The Domain Name System (or Service, depending on who you listen to—DNS) is one of the most important components of modern networks, including the global Internet. Without it, you couldn't type www.Microsoft.com into your Web browser; you'd have to type a difficult-to-remember IP address instead. DNS saves the day by translating human-friendly names into computer-friendly IP addresses. It actually does much more than that—providing computers with critical information about network services such as the locations of mail servers, domain controllers, and more.
In any DNS transaction, at least two computers are involved: the DNS server and a DNS client. In most networks, there is often also a second DNS server known as the forwarder as well as additional authoritative DNS servers. Consider an example: You're on your company's internal network, which is equipped with a DNS server. That server is set up to forward to your ISP's DNS server, and you're trying to surf to www.Microsoft.com. Here's what happens:
If the Microsoft.com server didn't have a record for a host named www, it would send back a negative reply. As an authoritative server, it by definition has records for all hosts in the domain; in other words, if that DNS server doesn't know about the host, the host doesn't exist.
Now, there's a bit of extra subtly in there. Each DNS server along the way will try to cache previous lookups. With a popular site such as www.Microsoft.com, it's likely that your local DNS server, or certainly your ISP's DNS server, will have already been through this process once. DNS servers will used their cached results from earlier attempts whenever possible to avoid having to go through this entire process every single time a request comes through.
DNS replies can often contain multiple responses. For example, if your client queries my.yahoo.com, you'll get back a response with at least two IP addresses. Your client is free to try either one, although it'll usually try the first one. A DNS technique called round robin can be implemented on the server; when more than one record exists for a single host, the server will rotate the order of the IP addresses in outgoing responses. This behavior helps direct clients to different servers in a Web farm, for example, more evenly spreading the workload. Figure 21.1 shows a Network Monitor capture of a DNS response in which you can clearly see two IP addresses for my.yahoo.com: 18.104.22.168 and 22.214.171.124.
Figure 21.1: Multiple replies for my.yahoo.com.
DNS keeps track of information in zones. Essentially, a zone is a flat-file database for a particular domain, such as www.Microsoft.com. The zone can contain different record types, all of which can be queried by clients:
It's common for companies to have more than one DNS server for their domains. In fact, the rules for DNS say that each domain must be hosted by at least two DNS servers for fault tolerance. However, having multiple DNS servers can be a configuration nightmare, because you would have to update records in multiple locations.
Rather than creating this maintenance nightmare, DNS servers can be configured to host secondary zones, which are essentially read-only copies of a primary zone. Configuration changes can be made in the primary zone, then transferred, or replicated, to the secondary zones through a process known as a zone transfer.
Sometimes computers need to resolve an IP address to a computer name. For example, when two SMTP email servers communicate, the receiving server might want to verify that the sending server is, in fact, really coming from the domain it says it is. The server can use DNS to perform a reverse lookup, attempting to translate the sending server's IP address into a host name and domain name.
Reverse lookups are provided through special, independent reverse lookup zones, which contain PTR records. PTR, or pointer records, resolve an IP address into a computer name. Like regular forward lookup zones, you can create primary and secondary reverse lookup zones for load balancing and redundancy.
Most DNS communications—queries and replies, at least—are conducted over connectionless UDP transmissions on UDP port 53. UDP does not provide packet confirmation, so if a request gets dropped in transit, the client will never know. Clients therefore wait for a fixed period of time—called a timeout period—before assuming the packet was lost and retransmitting it. Most clients will try three times, then assume that their DNS server has failed.
Zone transfers, which are usually large and involve hundreds or thousands of packets in sequence, are conducted over TCP port 53. TCP requires a bit more processing time to set up, but provides packet confirmation and allows for single-packet retransmissions if necessary.
The DNS specification makes it clear that UDP communications are intended to be single packet, and DNS requests are therefore limited to 256 bytes over TCP. This limitation is normally sufficient for any query. However, some replies with multiple hosts can exceed 256 characters. Although the DNS specification is unclear how these should be handled, in practice, the server will set up a TCP communications channel to send the response. In these cases, TCP port 53 is used. Clients listen for replies on both UDP and TCP port 53, ensuring clear communications.
Most DNS servers, including nearly all UNIX-based servers, store their DNS records in zone files, which are essentially text files. In fact, many UNIX DNS servers are simply background daemons (services), with no UI whatsoever. Changing DNS records requires you to edit the text file, then restart (or hup in UNIX parlance) the service, which rereads the updated file.
Microsoft DNS running on a Windows 2000 (Win2K) domain controller can convert a standard, file-based zone to an AD -integrated zone. In this type of zone, records are stored in the AD database and replicated to all domain controllers. Any domain controller running the Microsoft DNS service is therefore a DNS server. Technically, because all domain controllers have full read/write access to the AD database, all DNS servers in an AD -integrated zone are said to host a primary zone because they can all make changes to the zone. Changes made on one server are replicated through AD to the others.