1

Okay say you own someSmallSite.com. Its NS nameserver, is say, ns1.hostgator.com. The NS server of Hostgator is ns1.p13.dynect.net. The NS record of that is ns0.dynamicnetworkservices.net which has a same (glue) record of the same domain.

Say someone tries to resolve someSmallSite.com. Since it's a small site, most DNS servers probably have no caches of any of this. So 3 round-trips would have to be made in order to find the actual authoritative DNS server for someSmallSite.com. (resolving ns1.hostgator.com, then ns1.p13.dynect.net and at the end, ns0.dynamicnetworkservices.net which will contain the actual IP address of the DNS server).

If you, instead, make glue records for someSmallSite vs. using the DNS of a shared host (like Hostgator), aren't you avoiding 3 round-trips to resolve the NS record, and then the NS record of the NS record etc, until you finally get the IP address of the DNS server?

If my logic is correct, would this mean that adding a glue record for a small site would be more beneficial in practice, than, say, a big site, which prob has all of these NS servers already resolved in the cache + they are more likely to be on a DNS server which has the IP glue records immediately vs. pointing to another DNS server which points to another etc.

  • What are you trying to optimize for, exactly? Because after the first query starting with cold caches, the resulsts will be the same in both cases, and any negligible difference you might see is irrelevant compared to the time to open a TCP or TLS socket to the final webserver, as a typical usecase. If you instead look at the website you will probably find a couple/dozen of linked CSS and JS files in other domains you may not control, and this will have far more impact on your website total loading time than if you use glue records or not. – Patrick Mevzek Feb 23 '18 at 6:38
2

You are right that adding the glue record (to ns1.somesmallsite.com, for example) would save a few lookups when resolving your site's address.

However, due to DNS caching the difference should be negligible.

Your own glue record

If it's a site with little traffic, it's not likely that the glue record will be cached on any given DNS server, which in turn will incur a slight penalty when a request is made.

With this approach there's a very high chance of doing one lookup for somesmallsite.com NS against the .com authoritative nameservers.

Shared glue record

On the other hand, when your site's NS record is pointed at ns1.hostgator.com, that address is very likely to be cached by DNS servers worldwide, same for ns1.p13.dynect.net, and ns0.dynamicnetworkservices.net, which means those lookups are not repeated each time a query is made for your domain.

Your own domain's NS record is not likely to be in cache, though, due to its relative unpolularity.

There's still a very high chance of doing one lookup for somesmallsite.com NS, plus a small chance of having to do lookups for ns1.hostgator.com, ns1.p13.dynect.net, and ns0.dynamicnetworkservices.net.

  • Thanks for your answer. Aren't you going to end up (probably) with 1 lookup with both cases? In the first case, since the NS records for somesmallsite.com is the same domain (thus the .com DNS will contain an actual glue record containing the IP address of the authoritative server) so that's 1 look-up through the root DNS. In the other case, it's 1 look-up through the root again, until you get to "ns1.hostgator.com", after which (using DNS caching) you get the IP. – daremkd Apr 27 '17 at 16:14
  • Yes, that is the case. On average you will see 1 DNS lookup, the worst-case scenario (nothing in cache) is the one that differs. – André Fernandes Apr 27 '17 at 16:21
1

Theoretically there might be a minor difference, but in practice this doesn't have any huge impact, because

  • You could easily affect this more by using longer TTL. Compare common 84600 with DR 300.
  • DNS queries are cached on every level on recursive DNS servers, & even locally: only one set of queries to authoritative DNS servers occurs, even if there might be a couple of rounds more.
  • DNS packets are tiny: max. payload of < 512 bytes (+ 20 byte IPv4 & 8 byte UDP header).
  • Everything you do after the DNS queries is on a much larger scale in both size and repetitions.

So the question isn't truly practical. You can gain much more for example by removing one background element from the site.

To demonstrate how different factors affects initial page download speed I tested loading the frontpage of Serverfault.com on a computer without any browser cache from a location without cached DNS for the domain. I then analyzed the loading speed with Google Chrome's Timeline tool.

  • DNS queries took a total of 68 ms without cache (and only 4 ms when already cached).
  • It took 457 ms to get the response, i.e. HTTPS connection initiated.
  • Page load and rendering took a total of 941 ms: 59 ms loading, 350 ms scripting, 153 ms rendering, 14 ms painting, 279 ms other and 86 ms idle.

The amount of DNS query round-trips can only have a difference when first visiting the domain. The user experience on this StackExchange site (which I consider pretty light) was that the first page took 1.466 seconds to load. Under 5% of this delay was DNS related. Even if the amount of DNS query time doubles, it wouldn't make any notable difference on UX level, thus not beneficial in practice.

  • Did you read my question? I'm well aware of what glue records are. – daremkd Apr 27 '17 at 13:59
  • The problem is that in the lookup you need to also resolve the NAMESERVERS themselves, since they're too names that need IP addresses, and the nameserver nameservers etc. – daremkd Apr 27 '17 at 13:59
  • I'm truly sorry that I missed your point on the first (and too quick) read. Hopefully this answer is more useful. – Esa Jokinen Apr 27 '17 at 14:19
  • Thanks for the answer. You said DNS queries are cached at every level, but does the caching ends when you get at the chain of root -> root TLD -> appropriate (usually registrar owner) DNS? I can't imagine the root com server doing any caching, I might be wrong though. – daremkd Apr 27 '17 at 16:09
  • I mean that every record, even from com., gets cached on all recursive servers along the path for TTL - and also on local machine. Therefore it results only one query per record (per forwarder). – Esa Jokinen Apr 27 '17 at 16:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.