Today I was presented with an interesting problem; someone changed two MX records in a DNS/BIND in a rush as a stopgap to yet another situation in two of our domains xxx1.pt and xxx2.pt.

As such precautions of diminishing the particular TTL of that record on advance were not observed.

The change was done while under the TTL of 2 weeks.

Interestingly enough, it was pointed to me the Google DNS public servers answers are not all the same.

Testing with still resolves it with with the old address with the odd answer returning the new address.

The SOA serial was updated for sure, as by local procedures/configuration it is automatically updated to prevent people forgetting to do that.

So I was asked why the odd answer, and if something could be done on BIND´s side.

There are also a particular urgency on solving the cache problem on Google side, for reasons not pertinent to this question.

What can I do at BIND side?

  • Providing the names/IP concerned would probably help others to troubleshoot problems... – Patrick Mevzek Jul 27 '17 at 20:45
  • the DNS is public, hiding information clearly makes troubleshooting more complicated, that is all. – Patrick Mevzek Jul 27 '17 at 21:00
  • Some of us might have confidentiality/NDA obligations. – Rui F Ribeiro Jul 28 '17 at 8:02
  • If you are dealing in an enterprise setup you are surely paying people for professional support and they can access your details and help you. – Patrick Mevzek Jul 28 '17 at 8:05
  • The "problem" is solved, I just documented the existence of the Google flush cache functionality. I am the one providing support for them... The "problem" was changing an MX without the proper steps/planning TBH. – Rui F Ribeiro Jul 28 '17 at 8:08

What is obvious here, is that not much can be done on BIND's side.

Having RR records with a TTL of 2 weeks, there is always a risk of having DNS servers out there still having the address in cache.

Google also appears to hint vaguely in some help pages, that it honors long TTLs for at least up to 3 days.

More interestingly the odd answer with the new address might be because a few of the DNS servers on the Google DNS CDN/Cluster might already flushed the cache and got the new address, or might never seen our domain, or might have been provisioned after the change and never seen the old address actually). Or might be because occasionally it is another point of the CDN/another DNS cluster returning the answer. Have not investigated it.

Or getting to the point, it is not particularly surprising having different answers as the DNS service is not served by a single server, and has a complex infra-structure behind it.

As for the cache on Google DNS service side, I located a very interesting page that allows the general public to flush globally arbitrary DNS RR records here


After flushing the MX records cache of the domains in questions manually, the Google public DNS servers were tested again with dig, and the answer was already the new RR data.

|improve this answer|||||
  • Hmmm, but should not there be a synchronization between the cluster members given only one address is exposed to the outer world? – heemayl Jul 20 '17 at 14:01
  • @heemayl I also thought about it, but I do not know, and have not investigated (havent got the time today). It could well be some odd answer from another cluster/in another geographic area; will change the wording slightly. – Rui F Ribeiro Jul 20 '17 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.