In the days of Windows NT 4.0 and earlier, Microsoft products relied almost exclusively on NetBIOS name resolution to locate resources on a peer-to-peer or domain-based network. This underwent something of a sea change when Active Directory came into the picture, as Windows 2000 became the first Microsoft operating system to use DNS as its primary name resolution mechanism.
This trend has continued with Windows Server 2003 and R2 with no signs of changing. DNS is certainly here to stay, and because Active Directory is so dependent on the underlying network infrastructure, it's safe to say that your AD deployment simply will not function well (if at all) if DNS is not up to snuff. But before you can install and deploy a DNS server on your network, it's helpful to understand the mechanics of how DNS actually works; how DNS clients and servers work together to resolve human-readable DNS names into IP addresses.
There are two types of DNS queries: recursive and iterative. When a DNS client requests DNS information, it uses a recursive query to do so. (And for the purposes of this discussion, a DNS client is any computer requesting DNS information, even if that computer happens to be running a server operating system.) In a recursive query, the DNS client sends its query to the first DNS server that it has been configured for in its TCP/IP configuration. It then sits and waits for the server to return an answer. If the server returns a positive response, the client will then go to the IP address returned by the server.
If it's a negative response, the client will return some sort of "Page/Resource not found" error to the user. One thing that's important to note here is that configuring multiple DNS servers on a client will not cause the client to check with subsequent servers if the first one returns a negative response. The only time a client will go to its secondary DNS server is if the first one is unavailable. If the first DNS server queried returns a negative response, the client will not try any secondary servers and will accept that negative response as final.
When a DNS server receives a name resolution query, it follows a four-step process to determine whether it can respond to the query:
1. Do I host the zone that contains this record? If the query is for www.mycompany.com, and the DNS server being queried hosts a copy of the mycompany.com zone, then it will respond to the client with the IP address of www.mycompany.com. If not, the DNS server will move to the next step.
2. Is the record that's being requested in my cache? When a DNS server returns a positive answer to a client that isn't part of any zone it hosts, the server will cache the response in memory to speed any future requests for that resource. If the record is present in the DNS server's cache, it will return that record to the client. Otherwise, we move to the next step.
3. Am I configured with a forwarder? Many (though not all) DNS servers will be configured with a forwarder, which is a DNS server to send any queries to if it cannot answer the query through locally-hosted zones or the server cache. When a DNS server is configured with a forwarder, it sends a recursive query to the forwarder. The DNS server is, in effect, acting as a client.
Again, it's important to remember that this means the DNS server will send a query to its primary forwarder only and accept the response as gospel. It will only go to its secondary forwarder if the primary is unavailable, not if the primary forwarder is unable to resolve the query. If the DNS server receives an answer -- either positive or negative from one of its forwarders -- the server will return that answer to the client.
If the DNS server is not configured with any forwarders, it will move onto the fourth and final step before returning a negative response to the client.
4. Am I configured with root hints? Root hints allow a DNS server to perform an iterative query that uses a series of referrals (a process that's known as recursion, just to further muddy the terminology waters.) In an iterative query, the DNS server will query a top-level server (such as the ".com" server) to locate the mycompany.com zone. Then it will query the mycompany.com server and so forth until it finds a server that is authoritative for the record that's being requested.
Once it locates an authoritative server, it will end the referral process and get a "Yes, here's that resource" or "No, I don't know where that resource is" answer from the authoritative server, which it will then return to the client.
Laura E. Hunter (CISSP, MCSE: Security, MCDBA, Microsoft MVP) is a senior IT specialist with the University of Pennsylvania, where she provides network planning, implementation and troubleshooting services for business units and schools within the university. Hunter is a two-time recipient of the prestigious Microsoft "Most Valuable Professional" award in the area of Windows Server-Networking. She is the author of the Active Directory Field Guide (APress Publishing). You can contact her at email@example.com.