2007-07-06
What the flags on DNS query responses mean
Responses from DNS servers come with various useful and informative flags. Since I just looked them up while figuring out just what was going on with a peculiar nameserver, I'm going to write it down for my future reference.
qr |
Yes, this is really a DNS response that dig
is printing. |
aa |
The server is authoritative for the domain. |
rd |
You asked for recursive resolution of your query. |
ra |
The server is willing to do recursive queries for you. |
tc |
The response was truncated because it was too big to fit in a UDP packet. |
These come from RFC1035 section 4.1.1, which is worth reading in full (it's short).
Every nameserver for a domain should be an authoritative server for the
domain and so its responses about the domain should always have the aa
bit set. These days, seeing ra from a domain's nameserver should make
you nervous, especially if the nameserver does not report itself as
authoritative (ie, doesn't set aa).
(Real secondary servers for a domain are authoritative for the domain
and know it, even though they do not hold a permanent local copy of
the domain's DNS records. Informal secondaries, where you just list a
nameserver that will do recursive queries for the Internet as one of
your NS records, are not authoritative and will not set aa on replies.
Yes, people really do that.)
How not to set up your DNS (part 15)
This is one of those interesting little DNS glitches:
- the nameservers for the pk country domain say that gem.net.pk lists as nameservers sooraj.gem.net.pk and chand.gem.net.pk.
- if you ask sooraj what gem.net.pk's nameservers are, it gives you a non-authoritative reply saying that they are sooraj, chand, and ns1.gem.net.pk.
- ns1.gem.net.pk doesn't respond.
- if you ask chand what gem.net.pk's nameservers are, you sometimes get a reply without any actual data but with an 'additional authority' section that says that chand and sooraj are the nameservers, as if chand wasn't actually an authoritative nameserver for gem.net.pk.
The net result seems to be that every so often, our nameservers can't resolve anything to do with gem.net.pk because they have decided to query chand and have gotten answers back that make them throw up their hands in disgust.
What seems to be going on is that sooraj and chand are actually general recursive nameservers (for example, neither claim to be authoritative on any answers) that can also talk to ns1, which is presumably an internal-only machine. For some reason sooraj has a local copy of the data (for example, its TTLs on gem.net.pk results never count down) but chand does not; if you query chand during a time when it doesn't have things in its cache, you get useless results.