3 ms·
You got the use case right, but I think you're still thinking about it wrong. In-use public DNS changes aren't something that just crop up and need to be done
by ru552 6y ago
You got the use case right, but I think you're still thinking about it wrong. In-use public DNS changes aren't something that just crop up and need to be done immediately.
Eg. Five days from now, I'm going to make an infrastructure change that will affect public DNS. Today, I lower my TTL on affected records. Five days later I make the public changes, still using the lower TTL. Once I am satisfied my change will stay in production, I modify TTLs to be more sane.
- codyb 6y agoThat makes a lot of sense, I've updated a lot of DNS records, but not generally in a planned manner.
- elp 6y agoIn practice though other things come up and the admin doesn't get round to increasing the TTL back to sanity later because nothing is broken if they don't.
- gnu8 6y agoSure but in a department where people are sysadminning reactively, they’re going to have that problem crop up everywhere. This type of thing wouldn’t be neglected in a well thought-out change process.