Making DNS Queries and Zone Transfers

Making A DNS Query

DNS is the Domain Name System and its primary purpose is name resolution. Computers rely on the DNS name space to resolve human-readable host names, such as http://www.microsoft.com, into machine-readable addresses, like 23.217.198.68. This really saves us the time from having to remember all the IP addresses of the Web servers that host our favorite Web sites. It’s best to think of this DNS hierarchical name space as a “tree-like” structure of DNS servers. If we wanted to get to http://www.microsoft.com, we would likely need to traverse this tree to get to the Web server hosting that Web site.

microsoft

Let’s Query Microsoft

So, what if you typed in http://www.microsoft.com? What happens behind the scenes? First off, your operating system caches previous name resolutions with the help of a stub resolver. If your Web browser finds that the IP address for http://www.microsoft.com isn’t cached in your operating system, and isn’t cached in the Web browser, or isn’t found in your computer’s hosts file, it will send a DNS request to your local DNS server. The local DNS server is provided to you by your ISP. The local DNS server is also referred to as a “Recursive Resolver” because it constantly refers back to itself as it queries DNS and it eventually resolves the name-to-IP address for you. Recursive Resolver.png

If the recursive resolver does not have the IP address for http://www.microsoft.com cached in its records, it will have to query DNS for the IP address of the Web server. This looks like a long process, but it actually occurs extremely quickly. Your local DNS server may not know the IP address for http://www.microsoft.com, but it does, however, know the IP address of the DNS root servers. There are hundreds of root DNS servers scattered all over the world and they are split into  a dozen root zones or clusters that are maintained by 12 root name server operators. VeriSign is one example of a root name server operator. The IP address of these root servers are burned into your local DNS server’s configuration file. Your local DNS server contacts a nearby root DNS server and asks if it has the IP address for http://www.microsoft.com. Unfortunately, the DNS root server doesn’t know the answer, but it is an “authoritative name server” that knows the IP addresses of many generic Top Level Domain (gTLD) name servers. The root DNS server then provides a list of IP addresses to gTLD name servers. But, we are only interested in the .com gTLD server.

root dns.png

The local DNS server now has to ask the .com gTLD server for the IP address of http://www.microsoft.com. The .com gTLD name server doesn’t actually know the IP address of http://www.microsoft.com either, but it does know the IP address of the second-level domain microsoft.com name server.

gTLD sever.png

Now, our local DNS has to ask the microsoft.com name server for the IP address of http://www.microsoft.com. As you can see, there is a lot of back-and-forth directions here. Fortunately, the second-level domain name server, microsoft.com, knows the IP address of http://www.microsoft.com.

micro1.png

The microsoft.com name server sends the IP address of the http://www.microsoft.com Web server to your local DNS server, which it then hands to your Web browser to initiate the HTTP request to the Web page. The local DNS server stores the IP address in its cache and your operating system does the same. That way, should you wish to re-visit http://www.microsoft.com in the foreseeable future, you won’t have to query DNS. Let’s take a look at this process from a larger point of view.

microsoft answer.png

As your PC makes a DNS request to its local DNS server, and as your local DNS server queries other DNS servers, the communication all occurs over UDP port 53. DNS queries use UDP because it faster than TCP; however, you can configure a DNS server to use TCP port 53 as a failover.

Inside A DNS Server

All DNS servers are running DNS software. Most DNS servers are UNIX/Linux-based systems, but Microsoft has its own DNS Server program built-into Microsoft Windows Server. DNS servers typically have three main folders: Cached Lookups, Forward Lookup Zones, and Reverse Lookup Zones.

The Cached Lookups

Most DNS servers are also caching servers, that is, they cache IP addresses they already resolved.

The Forward Lookup Zones

When a DNS client requests the IP address of a Web server, it queries DNS using a “forward lookup request,” which is also called “forward mapping.” Inside this folder are several “Resource Records (RRs).”

  • The Address (A) Record: The A record is also known as the “host record” because it holds the host name and IP address of a server.
  • The Authentication, Authorization, Accounting and Auditing (AAAA) Record: This record performs the same function as the A record; however, the AAAA record holds IPv6 addresses instead of IPv4 addresses.
  • The Mail Exchanger (MX) Record: The MX record is used to identify mail servers for e-mail, which is linked to either the A record or the AAAA record. Email has to be able to go from email server-to-email server. How do those servers know where to send the email? Well, they ask the DNS server. Inside the DNS server is the MX record. This is how all of our devices know where to send your emails.
  • The Canonical Name (CNAME) Record: A canonical name is an alias for a server or system. This enables an IP address to have multiple names.

The Reverse Lookup Zones

“Reverse Lookup requests,” or “reverse mapping” is the opposite of forward lookup requests. This means the DNS query is responding with a Fully Qualified Domain Name (FQDN) instead of an IP address. The Reverse Lookup Zone has a particular RR of interest:

  • The Pointer Record (PTR): This is the opposite of an A record. Typically, DNS clients make forward lookup requests by querying DNS with a domain name. The PTR record, however, allows us to make a reverse lookup request, which means we query DNS with an IP address and it responds with a FQDN. PTR records are optional, so it won’t always work.

Zone Transfers

DNS servers sometimes share information with other DNS servers in a process known as “zone transfers.” This process occurs over TCP port 53. A single domain can have more than one DNS server. For example, the Google.com domain is probably a very busy domain. It needs more than one DNS server. In one region, for instance, there will be an authoritative name server and a number of subordinate name servers for the Google.com domain.

DNS ZONES.png

In this highly simplified example, there are 3 DNS Servers for Google.com, but one DNS server (DNS 1) is acting as the authoritative name server. All the DNS servers know each others’ IP addresses. The job of the authoritative name server is to act as the primary DNS server and to make sure that all other name servers are updated for changes. For example, should a new DNS server be added to this Google.com domain, the authoritative name server must distribute a copy of this information to the secondary name servers. Another example might be just a simple record change in the Forward Lookup Zone. Whatever the change may be, the transaction must take place as it is a critical feature of DNS.

Simply having more than one DNS server also provides redundancy and fault tolerance. Should the primary DNS server go down for any reason, there is a backup DNS server ready to take over.

References

Meyers, M. (2015). All in One CompTIA Network+ Certification Exam N10-006. McGraw-Hill Education: New York, NY.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: