2

Why do the DNS records authoritative name servers frequently give different results than cached name servers if "ANY" records are requested?

The authoritative name servers seem to consistently provide more records than the cache--for example returning MX or TXT records when the caching name server will only return these records if they are explicitly requested.

For example, on my home (OS X) system, the difference between the following two commands

$ dig -t ANY +noall +nottl +answer microsoft.com
$ dig -t ANY +noall +nottl +answer microsoft.com @ns1.msft.net

is that the first only returns the NS records; the second adds in MX, SOA and TXT. However on a separate Linux system, with a completely different DNS setup, the only records "missing" are MX and SOA.

Improve this question
1

1 Answer 1

Reset to default
4

You're hiding the answer from yourself with the dig options that remove information from the output, specifically TTL in this case.

If we look at the full answer section:

;; ANSWER SECTION:
microsoft.com.          3600    IN      A       23.96.52.53
microsoft.com.          3600    IN      A       191.239.213.197
microsoft.com.          3600    IN      A       104.40.211.35
microsoft.com.          3600    IN      A       104.43.195.251
microsoft.com.          3600    IN      A       23.100.122.175
microsoft.com.          172800  IN      NS      ns3.msft.net.
microsoft.com.          172800  IN      NS      ns4.msft.net.
microsoft.com.          172800  IN      NS      ns1.msft.net.
microsoft.com.          172800  IN      NS      ns2.msft.net.
microsoft.com.          3600    IN      SOA     ns1.msft.net. msnhst.microsoft.com. 2016020503 7200 600 2419200 3600
microsoft.com.          3600    IN      MX      10 microsoft-com.mail.protection.outlook.com.
microsoft.com.          3600    IN      TXT     "v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com ip4:147.243.128.24 ip4:147.243.128.26 ip4:147.243.1.153 ip4:147.243.1.47 ip4:147.243.1.48 -all"
microsoft.com.          3600    IN      TXT     "FbUF6DbkE+Aw1/wi9xgDi8KVrIIZus5v8L6tbIQZkGrQ/rVQKJi8CjQbBtWtE64ey4NJJwj5J65PIggVYNabdQ=="

We can see that not all records have the same TTL, which in turn means they will be evicted from the cache of the caching resolver server at different times.

This in combination with how the ANY query type was defined means that it's quite possible (and valid) to get only what is currently left in the cache as the response.

As a result of this behavior, QTYPE * aka ANY isn't to be relied on for an accurate listing of all records if there are caching servers involved. It's mostly useful in troubleshooting (and, I would only consider it useful even then if you have a good understanding of what ANY means).

Improve this answer
3
  • Thanks, this is helpful, although it doesn't explain why specifically asking the cache for the "missing" records, and then immediately requesting ANY doesn't seem to help. Why doesn't the cache get populated in this case?
    – ithinkihaveacat
    Feb 6, 2016 at 12:33
  • 2
    @ithinkihaveacat I'd expect the ANY query results to have a cache entry of its own. I'll try to work this into the answer later today, preferably with a source.
    – Håkan Lindqvist
    Feb 6, 2016 at 12:40
  • @ithinkihaveacat I'd expect that to work, actually. Are you sure that the recursor IP in question doesn't involve a load balancer? You would need to run the cache priming query several times for it to be on multiple servers in the farm. (or just keep asking until you hit the server that you primed)
    – Andrew B
    Feb 6, 2016 at 19:33

You must log in to answer this question.

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