3 ms·
If you have DNS typo for a fixed time, the longer the TTL the fewer clients will ever see the error. E.g. lets say your typo is up for 10 mins. With a 5 minute
by advisedwang 4y ago
If you have DNS typo for a fixed time, the longer the TTL the fewer clients will ever see the error. E.g. lets say your typo is up for 10 mins. With a 5 minute TTL everyone will be seeing the error. but with a 60 min TTL, 5/6 of your customers will never see the typo (assuming there's enough traffic for caching)
Slow onset of impact is probably more useful in minimizing incidents than fast onset of fix (edit: or rather this is a trade-off and one might consider both directions).
- 8organicbits 4y agoTesting strategy is also pretty important here. If you can run integration tests that bypass DNS caches immediately after the change, then you should know quick if things are working. If both old and new DNS settings are valid, the slow onset works great and minimizes impact of an error. I've handled DNS changes where the underlying host was changing IP address. In that instance the old DNS entry immediately became invalid, so a quick DNS cut-over was needed for all clients.
- M3L0NM4N 4y agoI think the amount of people that would see the error either way would be the same, assuming constant fix time and traffic. This means lowering the TTL as much as possible should be the right solution, because those affected will only have the issue for as long as the fix takes (hopefully less than 1hr) whereas if it is kept at 1hr those affected by the error will have it for an entire hour. Disclaimer I'm not OP