Prior to installing Active Directory in a Windows 2000 environment, it is important to first design a DNS implementation that will meet both your name resolution and Active Directory requirements. Active Directory requires DNS in order to provide both name resolution as well as namespace definition, since domain names in Windows 2000 are based on the DNS naming conventions. As such, any servers on which you are installing Active Directory should have their TCP/IP properties configured to be pointing at a DNS server that you have already configured. If you choose not to do this, the installation of Active Directory will automatically create a DNS structure for you, which may not meet your needs.
Since a basic introduction to how DNS queries work was already covered earlier in the series, I am not going to repeat it here. Instead I am going to cover the main areas of DNS that you’ll need to understand in order to successfully implement the service for the purpose of supporting both name resolution and especially Active Directory.
The first concept that you’ll need to be familiar with is the use of DNS to resolve hostnames or fully qualified domain names to IP addresses. As a quick reminder, a fully qualified domain name (FQDN) provides the hostname as well as the domain name of a system. For example:
In this example, the hostname is the leftmost portion, or www. Hostnames can also be resolved using a HOSTS file, which is a static text file that exists in the %systemroot%\system32\drivers\etc directory on the local machine. DNS should not be confused with WINS, which maps Netbios names to IP addresses (as does the text equivalent, LMHOSTS).
DNS stores a number of different types of resource records beyond simple host or ‘A’ records. The most popular resource records that you’ll find in a zone file are outlined below:
- SOA –represent the Start of Authority for a zone, and provides information about the zone including which server is the primary, who the administrative contact is, how often zone database files are checked for changes, database serial numbers, time to live values, and more.
- A –represents a unique host address on the network, mapping its hostname to an IP address.
- NS – outlines a domain name and the corresponding FQDN of name servers that are authoritative for that domain.
- MX – designates that a given host is a mail exchanger (mail server or forwarder) for the domain specified.
- PTR – provides reverse lookup capabilities by mapping the reversed IP address of a host to an FQDN. This allows the hostname associated with an IP address to be found. PTR records are found in reverse lookup zone files.
- SRV – maps a particular service to one or more hosts. For example, records can indicate a server as a Global Catalog server, domain controller, and so forth.
The second main concept you’ll need to be familiar with is that of a zone. A zone is basically an area of the DNS namespace that functions as an administrative unit. That is, a group of name servers are responsible (have authority) for the records relating to a certain domain and/or subdomains. I like to refer to zones as areas of responsibility. For example, I could create a zone for the domain 2000trainers.com, and create 2 servers that would be responsible (authoritative) for holding records for the defined zone. I could then create a different zone, to be managed by someone else, for the domain asia.2000trainers.com, and have 2 other servers (maybe in Asia) that are responsible (authoritative) for the records in that zone. However, a zone can also encompass a number of domains, as long as they fall within a contiguous namespace. For example, 2000trainers.com and asia.2000trainers.com could be part of the same zone, and have a number of servers responsible for holding records relating to the two domains. If a query was sent to these DNS servers looking for a record ending in 2000trainers.com or asia.2000trainers.com, these name servers could answer the query, since they are authoritative for the zone, which includes the two domains. The main reason for having multiple zones usually relates to administrative authority, as well as zone transfer traffic. For example, perhaps I have one DNS administrator in Canada and one in Asia. Then, two zones may be warranted. By the same token, if I had only one zone, then all DNS servers (perhaps two in Canada and two in Asia) would all need to participate in zone transfers in order to receive updates. This may cause an unacceptable level of WAN traffic.
As a general rule, 5 main types of DNS servers exist which you should be familiar with. These are primary, secondary, active-directory integrated, forwarding, and caching-only. Each is described below:
Primary DNS Server – a primary DNS server is the name server that is authoritative for a zone. Essentially what this means is that this is the only server on which updates to the zone database can be made.
Secondary DNS Server – a secondary DNS server contains a read-only copy of the information stored on the primary name server, and obtains updates via zone transfers. A single secondary is the minimum suggested requirement, but many more can be created for the purposes of load-balancing and fault-tolerance.
Active Directory Integrated – limited to Windows 2000-based DNS servers, this implementation of DNS stores the zone file as an object within Active Directory instead of a series of files on the hard drive. In this scenario, every domain controller running DNS essentially acts as a primary DNS server, allowing updates to the zone file, and handling zone file synchronization via directory replication. As such, if any DNS server should fail, any other AD-integrated server can continue to make updates.
Caching-Only – a caching only DNS server is not authoritative for any zone. As such, it simply takes client queries, performs queries on other DNS servers, caches the results, and passes the answers to clients. By default, a caching-only DNS server will forward all queries for information not found in cache to DNS root servers.
Forwarder – DNS servers can be configured to sent queries that they cannot resolve to other specific DNS servers, referred to as forwarders. The forwarders will then work to resolve the query, instead of the individual DNS servers. This allows the number of requests sent to find hosts (on the Internet for example) to be reduced over time, as the forwarder handles these requests and caches the results, which are subsequently returned to the DNS servers making the request. The can improve both speed and efficiency.