0

I have latency based DNS rules in AWS Route53 (with TTL set up to 60 seconds) pointing to AWS NLB located in various regions. I would like to have a possibility of redirecting traffic to other regions modifying Route53 rules and to be sure DNS failover policy will work for all clients.

I've heard that even though Route53 propagation time is fairly ok, it might not be respected by various Internet Service Providers doing their own caching and/or simply ignoring my TTL rules (even up to couple of days).

Is that statement true? Given the fact I need to make sure my routing changes should be propagated within 15m am I safe with using Route53, or should I implement mechanism allowing my client app to obtain my server address dynamically (rather than changing routing).

3

DNS propagation does not exist, it is incorrect terminology as DNS is not top down, but just governed by caches renewing their entries based on TTLs on records (and other more complicated rules, like DNSSEC RRSIG expirations, DNS Negative TTL, etc.)

In theory the TTL gives the maximum amount of time a cache can keep the entry. So a cache is theoretically free to do things before it, hence kind of lowering it.

In theory again, a cache should honor it and not increase it.

In practice it is known that some caches override the value, especially if too small. Various nameservers software have configuration option to do so.

While I do not know a definitive study on the subject, my ballpark recommendation is to stay way from TTL lowers than 5 minutes because otherwise you have a risk of some caches not honoring it. Others sources are more optimistic than me and says anything above 30 (seconds) is fine. YMMV.

There is at least this study, using RIPE probes, from 2017: https://labs.ripe.net/Members/giovane_moura/dns-ttl-violations-in-the-wild-with-ripe-atlas-2 It repeats the same sentiment: "It is publicly known that some cloud providers and CDNs override the original values provided by authoritative servers within their networks." based on this result in the study: "We have seen in Table 2 that 4.17% of the resolvers will actually increase the TTL value of our RRs in this measurement."

For further debug you will need to give more details on the specific caches where you see a behavior contradictory to your TTL configuration and you (and/or your clients) might want to try contacting their administrator to see if their rules can be changed (very low probability for that to succeed, but if you do not even try to contact them, absolute zero probability that things will change).

3
  • Clients will be mobile devices, so you can expect every possible ISP provider. Right now I don't see that behaviour so cannot say anything, for now it's just research before choosing solution. However it seems that your answer mean that indeed I cannot rely on Route53 routing in case I require fast propagation times.
    – Than
    Jun 9 '20 at 16:10
  • 1
    @Than I added a link to a study. Also you will probably need to monitor things closely (finding clients "clinching" to old IPs where they should have switched) and just architecture things as if TTLs will always work as is but take into account some sources may disregard them and make sure the resst of the system continue to work (routing to a less "favorable" IP). You may also want to look at anycast that can provide solutions for "local" routing without having to rely on the DNS. Jun 9 '20 at 16:43
  • 1
    "Clients will be mobile devices, so you can expect every possible ISP provider." Or maybe not.... browsers are more and more doing DoH at least on desktop and often hardcoded to 1.1.1.1 or things like that so you might wish to see how that one reacts to your DNS setup. As for mobile, I think I have read Android implements DoT, and there are "DNS VPNs" so to speak, like the app described on 1.1.1.1 (yes, again :-() Jun 9 '20 at 17:37

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.