6.1 DNS Fundamentals

DNS is a hierarchical name resolution system. It is also the largest public directory service deployed. Virtually every company uses DNS for name resolution services, including hostname to IP address, IP address to hostname, and hostname to alternate hostname (aliases). DNS is a well-documented standard that has been around since the early days of the Internet. The RFCs in the following list cover some of the basics of DNS:

• RFC 1034, "Domain Names - Concepts and Facilities"

• RFC 1035, "Domain Names - Implementation and Specification"

• RFC 1912, "Common DNS Operational and Configuration Errors"

• RFC 1995, "Incremental Zone Transfer in DNS"

• RFC 1996, "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)"

• RFC 2181, "Clarifications to the DNS Specification"

There are three important DNS concepts that every Active Directory administrator must understand. Zones are delegated portions of the DNS namespace, resource records contain name resolution information, and dynamic DNS allows clients to add and delete resource records dynamically.

6.1.1 Zones

A zone is a collection of hierarchical domain names, the root of which has been delegated to one or more name servers. For example, let's say that the mycorp.com DNS namespace was delegated to ns1.mycorp.com. All domain names contained under mycorp.com that ns1.mycorp.com was authoritative for would be considered part of the mycorp.com zone. A subset of the mycorp.com zone could be delegated to another server, for example, subdomain1.mycorp.com, could be delegated to ns2.mycorp.com. At that point, subdomain1.mycorp.com becomes its own zone for which ns2.mycorp.com is authoritative.

The terms zone and domain are often confused in DNS parlance. A domain or domain name can actually be any type of name contained within a zone. The term zone has significance in relation to a portion of the namespace that has been delegated. A subdomain on one server may be a zone on another. The difference is determined by identifying the root of the contiguous namespace that was delegated.

6.1.2 Resource Records

A resource record is the unit of information in DNS. A zone is essentially a collection of resource records. There are various resource record types that define different types of name lookups. Table 6-1 lists some of the more common resource record types.

Table 6-1. Commonly used resource record types

Record type	Name	Description
A	Address Record	Maps a hostname to an IP address
PTR	Pointer Record	Maps an IP address to a hostname
CNAME	Alias Record	Maps an alias to a hostname
MX	Mail Exchanger Record	Specifies a mail route for a domain
NS	Name Server Record	Specifies name servers for a given domain
SOA	Start of Authority Record	Contains administrative data about a zone, including the primary name server
SRV	Service Record	Maps a particular service (e.g., LDAP) to one or more hostnames

One important resource record to note is the SRV record type. SRV records are used extensively by domain controllers and Active Directory clients to locate servers that have a particular service. We will describe how Active Directory uses these records in more detail later in the chapter.

6.1.3 DDNS

Dynamic DNS, defined in RFC 2136, is a method for clients to send requests to a DNS server to add or delete resource records in a zone. Having this capability has greatly increased the supportability of DNS in large environments. Before DDNS, the primary means to update a zone was either by directly editing a text-based zone file or via a vendor supported GUI, such as the Windows DNS MMC snap-in.

RFC 2136 can be found at http://www.ietf.org/rfc/rfc2136.txt.

Active Directory takes full advantage of DDNS to ease the burden of maintaining all of the resource records it requires. Each domain controller can have anywhere from a few dozen to a few hundred associated resource records depending on the size of the Active Directory site topology. And when the site topology changes, the resource records for a particular domain controller can also change. Because of the dynamic nature of the Active Directory resource records, in a large environment it could easily take a person working full time to manually maintain all the records.

Securing Your Dynamic Updates The RFC that defined Dynamic DNS, RFC 2136, did not provide for a security model to secure updates from clients. As you might expect, this is a very serious limitation to widescale adoption. To address this problem, RFC 2137, "Secure Dynamic Update," was created. Unfortunately RFC 2137 was not very practical in implementation and tended to be overly complex. Later, RFC 2535, "Domain Name System Security Extensions," defined a public key-based method for securing DNS requests, commonly known as DNSSEC. RFC 3007 was then created, which obsoleted RFC 2137 and updated RFC 2535 to provide a more flexible method to secure update requests. Many DNS server products have only recently started to provide support for these RFCs, and only time will tell whether they will become widely adopted. Check out the following for more information on RFC 2535 and 3007: http://www.ietf.org/rfc/rfc2535.txt http://www.ietf.org/rfc/rfc3007.txt While Windows Server 2003 provides support for some of the resource record types defined in RFC 2535, such as KEY, SIG and NXT, it does not provide full compliance, such as message signing and verification. The approach Microsoft takes to providing secure dynamic updates is by using ACLs in Active Directory. Zones that are Active Directory Integrated (described later in the chapter) store their DNS data in Active Directory. You can then set ACLs on the DNS-related objects in Active Directory to permit or deny users to update records. By default, authenticated computers in a forest can make new entries in a zone, and only the computer that created an entry is allowed to modify the data associated with that entry.