2

I have recently changed the IP address for a particular domain, call it example.com. I know that it takes time for the DNS change to propagate, and it's still early enough that the propagation is not complete.

I've noticed that running an ANY query gives different results from running an A-record query. For example ...

% host -t a example.com
example.com has address THE.OLD.IP.ADDRESS
% host -t any example.com
example.com has address THE.NEW.IP.ADDRESS

I know that eventually, the DNS will fully propagate, and the A-record query will then return THE.NEW.IP.ADDRESS. But I'm wondering if someone could explain why an ANY query returns the new IP address, while the A-record query still returns the old IP address, until the propagation is complete.

This matters to me because application software that resolves domain names seem to do the equivalent of the A-record query and not the ANY query, and therefore, those applications still resolve the IP address to the old value until DNS propagation is complete.

I'm just looking for an explanation for why ANY results seem to propagate more quickly than A-record results ... this is for my own understanding and edification.

Thank you very much.

HippoMan
  • 165
  • 8
  • 2
    Possible duplicate of [Why does DNS work the way it does?](https://serverfault.com/questions/355887/why-does-dns-work-the-way-it-does) – Jenny D Aug 11 '17 at 15:39
  • I understand how DNS works the way it does, and the referenced post doesn't explain how an ANY query is handled differently from an A-record query. But the answer below provides the info I'm asking for. – HippoMan Aug 11 '17 at 15:59
  • 1
    The duplicate explains how DNS **caches** work. What's happened is that the A record was in your resolver's cache, but in order to check for ANY records, it needed to contact the authoritatie server. (There is no such thing as DNS **propagation**; that's a fundamental misunderstanding of how DNS works.) – Jenny D Aug 11 '17 at 16:14
  • Well, data does get "propagated" from the authoritative server to the various caches all over the world, but I know that this gets done by each cache querying the authoritative server. In other words, I realize that this is a "pull" from each cache and not a "push" from any server. – HippoMan Aug 11 '17 at 16:32

3 Answers3

1

It looks like that the 'ANY' record query is being reponded to by the authoritative DNS server which has the new IP while the 'A' record Query is being responded to by other recursive DNS servers where the new ip address propagation is still pending and hence returns the old ip address because thats the information it has in its cache.

sridhar pandurangiah
  • 743
  • 2
  • 11
  • 28
  • I guess the only explanation for this is that the "host" command (as well as the "dig" command) is written to specifically query the authoritative server when ANY is specified, but that it resolves specific record queries (A-record, MX-record, etc.) from the current cache. – HippoMan Aug 11 '17 at 16:03
  • @HippoMan In the `dig` output you will see that it does NOT query a different server when you change the qtype to `ANY`. However, a plausible explanation for the observed results is that there was not yet any cached result for an `ANY` lookup, while there was for an `A` lookup. – Håkan Lindqvist Aug 15 '17 at 20:36
1
  1. Give the true name involved, otherwise it is impossible to troubleshoot your problem. And use dig not host for debugging. And always specify explicitly which nameserver you query
  2. ANY is not a true record, it just asks the resolver to send back everything it has in its cache for the given name; thus it is a very poor debugging tool as the result will completely depend on the resolver queried; for some reason some people want to completely deprecate it
  3. So ANY records do not "propagate"
  4. In fact no record propagates at all since the DNS is not top down. It is a term used everywhere but this poorly reflect the reality.

And now at least since 2019-01-10 with RFC 8482 "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY", nameservers are free to "defuse" ANY requests and reply with minimum data (either any subset of records they deem appropriate, or with just one HINFO record).

See this lovely example from Cloudflare:

$ dig @ns7.cloudflare.com cloudflare.com ANY +noall +ans
cloudflare.com.     1h3m9s IN HINFO "RFC8482" ""
Community
  • 1
Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
0

The output of dig helps in circumstances like this, as we're missing other details such as the TTL associated with both queries.

I find it unlikely that ANY is resulting in a different behavior. Regardless of the query type used, the individual records in cache will have different TTLs associated with them, and there is no difference in the two queries that will prompt the server to update its cached value. If anything, ANY will typically result in answers for specific record types being omitted if they are not currently in cache. (i.e. expired)

More than likely your queries are being directed at a load balanced DNS cluster and some of your queries are landing on a server where the TTL from the old answer has expired, and others are landing on servers that still have the record in cache. An easy way to verify this in the future is to pay attention to the TTL returned by the remote server. If it is not consistently de-incrementing in seconds based on real world time, you are seeing TTL values coming from different servers.

Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • I've run my tests literally dozens of times today, and each and every "ANY" request always returns the new IP address, and each and every "A" request always returns the old IP address. I doubt that a load-balancing algorithm would check between ANY queries and queries for specific record types. – HippoMan Aug 11 '17 at 18:06
  • The TTL is the pertinent detail here. If there is a non-zero TTL in the `ANY` responses, the `A` request should not result in a refresh. (unless there's a more significant change in the background that hasn't been disclosed here, such as the `NS` records changing either in the authoritative zone or at the parent nameservers) – Andrew B Aug 11 '17 at 18:09
  • I'm not sure I completely understand. Are you saying that `ANY` queries and `A` queries behave differently w/r/t TTL, and that could be what is causing this discrepancy? – HippoMan Aug 11 '17 at 18:25
  • @HippoMan The opposite: if there was a positive TTL in the answer section for this particular qname+qtype combination, that value should have come from cache. An explicit lookup for qtype `A` should not have resulted in a refresh barring extenuating circumstances (a change that invalidated the entire zone, such as repointed NS records) or an interesting custom behavior within the nameserver software. [We can work out the details more in chat if you'd like](https://chat.stackexchange.com/rooms/info/63678/discussion-between-hippoman-and-andrewb). – Andrew B Aug 11 '17 at 18:30
  • Sure. I'll check in chat a little later. I have to catch a bus in a few minutes. :) Thanks. – HippoMan Aug 11 '17 at 18:32