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
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?
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 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.
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. 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.Really? Where is this cache?
Most home routers I've used also use dnsmasq.
Not Chrome, it has its own DNS resolver.
Does Chrome respect /etc/resolv.conf or /etc/hosts?
The user cannot choose their own DNS servers?
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.