This post is missing what is a very common DNS mis-configuration: extra, and/or lame delegations.<p>The root will return the list of authoritative nameservers, but each of those authoritative servers may have a <i>different</i> list - and that list may still be used for resolution.<p>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.<p>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.<p>In my experience, this is one of the more common DNS misconfigurations.
> h.root-servers.net is one of the 13 DNS root nameservers,<p>You can also find all current root nameservers by running<p><pre><code> dig ns .
</code></pre>
Since all domains end with a terminating '.' / are descendants of the DNS root '.', even though browsers obscure it.
Speaking as someone who has debugged a considerable number of DNS problems, recurring from the root as described in the post is the <i>only</i> 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.<p>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).
Shameless plug : I wrote a tool to watch DNS updates at the authoritative nameserver : <a href="https://github.com/JulienPalard/dnswait" rel="nofollow">https://github.com/JulienPalard/dnswait</a><p>DNS propagation is a lie!
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).<p>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].<p>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.<p>[1]: <a href="https://en.wikipedia.org/wiki/Extensible_Provisioning_Protocol" rel="nofollow">https://en.wikipedia.org/wiki/Extensible_Provisioning_Protoc...</a>
[2]: <a href="https://www.rfc-editor.org/rfc/rfc5731.txt" rel="nofollow">https://www.rfc-editor.org/rfc/rfc5731.txt</a>
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.
> 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.<p>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.
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.)<p>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.<p>(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.<p>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.<p>Using dug (<a href="https://github.com/unfrl/dug" rel="nofollow">https://github.com/unfrl/dug</a>) 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
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
"whois jvns.ca<p>This will usually give you the right answer, but it might be an old cached version."<p>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.
just sharing a browser based tool for it <a href="https://dnslookup.online/ns.html" rel="nofollow">https://dnslookup.online/ns.html</a>
Obligatory DNS Song Link:
<a href="https://soundcloud.com/ryan-flowers-916961339/dns-to-the-tune-of-let-it-be" rel="nofollow">https://soundcloud.com/ryan-flowers-916961339/dns-to-the-tun...</a>
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).<p>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.<p>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.<p>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".<p>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:<p><pre><code> #!/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</code></pre>