3

Here are my questions:

  • Why does dig +trace ignore the Glue Records?
  • Is this behavior specific to dig or dig +trace, or does a recursive name server also "manually verify" glue records it receives?

Here is the longer explanation:

This is the full capture of the DNS transaction that that prompted these questions.

I am using dig +trace to follow the DNS process for a simple A record resolution for www.pizza.com. As, expected, the first request was to my DNS server, looking for the Root Nameservers (Packet #1). My DNS Server then responds with the list of all 13 Name Servers (Packet #2):

packets 1 and 2

Note that in Packet#2, there are no Additional Records included. Which prompts my client to look up the A record for each of the provided Root name servers. Which happens in packets 3 thru 28:

packets 3 - 28

So far, this is expected. But next it gets interesting.

Packet 29 is my client, making a request to 192.5.5.241 (f.root-servers.net), looking for the A record for www.pizza.com. Obviously, the Root NS doesn't know the A record, so instead provides the .com TLD Name Servers' FQDNs (a.gtld-servers.net, b.gtld-servers.net, etc). Notice, the F Root NS also provides the "Additional Records", which are the A records corresponding to each of the .com TLD Name Server FQDNs:

Packets 29-30

What follows next is what my question revolves around. Even though my client received the A records correlating to the .com TLD name servers. It still decided to make an A record requests for each of the .com TLD name servers (packets 31-56):

Packets 31-56

The same thing happens just a bit further down (packets 57-66) when my client asks the .com TLD name servers for the A record for www.pizza.com, and receives the Authoritative NS records for the Pizza.com domain. The .com TLD Name servers provide the glue records, but my client still goes out and manually resolves each NS server's A record manually.

So my questions are:

  • Why does dig +trace ignore the Glue Records?
  • Is this behavior specific to dig or dig +trace, or does a recursive name server also "manually verify" glue records it receives?

I am using this version of Dig:
DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1

And ran this command:
$ dig www.pizza.com +trace -4


Edit 1: Added questions to the top as well, to make it easier to understand what I am inquiring about


Edit 2: This question is similar to mine, but not exactly the same. In this question, @Andrew B confirms the same behavior I am seeing:

+trace cheated and consulted the local resolver to obtain the IP address of the next hop nameserver instead of consulting the glue.

But my question is specifically why does dig +trace do that? What is the benefit? What is it trying to provide? It seems just like more work, that can sometimes even cause an inaccuracy in how dig resolves an address and how actual DNS resolves an address (as indicated by the other question).

The other question does seem to answer my second question, however. It seems this behavior of ignoring the glue records is specific to dig, and not how a "normal" recursive name server would act.

  • From the manpage: "When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup." I'm not 100% sure on that wording, but I take iterative to mean that each subsequent lookup occurs down the chain which would (at least as I read it) imply that every look up will back check. I could be wrong though =) – jackhamm Jul 23 '15 at 0:11
  • possible duplicate of Is dig +trace always accurate? – Andrew B Jul 23 '15 at 6:59
  • The answers are "because it does ignore glue records" and "it's specific to dig", respectively. The linked Q&A should clear things up. As for what caching DNS servers do specifically, data is overwritten in cache if data is seen from a source considered more trustworthy. This answer might be a good starting point if you want the nitty gritty. (and yeah, before you ask, I self Q&A anything DNS related that confuses either myself or coworkers) – Andrew B Jul 23 '15 at 7:07
  • 1
    @n1reu The difference between Iterative queries and Recursive queries is explained here, or here. Dig +trace is meant to mimic an Iterative query, this I know/understand. But I'm curious as to why it doesn't mimic an iterative query 100%. Because so far as I understand, a true iterative query "trusts" the Glue Records and doesn't try to manually re-resolve them. – Eddie Jul 23 '15 at 13:33
  • 1
    To be more specific: when I say a "heavy amount of recursion", I'm referring to the fact that complete recursion of every nameserver seen in the trace starting from root would be required. +trace is obviously doing simple recursion, but whenever it sees a new server named it has three choices: trust the glue (less authoritative), recurse the new name from scratch every time (a lot of work and a significant number of queries), or rely on a recursive nameserver (a compromise between accuracy and amount of work required). – Andrew B Jul 23 '15 at 14:04

Your Answer

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

Browse other questions tagged or ask your own question.