Windows Server – Dns Service
Essay Preview: Windows Server – Dns Service
Report this essay
Instructions
Answer the following questions:
1. Can a non Microsoft Windows DNS service be used for the successful implementation of Active Directory Services? If so distinguish between the minimum and recommended requirements of the DNS service for an Active Directory implementation.
There are some key differences between Windows DNS Services servers and non-Windows DNS server appliances in the areas of AD integration and security. For example, some non-Windows DNS server appliances lack complete AD integration features. Conversely, Windows DNS Service servers dont support encrypted zone transfer and update features like some non-Windows DNS server appliances do. (ref: DNS server appliances)
One cannot
use any DNS service. Active Directory requires that the DNS support dynamic updates via RFC 2136; Windows 2000 has the advantage of being the only one that does it out of the box
Those environments that already have Internet domains and DNS servers on their networks have two options.Either replace their existing DNS servers with Windows 2000 boxes or create a new internal domain to host the AD. For example, if your company is called WidgetCo, and all your internal servers are TCP/IP hosts on widgetco.com, you either need to create a sub-domain called ad.widgetco.com or you need to create something like widgetco.net, as one of my associates had to do at a large Manhattan-based international law firm. Its possible to make Unix DNS servers like BIND (Berkeley Internet Name Daemon) support Windows 2000 dynamic DNS, but its a little tricky. Microsoft TechNets white paper on Windows 2000 DNS provides information on getting your non-MS DNS to comply with RFC 2136. Chances are youll need to upgrade your Unix server to the latest version of BIND, version 8.2, to make it work. Creating an entirely new domain may be less of a headache.
(ref: How Microsoft went wrong with Active Directory)
When Microsoft started to talk about AD and ADs DNS integration, the company said AD would operate with any DNS implementation that is compatible with the standards for dynamic DNS. DDNS is a key piece of the AD model. As the development of AD progressed, Microsoft downplayed the support for non-Win2K DNS servers. At press time, Microsoft claimed that Win2K will be compatible with UNIXs Berkeley Internet Name Domain (BIND) 8.2, but to fully utilize ADs features, you will need to use Win2Ks DNS.
UNIX advocates believe that NT isnt stable enough to provide the 24 X 7 service that DNS services require and that the Microsoft DNS implementations arent sufficiently compatible with the open-source UNIX standards. Win2K and NT advocates believe that Win2K is reliable enough for the 24 X 7 service that DNS servers need (in multiple-server installations) and that Win2Ks DNS implementation is easier to manage and maintain than a UNIX-based DNS.
Win2Ks position is straightforward: If you want to fully utilize every AD function (e.g., deployment, installation automation), you have to use Win2Ks DNS services. The trick will be to find a way to let Win2Ks DNS provide services to Win2K and let the UNIX-based DNS retain control over the non-Win2K network components.
Win2K businesses that dont host their DNS services are in more of a bind (no pun intended). DNS server maintenance isnt a trivial matter, and businesses that dont have the expertise inhouse will need to develop or hire knowledgeable personnel–neither option is cheap. Businesses will also need to add at least two DNS servers (i.e., primary and secondary) to the Win2K network. The hardware for these DNS servers is an additional expense, and the Win2K hardware requirements are significannot
. However, implementing Win2K without AD is fairly pointless.
A business needs to resolve the domain name and DNS services concerns before it can truly begin to implement Win2K. Given the traditional IT approach to an OS rollout, in which the focus is on the OS, you might not have discussed these core concerns. Now might be the time to take a step back from your test configurations and deployment planning to make sure that youre also addressing the business and infrastructure concerns of a Win2K rollout.
(ref:Preparing for active directory)
Scenario 2
In this scenario, you need to decide how to integrate your existing DNS structure with Win2K. Win2K implements a DNS-style naming structure based on Lightweight Directory Access Protocol (LDAP) proposals. For example, if our Win2K AD domain name is sales.microsoft.com, an LDAP name can represent it as DC=sales,DC=microsoft,DC=com,O=Internet, where DC stands for a domain component and O stands for an organization. Id recommend that your Win2K architects be well versed in several areas, including AD, Active Directory Service Interfaces (ADSI), LDAP, dynamic DNS, and TCP/IP.
In a mixed environment, you might have to decide whether to use a contiguous or disjointed namespace for your Win2K DNS hierarchy. In a contiguous namespace, the child domains always contain the name of the parent domain in their names. For example, sales.microsoft.com is a contiguous namespace where the sales domain is a child of microsoft.com. In a disjointed namespace, the child domain doesnt contain the name of the parent domain as part of its domain name. For example, expedia.com could be a child domain of microsoft.com, but it doesnt contain the parent name in its name. Whether you use a contiguous or disjointed namespace determines how LDAP search operations execute. One advantage of a contiguous namespace is that a domain controller will create referrals to the child domains. In a disjointed namespace, the LDAP searches terminate because the domain controllers dont create any referrals. If you must implement a disjointed DNS namespace, there are some workarounds that require a more in-depth knowledge of AD, Schema, and LDAP.
To integrate DNS servers with non-Microsoft DNS servers (e.g., UNIX BIND servers), you should consider using only non-Microsoft servers that support dynamic updates and SRV records. BIND 8.1.2 or later servers support both dynamic updates and SRV records. Dynamic update isnt a requirement, but support for SRV record is a must. Microsoft recommends that you use BIND 8.2.1 or later, which supports dynamic updates, SRV records and, unlike BIND 8.1.2, incremental zone transfers. (For more information, refer to my columns Dynamic DNS Updates in Windows 2000 and Migrating to Windows 2000.) Microsoft recommends that you configure Win2Ks