Azure Traffic Manager Browser Caching Issue

Question

In Azure's traffic manager, I am doing some testing with TWO failover URLs: Two different endpoints are configured for the traffic manager (failover1.mysite.com, failover2.mysite.com.), however, my local browser (Chrome for example) seems to be caching the DNS record on its own and redirecting to what it thinks is still the destination, rather than letter Azure Traffic Manager re-route. Trying the request in a new browser or Incognito session will result in the request reaching the correct site. But for existing sessions, failover updates are not being registered and still hitting the site we are trying to redirect traffic away from. Does anyone have any experience with this?

Goldenrod

Any chance you found any solution ?? :P Im facing the exact same problem :/ – Signal

We are having a similar problem in that CORS requests get bound to a "down" site and ignores the "up" endpoint. No amount of refreshing or cache clearing or new tabs fixes it. We actually have to close down all instances of Chrome before it goes to the "up" endpoint. It is almost as if it caches the files responses indefinitely. Other browsers are not doing the same. – Thresathresh

Answer 1

I had the same issue while I was dealing with Azure Traffic Manager or AWS CloudFront.

DNS Record is associated with its TTL value. It is not something wrong with the Azure Traffic Manager. It is the TTL value that is letting the DNS client to cache the IP address.

How to check TTL value of DNS:

If you are using Windows,

https://support.rackspace.com/how-to/nslookup-checking-dns-records-on-windows/

If you are using linux follow the detailed instructions here,

https://www.cyberciti.biz/faq/howto-use-dig-to-find-dns-time-to-live-ttl-values/

Hope it helps.

Sarcoid

Thanks, I appreciate that each individual client device can be flushed or configured, but that defeats the purpose in many ways. Customers are getting stuck on one site that is now down because their browser/OS is caching, and it's impossible for us to contact hundreds of unknown web visitors to take them through a DNS cleansing process. – Goldenrod

TTL is configured in your DNS Server Record, not on client machines. Clients respect the TTL configured in your DNS Server. Looks like you misunderstood that TTL is configured in clients machine / browser. – Sarcoid

TTL is configured in traffic manager to 10 seconds, clients are not honouring this. – Goldenrod

You can verify the TTL using the above links. If you have just changed and waiting for it to propagate, then old TTL might be in effect. – Sarcoid

Old/Default TTL was 300 seconds. This time has passed several times since testing begun 2 days ago, thank you anyway, appreciate it. – Goldenrod

Answer 2

From Microsoft's overview of their load balancing services:

Traffic Manager is a DNS-based traffic load balancer [...] it load balances only at the domain level. For that reason, it can't fail over as quickly as Front Door, because of common challenges around DNS caching and systems not honoring DNS TTLs.

With Front Door you can route requests to different backends based on rules and/or the health of the backends themselves so it doesn't have the issue you describe.

Et