2 ms·
I was hoping this would be about DNS, as I never know what a “good” value for those TTLs are but I’ve read in HN that high is better somewhere and handle change
by quickthrower2 6y ago
I was hoping this would be about DNS, as I never know what a “good” value for those TTLs are but I’ve read in HN that high is better somewhere and handle changes some other way. I would be interested to learn more about strategies for that.
- toast0 6y agoThat could probably go into a whole separate article. But... The first rule of DNS TTLs is expect some things to not respect them. If you are changing your records frequently or urgently, set ttl somewhere between 1 minute and 5 minutes. Maybe 15 seconds if it's really a lot, but don't go below that cause things get weird. Other than that, most things should probably be between an hour to four hours. If you're paying per query, make ttls longer to reduce your costs. Don't make ttls longer than one or two days. Also, don't make long chains of cnames and what not, and don't let your responses grow beyond 512 bytes (cause it won't work on some networks), allowing for NAT64 turning your A records into AAAA records. IIRC that means don't return more than 8 A records, but your mileage may vary.
- JdeBP 6y agoOne strategy is to use DNS server software that handles changes for you. Set a time-to-die, and the software will publish a counting down TTL that is the number of seconds left until the time-to-die. Set a start time, and the software won't publish the record until that time has been reached. Have two records with each, and one has a pre-programmed switch over from one thing to another. * http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-data.xml http://jdebp.uk./Softwares/djbwares/guide/commands/tinydns-d...