Remix.run Logo
dspillett 5 hours ago

> To my (limited) understanding, this is not a good idea, and is an unfixable problem from the server side. Companies, VPNs or ISPs or routers, often use their own DNS servers, and those can have caching logic, which means it doesn't matter how fast your own DNS implementation is, as the users lookup request wont hit your DNS server, it'll hit an intermediate cache.

All caches should respect the TTL of DNS records, no matter what they are, though there are some interesting bugs out there.

Firstly the human bugs: a lot of people assume switching DNS is always fast, but they haven't had the TTLs property of a DNS entry explained to them so assume that if the change is working here then it is going to be working <there>, <there>, and <everywhere-else> too. The default TTL values are a mix, it used to be that 24 hours was common though these days four hours or less, sometimes even one hour, is what you are more likely to see even for defaults. Whatever value your entries have though, that doesn't mean a fixed × hour window that it will switch at the end of. If the TTL is four hours your local cache last checked three hours ago but mine last checked one hour ago, a change will take an hour for you to see and three for me to see. A cache that has not recently looked up the entry will see it immediately next time it is asked - this is why some assume it is always instant (they add a new sub-domain record and it works instantly because no one has ever requested an address for that name before, for instance, and assume this is how it will always work).

Then there are coded bugs. TBH these days I ignore those: they are rare enough that if you are caring about that sort of edge case a lot then there are a lot of other weeds you'll be worrying about too and you'll never get anything done. For my domains I mostly have everything set to five minutes (300 seconds) as they are rarely referenced and DNS infrastructure is not a high-power service these days. Some would suggest that using such a low default is unfriendly to DNS caches and the root servers, but my names are very rarely referenced outside my network/vpn where my own DNS authoritative servers are what get directly queried anyway so that isn't going to matter. example.{org|com} and some sizable companies use 300s too. Why five minutes and not less? There used to be a very common caching DNS server that would ignore anything lower than 300 seconds and apply its own default (14,400 seconds, four hours, IIRC) instead. This goes back a couple of decades though, if anyone is still running that they deserve some DNS lookup failures! If you are wanting to use longer values normally, just remember to lower your TTL a time before any planned change so the change propagates ASAP and raise them back up after. One extra thing to be aware of with short TTLs is an outage affecting all your authoritative DNS servers may cause less friendly errors in many cases than getting an out of date address would result in, so make sure your DNS servers are stable and have few (preferably zero) shared potential points of failure.