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.
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.
dig
nothost
for debugging. And always specify explicitly which nameserver you queryAnd 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:
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.