6 ms·

How to find a domain's authoritative nameservers

139 points by 0xedb 5y ago

judge2020 5y ago
> 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.
- sigjuice 5y ago
  Running dig without any additional arguments also does the same thing. $ dig ... ;; QUESTION SECTION: ;. IN NS ...
flas9sd 5y ago
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
- agwa 5y ago
  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.
  - flas9sd 5y ago
    thanks for clarifying that I cannot rely on the record
- deleted 5y ago
  [deleted]
great_wubwub 5y ago
"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.
- fennecfoxen 5y ago
  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
- pdonis 5y ago
  > 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.
- agwa 5y ago
  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.
  - ectopod 5y ago
    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.
    - creeble 5y ago
      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
agwa 5y ago
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.
monkaiju 5y ago
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 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
amichal 5y ago
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.
- spoiler 5y ago
  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.
  - amichal 5y ago
    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.
    - spoiler 5y ago
      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
perlgeek 5y ago
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).
zokier 5y ago
> 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.
- winthrowe 5y ago
  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"
- jlgaddis 5y ago
  > 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!
jaseemabid 5y ago
Great post! I find it interesting that all root servers are located in United States. Should some of them be elsewhere for redundancy?
- Godel_unicode 5y ago
  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://www.cloudflare.com/learning/dns/what-is-anycast-dns/ https://labs.ripe.net/author/emileaben/dns-root-server-transparency-k-root-anycast-and-more/ https://labs.ripe.net/author/emileaben/dns-root-server-trans...
theskyo 5y ago
Just want to hightlight that dig's +trace parameter does that automatically.
- 0x0000000 5y ago
  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.
gengear 5y ago
just sharing a browser based tool for it https://dnslookup.online/ns.html https://dnslookup.online/ns.html
- indigodaddy 5y ago
  I like intodns. Does a complete domain/record health check: https://intodns.com/ https://intodns.com/
creeble 5y ago
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.
- citrin_ru 5y ago
  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.
  - jethro_tell 5y ago
    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.
  - bradknowles 5y ago
    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.
TonyRobbins 5y ago
jchw 5y ago
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!)
geocrasher 5y ago
Obligatory DNS Song Link: https://soundcloud.com/ryan-flowers-916961339/dns-to-the-tune-of-let-it-be https://soundcloud.com/ryan-flowers-916961339/dns-to-the-tun...
mattl 5y ago
How does a service like Cloudflare find all the DNS records for a domain name?
- Operyl 5y ago
  Brute force. There’s a lot of services that help provide this now.
  - mattl 5y ago
    Can you name another?
    - Operyl 5y ago
      https://securitytrails.com/dns-trails https://securitytrails.com/dns-trails
anon776 5y ago
Fun fact, you can do the same for an IP address (reverse entry) by doing > dig -x some_ip_address
julienpalard 5y ago
Shameless plug : I wrote a tool to watch DNS updates at the authoritative nameserver : https://github.com/JulienPalard/dnswait https://github.com/JulienPalard/dnswait DNS propagation is a lie!
- Operyl 5y ago
  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.
runlevel1 5y ago
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_Protocol https://en.wikipedia.org/wiki/Extensible_Provisioning_Protoc... [2]: https://www.rfc-editor.org/rfc/rfc5731.txt https://www.rfc-editor.org/rfc/rfc5731.txt
- tankenmate 5y ago
  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 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 https://en.wikipedia.org/wiki/Sponsored_top-level_domain [2] https://www.igoldrush.com/domain-guide/domain-name-basics/tld-gtld-stld-utld-cctld https://www.igoldrush.com/domain-guide/domain-name-basics/tl... [3] https://en.wikipedia.org/wiki/Country_code_top-level_domain https://en.wikipedia.org/wiki/Country_code_top-level_domain
1vuio0pswjnm7 5y ago
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
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]

139 points by 0xedb 5y ago

judge2020 5y ago

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

sigjuice 5y ago
Running dig without any additional arguments also does the same thing. $ dig ... ;; QUESTION SECTION: ;. IN NS ...

flas9sd 5y ago

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

agwa 5y ago
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.
- flas9sd 5y ago
  thanks for clarifying that I cannot rely on the record
deleted 5y ago
[deleted]

great_wubwub 5y ago

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

fennecfoxen 5y ago
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
pdonis 5y ago
> 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.
agwa 5y ago
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.
- ectopod 5y ago
  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.
  - creeble 5y ago
    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

agwa 5y ago

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.

monkaiju 5y ago

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

amichal 5y ago

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.

spoiler 5y ago
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.
- amichal 5y ago
  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.
  - spoiler 5y ago
    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

perlgeek 5y ago

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

zokier 5y ago

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

winthrowe 5y ago
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"
jlgaddis 5y ago
> 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!

jaseemabid 5y ago

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

Godel_unicode 5y ago
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://www.cloudflare.com/learning/dns/what-is-anycast-dns/ https://labs.ripe.net/author/emileaben/dns-root-server-transparency-k-root-anycast-and-more/ https://labs.ripe.net/author/emileaben/dns-root-server-trans...

theskyo 5y ago

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

0x0000000 5y ago
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.

gengear 5y ago

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

indigodaddy 5y ago
I like intodns. Does a complete domain/record health check: https://intodns.com/ https://intodns.com/

creeble 5y ago

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.

citrin_ru 5y ago
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.
- jethro_tell 5y ago
  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.
- bradknowles 5y ago
  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.

TonyRobbins 5y ago

jchw 5y ago

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

geocrasher 5y ago

Obligatory DNS Song Link: https://soundcloud.com/ryan-flowers-916961339/dns-to-the-tune-of-let-it-be https://soundcloud.com/ryan-flowers-916961339/dns-to-the-tun...

mattl 5y ago

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

Operyl 5y ago
Brute force. There’s a lot of services that help provide this now.
- mattl 5y ago
  Can you name another?
  - Operyl 5y ago
    https://securitytrails.com/dns-trails https://securitytrails.com/dns-trails

anon776 5y ago

Fun fact, you can do the same for an IP address (reverse entry) by doing > dig -x some_ip_address

julienpalard 5y ago

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

Operyl 5y ago
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.

runlevel1 5y ago

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_Protocol https://en.wikipedia.org/wiki/Extensible_Provisioning_Protoc... [2]: https://www.rfc-editor.org/rfc/rfc5731.txt https://www.rfc-editor.org/rfc/rfc5731.txt

tankenmate 5y ago
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 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 https://en.wikipedia.org/wiki/Sponsored_top-level_domain [2] https://www.igoldrush.com/domain-guide/domain-name-basics/tld-gtld-stld-utld-cctld https://www.igoldrush.com/domain-guide/domain-name-basics/tl... [3] https://en.wikipedia.org/wiki/Country_code_top-level_domain https://en.wikipedia.org/wiki/Country_code_top-level_domain

1vuio0pswjnm7 5y ago

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

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]