DNS Resolution: A Primer

Corey Quinn | Senior Technical Consultant at Taos

Corey Quinn | Senior Technical Consultant at Taos

by Corey Quinn, Senior Technical Consultant at Taos

A part of what I do at Taos involves interviewing prospective consultants for our Unix/DevOps practice via a thorough technical assessment. Our technical interview spans virtually the entire breadth of topics that encompass the practice of systems administration.

One focus area that I like to spend a bit of time on is DNS. This essential service acts as the underpinning behind almost everything else a system does; when DNS goes away, your system is likely to be very, very unhappy. Despite this, few people tend to have a grasp upon how DNS works underneath the hood. I went searching for a decent write-up that explains the name resolution process, and struggled to find anything succinct that hit the points I felt were important.

So from the top, “I’m on a Linux system. I punch www.taos.com into a web browser[1] and press enter. Strictly at a name resolution level, assuming every DNS server in the world has a cold cache, what happens?”

On Linux specifically, the browser will call getaddrinfo()[2] to spark up the system’s internal resolver. Assuming /etc/nsswitch.conf is configured to query files first and DNS second, the system will first check/etc/hosts to see if www.taos.com is defined. Assuming it isn’t, it will then check the system’s local cache to see if there is a recently cached answer to this query. Presuming not, it will then check /etc/resolv.conf to see what its local nameserver is. From there, it sends out a UDP packet on port 53 to that nameserver.

If we assume that this resolver is not authoritative for www.taos.com., taos.com., com., or the root domain (and isn’t configured to think that it is!), and is configured to permit recursive lookups from my host, it again checks its cache. Presuming the cache is empty (as we have stated), it then quests out to the root nameserver (which it gets from its prepopulated root hints file; ‘dig’ with no arguments on a properly configured system will regenerate this), and queries for www.taos.com. The root nameserver responds with a delegation response that points to the servers that are authoritative for .com. The resolver then asks the server that is authoritative for .com the same question; it now gets back the authoritative nameserver for taos.com.

At this point, I usually like to stop the interviewee to posit an interesting question. “Let’s say that taos.com lists an authoritative nameserver of ns1.taos.com; at this point, you’ve got a circular dependency in place. Your nameserver is going to get back ‘the authoritative server for taos.com is ns1.taos.com.’  Remember, nameserver delegations are given out by name rather than by IP address. At this point, it’s going to continue to endlessly resolve taos.com to determine where ns1 lives. Obviously, this doesn¹t happen; why not?”

The correct answer to this is that ns1.taos.com is in the “answer” section of the DNS delegation response. In the “additional” section of the response, it also includes the IP address of that server; this is called a glue record.

At this point, the nameserver queries the authoritative nameserver for taos.com, and (presumably) gets back an A record for www.taos.com… and caches it.

If you’ve enjoyed this dive into DNS resolution, please get in touch with Taos; we’d love to spend a couple of hours on the phone with you discussing similar topics in depth!

[1] Note that some web browsers have their own DNS cache; that is disregarded for this question, as it adds an unnecessary layer of complication to what is already a fairly complex process.

[2] Note this used to be gethostbyname(), and became getaddrinfo() due to the need for IPv6 support.

Comments (23)

  • Tony Le November 19, 2013 - 6:56 pm Reply

    Nice. Next blog post should be on routing tables.

    • Taos November 19, 2013 - 7:49 pm Reply

      Great idea!

    • Corey Quinn November 20, 2013 - 11:10 am Reply

      I think we’ve got a winner. Watch this space!

  • Adam Baxter November 19, 2013 - 7:37 pm Reply

    >If you’ve enjoyed this dive into DNS resolution, please get in touch with Taos; we’d love to spend a couple of hours on the phone with you discussing similar topics in depth!

    I’m assuming this comes at a price ;)

  • Siddharth November 19, 2013 - 8:33 pm Reply

    Recent versions of Chrome do not call getaddrinfo() on Linux and Mac. Instead it uses its own asynchronous DNS stub resolver that does all the steps you mentioned.

    • Corey Quinn November 20, 2013 - 9:50 am Reply

      Quite right. Programs that implement their own stub resolvers (see also: nmap) tend to complicate the issue a bit. I suppose if we’re looking for a more “pure” use case, “ping http://www.taos.com” would be a more suitable fit as browsers continue to evolve…

  • c1123860 November 19, 2013 - 9:10 pm Reply

    One should use drill(1) instead of dig(1)

    • Corey Quinn November 20, 2013 - 9:52 am Reply

      In theory yes, but you can’t count on people having drill installed on most platforms. On my desktop of choice (OS X) it’s only packaged (via homebrew) as a part of ldns, which is in turn really only ever installed as a dependency for unbound. The idea is to address the lowest common denominator of systems…

  • Tim Osman November 20, 2013 - 1:20 am Reply

    That’s not how DNS works. The resolver never “asks it who is authoritative for http://www.taos.com. “

    • Corey Quinn November 20, 2013 - 9:53 am Reply

      Quite right; my apologies for the oversight. I have corrected this. If you’re the root server, you (almost never) see queries for the TLDs themselves, but rather for full domains, which you then refer to the TLD servers.

  • hammad November 20, 2013 - 3:06 am Reply

    “If you’ve enjoyed this dive into DNS resolution, please get in touch with Taos; we’d love to spend a couple of hours on the phone with you discussing similar topics in depth!”

    I enjoyed it. I could chat for a couple of hours discussing similar topics. How to get in touch?

  • Stefan November 20, 2013 - 3:09 am Reply

    I’m afraid you got some details wrong here.

    You write “[the resolver] quests out to the root nameserver, and asks it who is authoritative for http://www.taos.com.” That’s not quite right. If (as we have stated) the resolver starts out from a “www.taos.com. A?” query, it will use this exact question to query the root server. This is neccessary for a number of reasons, one being that the name might be in the root zone, and then there would not be any other authoritative servers to refer to.

    The referral response that the root and GTLD servers will be replying with will have an empty answer section, the authority section pointing to the referred-to nameservers, and glue records in the additional section, although the latter is not a requirement. Glue records may be missing from the referral response and the resolver will have to start an internal query to fetch glue before continuing with the original query.

    Lastly, the sentence “[i]f we assume that this nameserver isn’t authoritative for the taos.com domain” should be more correctly put as “if we assume that this nameserver (better yet: resolver) is not authoritative for either http://www.taos.com., taos.com., com., or the root domain”.

    • Corey Quinn November 20, 2013 - 9:56 am Reply

      Thanks for the feedback. I’ve addressed your first and third points. The second is a bit more in-depth than I wanted to go for an introductory primer.

      This is a common problem with most explanations of recursive resolution; it’s *very* easy to go far too in depth too quickly, and lose most of your audience in the technical weeds. I probably erred on the side of being too superficial in this case.

  • anon November 20, 2013 - 3:20 am Reply

    > it will then check the system’s local cache
    Which local cache?

    • Corey Quinn November 20, 2013 - 9:57 am Reply

      nscd and dnsmasq are two common culprits. I wanted to steer away from being too implementation specific; it’s entirely possible that on a given system there is no caching set up.

  • onnlucky November 20, 2013 - 4:05 am Reply

    “it will then check the system’s local cache”, euh, where does that cache live? How does your libc access that?

    • Corey Quinn November 20, 2013 - 11:10 am Reply

      As mentioned previously, nscd is probably the most common implementation. nscd is a part of glibc, and if the daemon is running, the address call will go to nscd. I’d need to dig a bit deeper into the glibc code to determine exactly how this is accomplished.

      • Stefan November 20, 2013 - 12:53 pm Reply

        Don’t bother. nscd is a p.o.s. that is getting shot down more and more. For the hosts database it’s outright dangerous.

  • Bill Broadley November 26, 2013 - 7:33 pm Reply

    Next I’d suggest DNSSEC.

  • jack chen December 3, 2013 - 6:13 pm Reply

    Thanks Corey for this good posting.
    Without a functioning and feasible DNS as the naming resolution, just like you mentioned on your blog, systems are not gong to be happy.

    Excepts a feasible DNS solution, there are several new features that include LLMNR, PRNP, and DNSSEC (NSEC3, RSA/SHA2, RFC5011) provided by Windows Server 2012 to assist on the DNS solution (either using Bind DNS, MSDNS, Splunk DNS, or InfoBlox) to accommodate the dns clients’ requests.

  • jack chen December 3, 2013 - 7:29 pm Reply

    With a fully functioning DNS and naming resolution which usually requires both Recursive and Iterartive queries. Here is the interaction between a dns client and dns server addressed below.

    A DNS client somewhere on the Internet needs the IP address of IMAIL.taos.com. The following events take place:
    1. The client contacts NameServer1 with a recursive query for IMAIL.taos.com. The server must now return either the answer or an error message.
    2. NameServer1 checks its cache and zones for the answer, but does not find it, so it contacts a root server with an iterative query for IMAIL.taos.com.
    3. The server at the root of the Internet does not know the answer, so it responds with a referral to a server authoritative for the .com domain.
    4. NameServer1 contacts a server authoritative for the .com domain with an iterative query for IMAIL.taos.com.
    5. The server authoritative for the .com domain does not know the exact answer, so it responds with a referral to a server authoritative for the taos.com domain.
    6. NameServer1 contacts the server authoritative for the taos.com domain with an iterative query for IMAIL.taos.com.
    7. The server authoritative for the taos.com domain does know the answer. It responds with the requested IP address.
    8. NameServer1 responds to the client query with the IP address for IMAIL.taos.com.

Leave a Reply

Your email address will not be published. Required fields are marked *


five + = 6

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>