5

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.

Community
  • 1
Eddie
  • 183
  • 6
  • 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 00:11
  • possible duplicate of [Is dig +trace always accurate?](http://serverfault.com/questions/482913/is-dig-trace-always-accurate) – Andrew B Jul 23 '15 at 06: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](http://serverfault.com/a/588245/152073) 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 07:07
  • Hi @AndrewB, while your [Q&A](http://serverfault.com/questions/482913/is-dig-trace-always-accurate) was informative, and confirmed the behavior I was seeing, I am more curious as to *why* `dig` behaves that way. What purpose does it solve? Also, I'll read through your [other linked thread](http://serverfault.com/a/588245/152073), which is also something that I had been confused of, so thanks for the link! – Eddie Jul 23 '15 at 13:27
  • 1
    @n1reu The difference between Iterative queries and Recursive queries is explained [here](http://www.slashroot.in/difference-between-iterative-and-recursive-dns-query), or [here](http://www.tcpipguide.com/free/t_DNSBasicNameResolutionTechniquesIterativeandRecurs-4.htm). 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
  • That's something you'd have to take to an ISC mailing list, but the reason most apparent to me would be that they're trying to avoid recursion. The most accurate information on authority comes not from the glue record (the second link touches on that), but from the authoritative servers that were named. Obtaining this information would require a heavy amount of recursion of all names involved in the iterative lookup and it's simpler (and less network intensive) to rely on a recursive nameserver for that. – Andrew B Jul 23 '15 at 13:38
  • 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
  • @AndrewB, ahh well explained. I'm going to leave the Q open for a few days, but if no other answers come in, I'd like to mark your set of answers as the answer. Care to convert them into an Answer so I can give you your due credit? – Eddie Jul 23 '15 at 14:45
  • Sure, no sweat. – Andrew B Jul 23 '15 at 15:10

1 Answers1

0

The official documentation says that dig can use glue records for subsequent queries but may revert to recursive queries if glue records are not provided [1]:

dig may still send queries to the servers listed in /etc/resolv.conf when using +trace When following delegation iteratively as specified with the +trace option, dig will begin by requesting the NS records for the servers authoritative for root ("."). These may or may not be supplied with glue - that is A and AAAA records that can be used for the next queries dig has to send. When there is no glue provided, either on the initial query for the root nameservers, or later on when following delegation, dig will revert to recursively querying the servers listed in /etc/resolv.conf to obtain the needed A/AAAA RRsets.

Specifying @server does not change this behaviour - the server specified in this way will only be queried for the NS records for the servers authoritative for root (".").

It might be wrong documentation or a bug in dig.

[1] https://kb.isc.org/docs/aa-00208

User 714
  • 16
  • 1