DNS Infrastructure Design

A successful DNS infrastructure design must meet both business and technical requirements. The business needs must be addressed first so that existing applications and systems are not impacted by the addition of Windows 2000, Active Directory, and a new DNS. Technical requirements include availability, reliability, security, and scalability.

Integrating Windows 2000 DNS with BIND

BIND is the most prevalent Unix-based DNS service in existence today. Many organizations, even those with predominantly Windows-based hosts , have implemented BIND for external and internal name resolution. Because DNS is a critical service, many IT departments are reluctant to modify an existing, functional implementation of DNS to support Windows 2000 and Active Directory.

Fortunately, Windows 2000 DNS can interoperate with BIND. However, different solutions are required based on the installed version of BIND because later versions include features not found in earlier BIND implementations .

As mentioned earlier, Windows 2000 processes use service locator records in DNS to find a nearby domain controller that is hosting a desired service. A Windows 2000 Professional client computer might be running an application wanting to access the Global Catalog (GC), for example. SRV record support is mandatory for any DNS server accessed by Windows 2000 domain controllers. BIND version 4.9.7 and above supports SRV records.

Although not mandatory, it is strongly suggested that any DNS used for Windows 2000 domain controllers also support dynamic update. Dynamic update enables a host computer to register its own DNS records. You'll find dynamic update extremely useful when adding a new domain controller because a large number of SRV records must be registered. The exact number depends on the number of services to be hosted on that server. The records are written to the %systemroot%\system32\config\netlogon.dns file when the new domain controller's dcpromo process completes successfully. To avoid the need for tedious and error-prone manual update, you should use a DNS server that permits dynamic update. BIND version 8.1.2 is the first reliable version of BIND to perform dynamic updates successfully.

You might find references to BIND 8.1.1 in older documentation. BIND 8.1.1, how ever, crashes when updated by a Windows 2000 computer and is therefore not well suited to a Windows 2000 implementation.

A sample netlogon.dns file follows :

 xyz.corp. 600 IN A 10.10.1.1 _ldap._tcp.xyz.corp. 600 IN SRV 0 100 389 redmond.xyz.corp. _ldap._tcp.pdc._msdcs.xyz.corp. 600 IN SRV 0 100 389 redmond.xyz.corp. _ldap._tcp.gc._msdcs.xyz.corp. 600 IN SRV 0 100 3268 redmond.xyz.corp. _ldap._tcp.558f59cf-0aad-4841-9d85-9dcb91989ee2.domains._msdcs.xyz.corp. 600   IN SRV 0 100 389 redmond.xyz.corp. gc._msdcs.xyz.corp. 600 IN A 10.10.1.1 8bbc38db-c18e-48bb-a7a3-e3154617862d._msdcs.xyz.corp. 600 IN CNAME   redmond.xyz.corp. _kerberos._tcp.dc._msdcs.xyz.corp. 600 IN SRV 0 100 88 redmond.xyz.corp. _ldap._tcp.dc._msdcs.xyz.corp. 600 IN SRV 0 100 389 redmond.xyz.corp. _kerberos._tcp.xyz.corp. 600 IN SRV 0 100 88 redmond.xyz.corp. _gc._tcp.xyz.corp. 600 IN SRV 0 100 3268 redmond.xyz.corp. _kerberos._udp.xyz.corp. 600 IN SRV 0 100 88 redmond.xyz.corp. _kpasswd._tcp.xyz.corp. 600 IN SRV 0 100 464 redmond.xyz.corp. _kpasswd._udp.xyz.corp. 600 IN SRV 0 100 464 redmond.xyz.corp. _ldap._tcp.Default-First-Site._sites.xyz.corp. 600 IN SRV   0 100 389 redmond.xyz.corp. _ldap._tcp.Default-First-Site._sites.gc._msdcs.xyz.corp. 600 IN SRV   0 100 3268 redmond.xyz.corp. _kerberos._tcp.Default-First-Site._sites.dc._msdcs.xyz.corp. 600 IN SRV   0 100 88 redmond.xyz.corp. _ldap._tcp.Default-First-Site._sites.dc._msdcs.xyz.corp. 600 IN SRV   0 100 389 redmond.xyz.corp. _kerberos._tcp.Default-First-Site._sites.xyz.corp. 600 IN SRV   0 100 88 redmond.xyz.corp. _gc._tcp.Default-First-Site._sites.xyz.corp. 600 IN SRV   0 100 3268 redmond.xyz.corp. 

The following sections examine some common options based on the version of BIND in use. Note that information in this section is valid only as far as Microsoft certification materials are concerned . All versions of BIND listed here have major, identified security flaws and should never be used in production environments.

BIND Versions Prior to 4.9.7

BIND implementations using versions prior to 4.9.7 support neither SRV service locator records nor dynamic update. These servers cannot be used alone to support Active Directory, but they can be used in conjunction with later BIND servers or Microsoft Windows 2000 DNS servers to provide the necessary functionality.

Two basic options exist. First, the four Active Directory zones can be delegated to DNS servers with SRV record support. The delegated servers can be running BIND 4.9.7 or higher or Windows NT 4.0 DNS (with Service Pack 4) or higher.

Second, a separate Active Directory subdomain can be created, again on a BIND or Microsoft DNS server that supports at least SRV records and preferably dynamic update.

These options are discussed in the next section, "DNS Naming Strategies."

BIND Versions 4.9.7 “8.1.1

These versions of BIND allow for SRV records but either do not support dynamic update at all or do not perform it reliably for Microsoft hosts. The options described previously for earlier versions of BIND apply here as well. A third option is to perform manual updates of the DNS server using the contents of the netlogon.dns file created during the dcpromo operation. Note that updates must also be done whenever a new site or Global Catalog Server is added.

BIND 8.1.2 or Higher

These versions of BIND permit SRV records and can be reliably updated by Microsoft Windows 2000 hosts. You don't have to run Windows 2000 DNS if the existing DNS infrastructure consists of BIND 8.1.2 or higher.

Other DNS Servers

Microsoft Windows NT 4.0 DNS supports SRV records if Service Pack 4 has been applied. However, NT 4 DNS does not perform dynamic updates, so the Active Directory SRV records must be manually updated every time a domain controller, Global Catalog Server, or site is added or deleted.

Windows 2000 domain controllers must use a DNS server with SRV record support. Dynamic update is strongly recommended because changes in the domain controllers or Active Directory can require updates to SRV record information. Note that only a standard primary DNS server needs to support dynamic update; secondary DNS servers pull updates from the primary server and therefore do not need dynamic update capability.

Ensuring Availability

Because DNS is so critical to the proper operation of Windows 2000 and Active Directory, the DNS design must be fault tolerant. You can take several approaches to ensure that a DNS server is always accessible, regardless of failures in hardware, software, or LAN/WAN connections.

Use One DNS Server per Site

The first rule of thumb is to place at least one DNS server in each site. Sites are areas of good network connectivity, and a multisite environment typically has wide area links connecting the sites. WAN links are usually more prone to failure than LAN connections, so it stands to reason that a DNS server per site will provide a good measure of fault tolerance.

Delegate Subdomains Off the Root

A traditional DNS implementation consists of one primary DNS server, which receives periodic updates, and one or more secondary DNS servers, which obtain read-only copies of the zone file from the primary.

DNS primary and secondary servers operate in a manner similar to primary and backup domain controllers under Windows NT 4.0. Updates can be made only at the primary DNS server, and secondary DNS servers periodically pull an updated copy from the primary.

The biggest problem with the traditional approach is that, if the primary DNS server is down, no updates can take place. In a nondynamic environment, this does not present a major issue because updates are manually entered. It matters little whether a host record update, for example, occurs now or in one hour . However, if DNS is being updated dynamically, server availability becomes much more important. If client computers are configured to update DNS, either by themselves or through DHCP, server availability is critical.

One solution is to delegate all subdomains off the root domain. For example, assume that the XYZ Corporation has subdomains for Europe, Asia, and North America. The European and Asian subdomains should be delegated to servers located in those geographic areas. Delegation improves reliability and performance because DNS updates do not need to cross wide area networks (WANs). In addition, to further minimize WAN traffic, the DNS server that is the primary server for a given subdomain, such as eur.xyz.corp , should be the secondary server for all the other domains and subdomains in the enterprise. Configuring multiple DNS servers as secondaries also provides a level of fault tolerance. Therefore, the DNS server in Europe would contain the zone file for Europe as well as be secondary for all other zones. In addition to being primary for Europe, this DNS server would have a read-only (secondary) copy of the Asian, North American, and root zones.

Use Active Directory-Integrated Zones

Active Directory-integrated zones are exclusive to Windows 2000 DNS. A new zone can be created as Active Directory integrated or be changed from a standard zone at any time. Simply right-click the zone filename in the DNS MMC snap-in, select Properties, and click the Change button on the General tab of the Properties page, as shown in Figure 4.2.

Figure 4.2. Active Directory-integrated zones.

Active Directory-integrated zones have several advantages over the standard zone types. The most significant of these is that AD-integrated zones are multimaster . If two domain controllers exist at a site and both are DNS servers with Active Directory-integrated zones, updates can occur at either server. Fault tolerance is greatly enhanced, and updates are far more likely to remain local rather than cross slower and possibly more congested WAN links.

Because the zone information is stored in Active Directory, replication follows the same path as regular Active Directory replication. Traditional DNS requires a separate replication topology, which can complicate zone transfer troubleshooting.

An additional benefit of Active Directory integration is the capability to secure the dynamic update process. When the Only Secure Updates option is selected, as shown previously in Figure 4.2, updates to DNS are signed and encrypted. Encryption prevents unauthorized persons from monitoring, or sniffing , the network to pick up information about servers and workstations by examining DNS traffic. Packet signatures validate that the DNS update request was sent by the proper entity, thus curtailing name theft.

Traditional zone transfers, either incremental or full, are sent in clear text so that someone monitoring the network has a complete picture of all the servers and workstations registered with DNS. Note that using IPSec to secure transmissions between standard DNS servers is possible. IPSec can be configured to sign or encrypt (or both sign and encrypt) all IP traffic between specified computers. Because IPSec security is applied low in the IP stack, applications don't have to be aware of the existence of IPSec. This means, however, that IPSec must be configured separately from DNS, so the security features are not available automatically.

In a mixed DNS environment, non-Microsoft secondary DNS servers can still receive updates from an Active Directory-integrated DNS server because a BIND-style zone file is still maintained .