How to find a domain's authoritative nameservers | Hacker News Reader

How to find a domain's authoritative nameservers

jvns.ca

139 points0xedb46 comments

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.

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.

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.

> h.root-servers.net is one of the 13 DNS root nameservers,

You can also find all current root nameservers by running

  dig ns .

Since all domains end with a terminating '.' / are descendants of the DNS root '.', even though browsers obscure it.

Running dig without any additional arguments also does the same thing.

  $ dig
  ...
  
  ;; QUESTION SECTION:
  ;.    IN NS
  
  ...

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

Shameless plug : I wrote a tool to watch DNS updates at the authoritative nameserver : https://github.com/JulienPalard/dnswait

DNS propagation is a lie!

It’s not a complete lie, for some of the big registrar nameservers they do have an internal propagation delay. It sucks, but it exists.

Just want to hightlight that dig's +trace parameter does that automatically.

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.

[1]: https://en.wikipedia.org/wiki/Extensible_Provisioning_Protoc... [2]: https://www.rfc-editor.org/rfc/rfc5731.txt

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.

[0] https://en.wikipedia.org/wiki/Generic_top-level_domain (although some domains listed as gTLDs by Wikipedia would be better categorised as uTLDs) [1] https://en.wikipedia.org/wiki/Sponsored_top-level_domain [2] https://www.igoldrush.com/domain-guide/domain-name-basics/tl... [3] https://en.wikipedia.org/wiki/Country_code_top-level_domain

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.

Trace output was easier to read in the days when everybody trusted and there was no security.

Try reading this, with just the tool output, A and NS records, like the old days:

dig +trace jvns.ca | egrep ";|IN\s+A|IN\s+NS\s"

> I always find its output baffling.

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

Great post! I find it interesting that all root servers are located in United States. Should some of them be elsewhere for redundancy?

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.

https://www.cloudflare.com/learning/dns/what-is-anycast-dns/

https://labs.ripe.net/author/emileaben/dns-root-server-trans...

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.

thanks for clarifying that I cannot rely on the record

Fun fact, you can do the same for an IP address (reverse entry) by doing

> dig -x some_ip_address

How does a service like Cloudflare find all the DNS records for a domain name?

Brute force. There’s a lot of services that help provide this now.

Can you name another?

https://securitytrails.com/dns-trails

"whois jvns.ca

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.

yes?

> 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

> Who changes authoritative nameservers for a domain?

Anyone who has just bought a domain, or anyone who is changing their hosting to a new provider.

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.

Edit: registrar’s whois

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

One of the primary times I'm interested in doing DNS queries carefully is when I updated my authoritative nameserver.

What I'm wondering is how whois data is cached. Anyone have a reference on how that works in practice?

just sharing a browser based tool for it https://dnslookup.online/ns.html

I like intodns. Does a complete domain/record health check:

https://intodns.com/

Obligatory DNS Song Link: https://soundcloud.com/ryan-flowers-916961339/dns-to-the-tun...

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

Reply on news.ycombinator.com