

DNS Resolution: A Primer - KB1JWQ
http://blog.taos.com/2013/11/19/dns-resolution-a-primer/

======
colmmacc
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.

------
chrissnell
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.

73's. :) NW5W

~~~
chimeracoder
> behind to "Do you have any questions for me?"

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?

~~~
DavidWoof
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.

------
jlgaddis
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.

~~~
dsp
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.

------
xiaomai
This was a really great explanation of glue records. It seems like those are
often overlooked when learning about how DNS works.

------
noja
> 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.

Really? Where is this cache?

~~~
mcpherrinm
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.

Most home routers I've used also use dnsmasq.

~~~
noja
But the article says assume no caching, so I'm guessing nscd is off. He seems
to be referring to another local cache, which I don't think exists.

------
wereHamster
> On Linux specifically, the browser will call getaddrinfo()[2] to spark up
> the system’s internal resolver.

Not Chrome, it has its own DNS resolver.

~~~
gwu78
Can you turn this off?

Does Chrome respect /etc/resolv.conf or /etc/hosts?

The user cannot choose their own DNS servers?

~~~
n0ndescript
Chrome's resolver is a stub resolver - it is just a replacement for
getaddrinfo(). It does what getaddrinfo() does but asynchronously.

~~~
gwu78
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?

------
iigs
It's been quite suitable for my purposes, as well. :) (Hey Corey!)

