I would like to find out the authoritative name-servers for swedbank.se domain. I queried few caching name-servers for swedbank.se and while some answered the authoritative name servers, then others did not. For example Google public DNS servers:
$ dig @8.8.8.8 swedbank.se +noall +authority
; <<>> DiG 9.6.1-P1 <<>> @8.8.8.8 swedbank.se +noall +authority
; (1 server found)
;; global options: +cmd
$ dig @isp-nameserver swedbank.se +noall +authority
; <<>> DiG 9.6.1-P1 <<>> @isp-nameserver swedbank.se +noall +authority
; (1 server found)
;; global options: +cmd
swedbank.se. 2719 IN NS ns2.foreningssparbanken.se.
swedbank.se. 2719 IN NS ns1.foreningssparbanken.se.
swedbank.se. 2719 IN NS ns3.foreningssparbanken.se.
$
Is this just a matter of caching name-server configuration? Or is there some other reason for such behavior?
The most precise answer is "when required to by RFC, and a few other cases besides".
The only times you are guaranteed to see an AUTHORITY section is when the remote server is replying with zero records in the ANSWER section (and even then, only when the rcode is NOERROR or NXDOMAIN). The most common cases I know of are:
RD
(recursion desired) flag set when the record is not in cache. Using dig, this would be accomplished via the+norecurse
option.Outside of the circumstances required by RFC, what you will get in that field is implementation specific and unreliable. Some nameserver software provide options for not serving up this data except when required to by RFC, which is useful to reduce the per-reply packet size in amplification attack scenarios. An example of this is BIND9's
minimal-responses
option.In short, unless a referral or NXDOMAIN is involved you should consider the data in the AUTHORITY section as a convenience factor only. When writing code that analyzes DNS replies, I only look at the AUTHORITY section if the rcode was NOERROR with zero records in the ANSWER section.