Why is the outcome different from dig when using the +trace option?
- 07 Sep 2018
- 1 Minute to read
-
Contributors
-
Print
-
DarkLight
-
PDF
Why is the outcome different from dig when using the +trace option?
- Updated on 07 Sep 2018
- 1 Minute to read
-
Contributors
-
Print
-
DarkLight
-
PDF
Article Summary
Share feedback
Thanks for sharing your feedback!
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 configurationThe 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 +traceWhen 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 (".").