For something so pervasive, DNS is just too hard at times. Even the author, who is clearly in the 99th percentile plus for DNS knowledge, slips up on the depth.<p>There's two small nits, besides the modern browser caching/pre-fetching, that are worth clearing up;<p>1. When receiving a delegation response, the NS records won't be in the answer section - they'll be in the authority section. NS records are never in the answer section unless the query was an NS query, or an ANY query. But neither query plays any role in ordinary DNS resolution. Resolvers always ask the same question when recursing - so if you're trying to resolve www.example.com, then with a cold cache a resolver will at some point make a query that is the equivalent of "dig www.example.com @h.gtld-servers.net" . There you'll see the NS records in the authority section, and the glue in the additional section.<p>2. There's one exception to the "NS queries don't form a part of regular DNS" which is root zone priming. When a resolver first starts it will try to find the current "live" root zone contents by querying each root server in the hints file (which might be out of date), with an NS query, until one responds. E.g. "dig NS . @a.root-servers.net" . That response is what forms the authoritative root zone in the cache, not the hints file. The hints file is just for one-time bootstrap. At least that's the intent.
This is one of those interview questions that is so disconnected from the day-to-day work of systems administrators and DevOps types, yet it's probably the second-most popular question to ask (behind to "Do you have any questions for me?"). It's not a <i>dumb</i> question, per se, it's just that 90% of the details of the answer is stuff that most of us will never have to mess with.<p>Still, it's asked so frequently that it's worth learning. While you're at it, take the time to learn dig(1), inside and out. <i>This</i> is something that you'll use frequently and having a solid understanding of dig will make the DNS question a breeze, especially if you are quizzed on aspects of the resolution process.<p>Bonus points when answering this question: mention the existence of NIS as a resolution option when discussing nsswitch.conf. :)<p>All of that said, I never ask this question. I'd rather test a candidate's knowledge by asking them about things that we <i>do</i> have to do frequently, like holding a package with APT...backporting a package...writing IPtables rules...structure of Chef cookbooks, etc.<p>73's. :) NW5W
The "message compression" used in DNS messages is also quite unusual, compared to other protocols. It serves as a reminder that the DNS protocol was created at a time when it was desirable to minimize as much as possible the amount of bandwidth used (as opposed to today), e.g.:<p><pre><code> a domain name represented as a sequence of labels, where
each label consists of a length octet followed by that
number of octets. The domain name terminates with the
zero length octet for the null label of the root. Note
that this field may be an odd number of octets; no
padding is used.</code></pre>
> 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.<p>Really? Where is this cache?
> On Linux specifically, the browser will call getaddrinfo()[2] to spark up the system’s internal resolver.<p>Not Chrome, it has its own DNS resolver.