This post is missing what is a very common DNS mis-configuration: extra, and/or lame delegations.
The root will return the list of authoritative nameservers, but each of those authoritative servers may have a different list - and that list may still be used for resolution.
For example, if the root says ns1,ns2.example.com are the nameservers for your domain, but ns1.example.com also lists ns3.example.com as an authoritative server, then resolvers WILL query ns3. If ns3.example.com does not actually have authority for your domain (I.e., a lame delegation), then DNS queries for your domain will fail some percentage of the time.
It is valid (though confusing) to extend the list of authoritative nameservers from what the root says. But they had better all actually BE authoritative.
In my experience, this is one of the more common DNS misconfigurations.
This misconfiguration is indeed very common and sometimes it is hard to explain why this is a problem - 'it works for me' it is a common reply I'm getting when reporting such problem.
I wish domain registrars warned domain owners about lame delegations - they know owner's email or can show a message in an admin panel.
Thirty years ago, there was a script for processing and notifying domain owners regarding those lame delegations. It was called lamers.sh, and I took over maintenance of it from Paul Mockapetris. But then we started getting so much pushback from people who were getting the notifications that the script was allowed to go unmaintained, and the situation has only gotten worse since.
As a matter of practice, before removing an authoritative name server, we would usually point it to another server. I.e. ns3 might now point to ns2 and we'd Leve that for a few days as not all caching is respected.
After that you can remove the server and the name and if it's cached somewhere, it still points to a valid server.
Speaking as someone who has debugged a considerable number of DNS problems, recurring from the root as described in the post is the only dependable way to determine a domain's authoritative servers. I've seen every alternative method (`dig NS $DOMAIN`, `dig SOA $DOMAIN`, `whois $DOMAIN`) give the wrong answer in some cases.
A problem I have recently observed a few times: people add DNS records to the wrong zone. For example, they add an a.b record to the example.com zone, but b.example.com is its own zone.
Bind doesn't complain about the extra records, but also doesn't return them, even if b.example.com is hosted on the same bind instance. (Which is technically correct, but sometimes confusing).
The author notes that at the end of the blog post, but portrays the output as "confusing to read". Personally, I'm with you: `dig +trace` is one of those tools I use almost daily.
One interesting piece not mentioned is how updating the name servers at your registrar is communicated to the top-level domain (TLD) registry operator's name servers (ex: Verisign's for .com).
The answer, for .(com|net|org) at least, appears to be that the registrar makes an [EPP][^1] request on your behalf. The protocol is documented in IETF std69 -- specifically [RFC5731][^2].
What I'm not clear on is whether other methods are still in common use. I'm also curious what the process looked like before EPP. If someone else here knows, I'd be interested in learning.
EPP is still very much in use as ICANN requires it for gTLDs[0] (2012 round), sTLDs[1] (2000 & 2003 rounds). And most uTLDs[2] (non ccTLDs before 2000, e.g. .com) have moved over due to consolidation / negotiation / cajoling by ICANN.
ccTLDs[3] are free to chose their own provisioning process / protocols; some use EPP, some don't.
They other edge case I used to see is incorrect “glue” records. The parent name server needs to know the A records of your authoritative server. if your domain is example.net and you told the .com that your NS/SOA (can’t remember that detail) for example.net is ns1.example. net., you also need to provide an A record to the .com servers for that one machine. It used and probably still is possible for these to be incorrect and or incorrectly cached. Of course, “dont do that” is probably a better solution that fiddling with glue records.
There's nothing wrong with glue records. If you want to "selfhost" them, you will needs to set that up. Most registrars will require you to explicitly specify the addresses of the name servers when you try to self host the NS on the same domain.
Right and my recollection was from moving our self hosted authoritative name servers to new ip addresses and dealing with unclear/delayed updates to those glue records. Of course this was 20yrs ago and the UI for making changes was much less slick and real-time than it is today. Got through it just fine without DNS outages but we did have to be methodical and check dig output carefully along the way.
Aah, your right that things have gotten better. Luckily I only had to deal with more "modern" DNS setups.
Although, now that I think of it, you do need to be mindful even today. You could stills misconfigure them, but it's unlike it will be due to forgotten/missing records. Which I think is the most common issue, because people don't understand enough how DNS works to know those are needed
> This does the exact same thing so it will always give you the right answer, but the output is a bit confusing to read so I’m a bit more hesitant to recommend it.
I constantly get indications that dig is this really powerful tool, but I must say I always find its output baffling. Granted I'm not expert on DNS but I know the basics and its still pretty damn arcane. I usually can decipher it in the end (assuming nothing too weird is going on) but I can't shake the feeling that my understanding is being obstructed by the tool here.
I'm gonna fathom a guess that this is likely because you aren't aware that tha output returned by dig is (by default) valid BIND zonefile format/syntax, and/or you aren't very familiar with the BIND zonefile format/syntax itself.
Regardless, though, dig has a number of query options you might like to use that will suppress much of the (redundant and/or unwanted) output that's shown by default, such as "+noadditional", "+noauthority", "+nocmd", "+nocomments", "+noquestion", "+norrcomments", or "+nostats". You can even put all of those those (on a single line) in a "$HOME/.digrc" file and they'll be used automatically everytime you run "dig". See dig(1) for details.
Alternatively, you might find it easier to simply get into the habit of using (only) the "+short" query option everytime you run "dig" (or put that in .digrc). Just at the output of these queries, for example:
$ dig +short ns example.com
$ dig +short a google.com
The output quite possibly contains exactly what you want to know and nothing more -- including, especially, all of the extraneous output that often just gets in the way and leaves you constantly baffled!
One important note is that there’s actually a couple different kinds of DNS servers; Cloudflare 1.1.1.1 and Google Public DNS are examples of recursive resolvers. These resolvers do what is described in this post, which is to say, recursively resolve a DNS request using authoritative DNS servers. And authoritative DNS servers are in the hierarchy observed here, starting with the root name servers, the TLDs, and then any number of delegated authoritative name servers for specific zones. (I’m sure there is a limit to how many you can practically have, either due to protocol limitations or simply because recursive resolvers will give up.)
The reason why public recursive resolvers are unreliable when records change is because they cache answers according to the TTL, recursively. If you always use the authoritative servers to walk the query, though, you effectively sidestep this, since authoritative servers are the ones that actually store the records.
(In the past it was also common for operating systems to default to caching DNS records, but even though it is definitely beneficial for performance, I think a lot of them have stopped, for the sake of making things less confusing. You can potentially improve your web browsing experience by installing a caching DNS server locally to your machine or network!)
Good article, totally correct that that is how to definitely 100% get the correct answer.
The bottom of the article, with 'other ways' got me thinking that another way to get what is very probably the correct answer is asking a bunch of other DNS servers what they think the correct answer is.
Using dug (https://github.com/unfrl/dug) like: dug -q NS jvns.ca
I was able to see that 32 of the 37 servers it tried got an NS record with art.ns.cloudflare.com
This also shows you how well(ish) the answer is propagated
They're definitely not, that's just what their IP lookup would have you believe. There are in fact tons of root servers located all over the world leveraging anycast.
there's also the dig shortcut to see the authorative ns in a oneliner
`dig -t soa` - usually I pair this with a quiet .digrc with +noall +answer to have a more terse experience
The MNAME field of the SOA record isn't actually used in DNS resolution so it could contain useless garbage. Recurring from the root as described by the blog post is the only correct way to determine a domain's authoritative servers.
This will usually give you the right answer, but it might be an old cached version."
Is that really ever a problem? Who changes authoritative nameservers for a domain? This is by far the easiest way and the whole blog post could have just been six lines long.
> and the whole blog post could have just been six lines long
The whole point of the blog posts is to explain the problem in detail, not getting some quick task done for the sake of getting it done. Just like https://jvns.ca/blog/2021/12/04/how-to-use-dig/ isn't "Use man dig" but an in-depth explanations of the features and usage.
Speaking as someone who worked for an ISP and looked after our DNS and domain name registration infrastructure (amongst many other things) lots of folks and for all sorts of different reasons. It's not as uncommon as you might think. And the extra diagnostic steps described in that article (or similar) were daily drivers when debugging customer support issues related to DNS.
whois only works for registered domains. It won't help you find the authoritative servers for a subdomain of a registered domain (e.g. subdomain.jvns.ca).
It also relies on the registry operating an accurate and reliable whois service. I would not count on that from ccTLDs.
To get complete whois information you need to query the registrar. Whether the whois or DNS is the most up-to-date source for the authoritative DNS servers for a domain seems like an implementation detail at the registrar rather than something you can know in advance. I guess I'm missing something.
I think what the parent is saying is that the nameserver information coming from the registrar’s Whois may not be accurate in any way compared to what is actually in the DNS. The DNS (and, by extension, the authoritative nameservers for a domain) is, by definition, the most up-to-date source for the DNS.
> I’m writing this because if you made a DNS update and it didn’t work, there are 2 options: Your authoritative nameserver doesn’t have the correct record. Your authoritative nameserver does have the correct record, but an old record is cached and you need to wait for the cache to expire
The author is using recursive queries to query authoritative servers, such as the "H" root.1 The whole point of querying authoritative servers directly, versus simply querying a third party DNS cache, (one would think) is to use authoritative nameservers because they are authoritative, not recursive (and they are not subject to TTL issues).
Authoritative servers are not supposed to accept recursive queries (RD bit is 1), they will just ignore the RD bit, and caches are not supposed to accept nonrecursive queries (RD bit is 0). Unfortunately one can find people on the internet who use DNS caches to provide "authoritative" answers. Regardless of the intent of the person using such a configuration (e.g., it could be intended to deceive or it could be merely for "convenience"), AFAICT that is not how DNS was intended to be configured.
For example, djbdns' dnscache properly rejects nonrecursive queries. Unfortunately, large public DNS caches run by third parties like 1.1.1.1, 9.9.9.9 or 208.67.222.222 will accept them. By contrast, 8.8.8.8 will not.
1. There is also the issue of using domainnames for nameservers instead of IP addresses. Doing so means the stub resolver has to do recursive queries to find the IP address of the nameserver. Thus the whole process of using nonrecursive "authoritative servers" actually becomes reliant on a recursive cache. For many folks, that means one that is run by a third party. The cache effectively becomes the source of "authority".
Here is how an example of how to find/check nameservers servers using only authoritative servers (no caches) with a stub resolver such as dig/drill/kdig/dnsq/dq:
#!/bin/sh
test $# = 1||exec echo usage: $0 domainname
# which is the fastest stub resolver. for me dig is much slower than the others. test this yourself
# uncomment the stub resolver to use
#DIG="dig +norecurse";
#DIG="drill -ord";
#DIG="kdig +norecurse";
#DNSQ="dnsq";
#DNSQ="dq -a";
if test "$DIG";then
ns=$($DIG $1 @198.41.0.4 ns|tr '\11' '\40'|sed -n '/ NS /{s/.* //;p;q;}');
nsip=$($DIG $ns @198.41.0.4 a|tr '\11' '\40'|sed -n '/ A /{s/.* //;p;q;}');
$DIG $1 @$nsip ns|tr '\11' '\40'|sed -n '/./{/AUTHORITY SECTION/,/^$/{/ NS /{s/.* //;p;};};}';
exit;
fi;
if test "$DNSQ";then
ns=$($DNSQ ns $1 198.41.0.4|sed -n '/ NS /{s/.* //;p;q;}');
nsip=$($DNSQ a $ns 198.41.0.4|sed -n '/ A /{s/.* //;p;q;}');
$DNSQ ns $1 $nsip|sed -n '/^authority:/{/ NS /{s/.* //;p;};}';
else sed -n '/^ *#DIG/p;/^ *#DNSQ/p;/^ *# uncomment/p' $0;
fi
exit;
198.41.0.4 is the address for the "A" root which I have memorised
People on the internet claim it is impractical to memorise IP addresses
I have found this is not true and knowing some of these numbers can be very useful when troubleshooting. YMMV
Another one I have memorised is 192.5.6.30 which is the "A" com/net nameserver
I can usually remember a 199.19.x.x org nameserver, too, such as 199.19.53.1
The root will return the list of authoritative nameservers, but each of those authoritative servers may have a different list - and that list may still be used for resolution.
For example, if the root says ns1,ns2.example.com are the nameservers for your domain, but ns1.example.com also lists ns3.example.com as an authoritative server, then resolvers WILL query ns3. If ns3.example.com does not actually have authority for your domain (I.e., a lame delegation), then DNS queries for your domain will fail some percentage of the time.
It is valid (though confusing) to extend the list of authoritative nameservers from what the root says. But they had better all actually BE authoritative.
In my experience, this is one of the more common DNS misconfigurations.