Windows Server - Dns Service

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 don't 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. It's possible to make Unix DNS servers like BIND (Berkeley Internet Name Daemon) support Windows 2000 dynamic DNS, but it's a little tricky. Microsoft TechNet's white paper on Windows 2000 DNS provides information on getting your non-MS DNS to comply with RFC 2136. Chances are you'll 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 AD's 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 UNIX's Berkeley Internet Name Domain (BIND) 8.2, but to fully utilize AD's features, you will need to use Win2K's DNS.

UNIX advocates believe that NT isn't stable enough to provide the 24 X 7 service that DNS services require and that the Microsoft DNS implementations aren't 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 Win2K's DNS implementation is easier to manage and maintain than a UNIX-based DNS.

Win2K's position is straightforward: If you want to fully utilize every AD function (e.g., deployment, installation automation), you have to use Win2K's DNS services. The trick will be to find a way to let Win2K's DNS provide services to Win2K and let the UNIX-based DNS retain control over the non-Win2K network components.

Win2K businesses that don't host their DNS services are in more of a bind (no pun intended). DNS server maintenance isn't a trivial matter, and businesses that don't 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 you're 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. I'd 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 doesn't 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 doesn't 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 don't 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 isn't 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 Win2K's