Knowledge Base ISC Main Website Ask a Question/Contact ISC
Why is the outcome different from dig when using the +trace option?
Author: ISC Support Reference Number: AA-00208 Views: 17656 Created: 2011-03-31 13:07 Last Updated: 2017-02-22 21:46 0 Rating/ Voters

By default dig will use the configured nameservers from /etc/resolv.conf (or one explicitly specified using the command syntax).  Without +trace you are testing the ability of the target nameserver to resolve your query.

Adding the +trace option instructs dig to resolve the query from the root nameservers downwards and to report the results from each query step.  Thus dig will only use the default or explicitly specified nameserver for the initial discovery of the root nameservers. Thereafter it makes its own queries following the delegation referrals it receives.   This can be useful when testing why recursive nameservers are having difficulty obtaining an answer from the Internet authoritative nameservers for a particular query. 

Running "dig @127.0.0.1 +trace" from the nameserver being tested may be more helpful for diagnostic purposes as it will start with the same roots as that nameserver is using.  It may also use the same source IP address - but this should not be assumed.


Interpretation of the outcome of dig +trace requires understanding of the DNS protocol and knowledge of BIND's operation and configuration


The resolution path taken by the nameserver will be dependent on both its configuration and the current status of its cache, whereas dig +trace simply follows the downwards delegation from root as if there was nothing already in cache when commencing iterative resolution.

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






© 2001-2017 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback
  • There is no feedback for this article
Quick Jump Menu