using the examples below

dig +trace stackoverflow.com dig +trace google.com

dig +trace yahoo.com dig +trace bbc.com

the first two show me only the A records for the queried domain, while the last two show me the A, or CNAME, as well as multiple NS records.

Can someone explain what config on the DNS server controls this behaviour, causing all of your nameservers being sent in response to this type of dig lookup. Also, is it possible to disable this behaviour so in the first two examples.. so that only the A record is sent and not the authoritative nameservers as well?

I would like to sync my domain with UltraDNS and configure the domain to use their nameservers to avoid DNS DDoS attacks on our DNS servers. But with the above behaviour, when people 'dig +trace' the domain it replies with our nameservers so making the exercise of trying to hide them pointless.

thanks fLo

  • On my computer, all the queries you put as example have the same behavior: the one describe in the manpage. it prints all necesssary RR to trace the delegation path. This path include NS records in all cases.
    – Manu H
    Oct 8, 2014 at 7:11

2 Answers 2


The difference is that yahoo.com and bbc.com are returning an AUTHORITY section, but stackoverflow.com and google.com are not.

$ dig @ns1.yahoo.com +noall +question +authority yahoo.com
;yahoo.com.                     IN      A
yahoo.com.              172800  IN      NS      ns2.yahoo.com.
yahoo.com.              172800  IN      NS      ns6.yahoo.com.
yahoo.com.              172800  IN      NS      ns5.yahoo.com.
yahoo.com.              172800  IN      NS      ns4.yahoo.com.
yahoo.com.              172800  IN      NS      ns3.yahoo.com.
yahoo.com.              172800  IN      NS      ns1.yahoo.com.
$ dig @ns1.google.com +noall +question +authority google.com
;google.com.                    IN      A

You could hide this from your trace with the +noauthority option, but it would also make the output largely useless as you would be hiding the AUTHORITY section from the intermediate nameservers as well. (which, being delegations, is pretty much all there is to be seen unless you've set +additional)

It is up to individual nameserver implementations whether or not they wish to supply an AUTHORITY section in scenarios where they are not strictly required by RFC. BIND is one of the server implementations that does display this information by default, but it also provides a minimal-responses option for disabling the behavior. I strongly recommend this option in customer facing recursion scenarios as it reduces the overhead of amplification attacks against spoofed source IPs. (sadly, BCP 38 is not as widely implemented as it needs to be)

From the BIND ARM:

If yes, then when generating responses the server will only add records to the authority and additional data sections when they are required (e.g. delegations, negative responses). This may improve the performance of the server. The default is no.


With +trace, dig will go ahead and query the actual nameservers of the domain. So the response you're seeing is not from your local DNS resolver, but rather from the actual 'masters' of the domain.

If we look at google.com and yahoo.com, we use ns1.google.com and ns1.yahoo.com as nameservers respectively. Querying google's nameserver for Google.com will reveal 12 A records with IP's, while querying yahoos nameserver for Yahoo.com will reveal 3 A records, 6 NS records and some more.

There is no need to use +trace. You can query the servers directly using a combination of dig ns yahoo.com (to find nameservers) and then dig @ns1.yahoo.com yahoo.com (to query the domain using ns1.yahoo.com).

This behaviour is determined by the DNS server in question. For example, if I query google.com through a Windows DNS server, I will get only the A records, but if I do the same through a local BIND instance, I will get a plethora of authority records. This question, DNS answer with/without authority, additional sections, touches on the same topic, but they also haven't found a setting that controls it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .