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.
There's two small nits, besides the modern browser caching/pre-fetching, that are worth clearing up;
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.
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 dumb 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.
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. This 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.
Bonus points when answering this question: mention the existence of NIS as a resolution option when discussing nsswitch.conf. :)
All of that said, I never ask this question. I'd rather test a candidate's knowledge by asking them about things that we do have to do frequently, like holding a package with APT...backporting a package...writing IPtables rules...structure of Chef cookbooks, etc.
A bit tangential, but I never liked that question. I mean, I understand the importance of giving the interviewee a chance to ask questions they may have about the company, but sometimes it feels like there's the expectation that one should have questions, and if you don't have any, it means you don't care, or aren't invested, or aren't a good candidate.
[In my experience, it usually means (A) someone else (perhaps one of the other interviewers) already answered it, or (B) it's hard to come up with questions on the spot.]
But maybe that's just a holdover from me having done interviewing workshops, etc. in high school/college which were tailored more for jobs in the financial sector, where this very much is the case.
Does anybody else feel this way? Or perhaps more importantly, if you conduct interviews (and ask this question), how do you react when a candidate doesn't have questions they want to ask?
From the interviewer side, I always ask this. I think it's just polite and don't really have any expectations at all. If somebody doesn't have questions, that's fine; if they want to know if there's a good coffee shop nearby, that's fine too.
But then, I'm not really one of those "culture fit" interviewers. By this point in the interview, I have a pretty good sense of where I think your technical skills are and that's what matters to me. I think judging people on weird intangibles is where interviewers tend to let their prejudices sway their judgment, and I strive to avoid that.
On the other side of the table, I always ask about bike facilities and source control processes.
For a job that you have done your research on, usually the question is pointless. Most high level jobs will be fairly clear about what they give back to you.
For many jobs where you might be just some guy, people might ask questions about the job site, culture, day to day minutiae, areas of specific responsibility, etc.
I really think it is a holdover from a time someone would go hat in hand to a job site and be given little information except "You are doing X, prove to me you should have this job."
I have interviewed a bunch of people for jobs that fit in both places in the spectrum, and while I don't expect the candidate to ask questions, if they are a face among the crowd of 20 interviews and give you relevant questions about your business it can show their interest in what you do, it can also show they are sensitive about specific things.
I disagree, I think this is a very high level description. Every sysadmin should know, and be able to explain in basic terms, the hierarchical nature of DNS. They should also know the difference between an authoritative and recursive DNS server, the basic record types, how zone transfers work, how to query servers, etc.
I would treat this as a bonus question, but not a required one to answer. If the interviewee is on the right track with a lot of good DNS questions and you throw this one at them, it might set them out from the pack.
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.:
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.
DNS compression is actually described in section 4.1.4 of IETF RFC 1035:
In order to reduce the size of messages, the domain system utilizes a
compression scheme which eliminates the repetition of domain names in a
message. In this scheme, an entire domain name or a list of labels at
the end of a domain name is replaced with a pointer to a prior occurance
of the same name.
Even now it's worth doing all compressions possible, with as little CPU use as possible. With something like a DNS server a difference of one byte in the packet size can result in twice as much bandwidth used. At the lowest levels, it's packets, not bytes. Cross the limit for one packet, get two packets, twice as much of bandwidth.
On Linux, this is typically nscd(8): Name service cache daemon. I believe some Linux distributions also ship with dnsmasq listening on localhost that serves a similar purpose.
That means the parent's comment is irrelevant in the context of what the article is discussing.
As for getaddrinfo, Links, a text-based browser which preceded Chrome by many years, also has one. Links allows the user to turn asynchronous DNS resolution off. Does Chrome?
There's two small nits, besides the modern browser caching/pre-fetching, that are worth clearing up;
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.
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.