2

Note: I'm aware of glue records and that DNS servers use them only in case the ns server domain is the same as the domain for which you sent the query.

Now my question was: Say you have example.com which has ns1.example.org (a different domain than example.com) as its NS record. At some point, the resolver will need to also resolve and find the IP address for ns1.example.org. My question is, HOW does it do that (without a glue record)?

My guess is that it starts the process over again, first going to the root DNS, then to the .org DNS, then it reaches the nameservers for example.org...but wait, do nameservers have nameservers? If yes, then this would end up in a big endless loop, because now you'll need to find the NS records for example.org and go there etc.

My point is, these IP addresses for the name servers MUST be stored somewhere. I've heard people say that glue records are only used if say you have example.com and its NS servers are ns1.example.com, same domain. If it's a different domain, then I've read there's a resolution of that domain in order to find the IP...but this implies that nameservers like ns1.example.org have their own nameservers which really makes no sense.

HBruijn
  • 72,524
  • 21
  • 127
  • 192
daremkd
  • 139
  • 4

3 Answers3

3

Delegation to a name server in a different domain really doesn't change much - it's just making the resolver do more legwork.

In the example you provide, the example.org domain must be functional for the example.com name to successfully resolve - why wouldn't it have its own functioning name servers, or glue records?

The infinite-loop failure scenario you seem to be imagining would only come into play if you created an impossible delegation loop, like if you tried to delegate ns1.example.org back to a name server under example.com.

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • Well let's continue with the chain. Let's say example.org has 'ns1.example.info' as its nameserver. Now let's say example.info has 'example.cc' as its nameserver...and let's say this continues with 10 more domains until we finally get to a domain like example.tv which has a glue record. So, in order to obtain example.com, did the server needed to do 10+ lookups? – daremkd Apr 24 '17 at 15:45
  • 1
    @daremkd Yes, assuming that there was nothing cached already about those domains. You can make an arbitrarily long chain of delegation, though in practice it's limited by the amount of time a resolving client will spend on following the delegation chain for a single request, usually a couple seconds. – Shane Madden Apr 24 '17 at 16:52
  • that's interesting. Considering that a smaller website, let's say you own smallSite.com, is on a shared host, say on "ns1.hostgator.com" which is itself pointing to ns1.p13.dynect.net, which is pointing to ns0.dynamicnetworkservices.net, which FINALLY has a glue record, that's going through 3 different nameserver resolutions. And considering it's a small site, I'm assuming most DNSes don't have much cached about it. So by creating a glue DNS record for that small site, wouldn't the resolution be much faster? You're avoiding travelling 3 times. – daremkd Apr 24 '17 at 22:15
  • The limitations are both at the client level (timeout) and server level. Even if the client times out, the server side of this transaction will not abort, as it has no knowledge of what the client's timeout settings are. The server will continue to follow the referrals so that it will have all of the necessary information in cache for the next query. The server software is responsible for determining the maximum recursion depth it is willing to follow. To give you an idea of how crazy it gets, [even 75 recursion levels can be too few on an empty cache](https://serverfault.com/a/690472/152073). – Andrew B Apr 24 '17 at 22:27
1
  • The resolver wants the IP of www.example.com (query "A www.example.com.")
  • it is not cached, hence it needs to ask a DNS server that is authoritative for example.com
  • not having any better idea it asks one of the pre-configured root servers
  • Instead of a final reply, we are informed about the autoritative servers for com., such as a.gtld-servers.net; even though these are not under com, the root servers add in glue records; hence we know the ip of a.gtld-servers.net
  • So we ask our question "A www.example.com" to a.gtld-servers.net
  • Again, a.gtld-servers doen's know the answer, but tells us that ns.example.org is responsible; typically, there would be glue records at this point, but let's assume that this i not the case
  • We start a sub-query "A ns.example.org"
  • As above, the root servers lead us to DNS servers for org., such as a0.org.afilieas-nst.info; in a bad world, we'd have to start the game all over to locate this guy, but at this level, we do obtain glue records
  • So we can ask a0.org.afilieas-nst.info for ns.example.org
  • We learn that we should ask a.iana-servers.net about example.org, but unfortunately without glue
  • So we ask the root servers (because we meanwhile learned about com. and org., but not yet about net.)
  • The reply tells us that e.g. a.gtld-servers-net is responsible for net. and we also obtain glue, but we already knew ip of a.gtld-servers.net
  • We ask a.gtld-servers.net "A a.inana-servers.net" and learn the NS records for iana-servers.net; three of them are within iana-servers.net (and come with glue) and a fourth server is ns.icann.org
  • For some stupid reasin, we ignore the glue records (or maybe thise name servers are unreachable) and thus need to resolve ns.icann.org; well, we know already that we should query a0.org.afilieas-nst.info for "A ns.icann.org"
  • Intiguingly, the returned name servers are the same as above: three from icann-servers.net and ns.icann.org itself; this time ns.icann.org comes with glue
  • So now we knwo the ip of ns.icann.org and can ask it "A a.iana-servers.net" and obtain its address
  • So now we can at last ask a.iana-servers.net for "A ns.example.org" and obtain an ip (well, not in reality, or course)
  • We can ask ns.example.org under that ip for "A www.example.com" and finally solved our original problem

In the course of this, we learned lot about sevral important zones, such as com, net, and org. By caching this info, our next queries wil take a lot less detours ...

Hagen von Eitzen
  • 816
  • 3
  • 15
  • 41
  • Are you saying that when you do "A ns.someDomain.com", which is registered as a nameserver, the root .com always gives you the glue records? – daremkd Apr 24 '17 at 15:55
0

You're right on that the IP addresses of the name servers are stored somewhere - you can't resolve any FQDN without a DNS. That's why you have the IP addresses in your network configuration, and not their names.

The root DNS servers are referred by their IP addresses configured in each DNS server. So, when a DNS server gets a query for a domain name it doesn't knows, it

  1. queries its configured DNS
  2. queries the root DNS, which will not answer the respective IP but which name server(s) handles the root domain name (say, .com) and then that name server could answer which name server handles the particular domain (say, nasa.com)

You can do some exploration doing a tracing request with:

dig +trace www.google.com
niglesias
  • 210
  • 1
  • 8