How does DNS work?

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.

The Process

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:

  1. Your client sends a DNS request packet, usually via User Datagram Protocol (UDP), to the local DNS server.
  2. That DNS server has no clue what the IP address for www.Microsoft.com is, so it sends the entire request to your ISP's DNS server—a process known as forwarding.
  3. The ISP's DNS server also has no clue. However, it is configured with root hints, meaning it knows the IP address of a DNS server that is authoritative for the ".com" toplevel domain (TLD).
  4. The ISP's DNS server contacts the .com TLD server and asks for a reference for the Microsoft.com domain. This action is called a recursive query. Your own DNS server could have performed this type of query, but it's more common for businesses to forward requests to their ISP's DNS server.
  5. The TLD server, being authoritative, has records for every .com domain in existence (actually, there are a bunch of load-balanced DNS servers handling that TLD, but let's pretend it is one big server for now). So the TLD server sends back the IP address of a DNS server that's authoritative for the Microsoft.com domain. Now the DNS server knows how to contact Microsoft.com, so it just needs to figure out the "www" part.
  6. The ISP's DNS server then contacts the Microsoft.com DNS server. In all likelihood, that server is owned by Microsoft and contained in one of Microsoft's data centers (it's also probably part of another load balanced set of DNS servers because Microsoft.com gets so much traffic). The ISP's DNS server asks for the address of www.Microsoft.com.
  7. As an authoritative server for the Microsoft.com domain, the Microsoft.com DNS server has a record for the host named www. So it sends that host's IP address back to the ISP's DNS server.
  8. The ISP's DNS server sends the IP address for www.Microsoft.com to your local DNS server.
  9. The local DNS server sends the IP address to your client.
  10. You client now has the IP address, and can contact www.Microsoft.com directly.

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

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: 216.115.105.17 and 216.115.105.17.

Figure 21.1: Multiple replies for my.yahoo.com.

Record Keeping

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:

  • A, which is a Host Address record—This resolves a single host name, such as www, to an IP address.
  • CNAME, or Alias—This resolves a name such as www to an actual host name, such as www1. Think of it as a nickname for a computer—"www," for example, is easier to remember and more standardized than a computer name like "w4laswin," which is what a Web server's real name might be.
  • MX, or Mail Exchanger—This provides the name of the mail server for a domain. Multiple MX records can be provided for fault tolerance or load balancing and a priority assigned to each. Clients, such as sending mail servers, will attempt to contact the server in the MX record with the lowest-numbered priority.
  • AAAA—This maps an IPv6 IP address to a host name.
  • SRV, or Service—This provides the IP address of one or more servers providing a particular service. AD uses SRV records to allow clients to locate domain controllers, among other things.
  • SOA, or Start of Authority—This special record indicates that the DNS server hosting the zone is authoritative for the zone and is the primary source of name resolution for hosts within that domain.

Sharing Zones

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.

IP Address to Name

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.

Communications

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.

Data Storage

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.