Hacker News Reader

Comment by codyb | Hacker News Reader

I always was under the impression people lowered the TTL when updating records... which doesn't even really make sense since the change won't propagate until the previous TTL is overrun anyways.

Then you were supposed to update it to a longer TTL when your change had propagated.

So, I guess, after understanding things better... there is no use case really since if it's a new record your change will always propagate, and if it's an old record, lowering the TTL on update doesn't really matter since the old TTL will still be in effect.

View on HN

It could help to lower your TTL way before you plan to update. If your current TTL was 24h, you just update it to 5m 24 hours before you plan the actual change of the record itself. The new record can them be set to 24h directly (unless you want a quick turnaround for rollback).

It's still no guarantee all changes will propagate within 5 minutes. But it gives some ease of mind to know the bulk of change won't take a day.

Also a lot of people forget the negative caching of NXDOMAIN records which is set by the TTL of the SOA record. Which means that it will take a while for your new record to be resolved if you started querying before you set the record.

> It's still no guarantee all changes will propagate within 5 minutes. But it gives some ease of mind to know the bulk of change won't take a day.

Especially it gives you peace of mind that should stuff go badly wrong you can easily revert the change.

Yes - it’s called planning. Lowering TTL well in advanced is not a new concept and works very well if you have enough advanced notice from the application owners ahead of time :p

Unfortunately, data centers rarely give 24 hour notice about catastrophic fires or provide advance notice about utility outages when the automatic transfer switch is going to fail.

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.

That makes a lot of sense, I've updated a lot of DNS records, but not generally in a planned manner.

In 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.

Sure 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.

I lower the try a few days before I’m going to make a big change. This is also how we did it in the past at a large corp I worked at.

Does it actually make a difference? I dunno but it just feels right.

You could lower TTL if you know a change is coming.

Exactly. The TTL is lowered in advance of the maintenance window, sufficiently far out to allow any entries with the old TTL to expire from most resolvers. Once the maintenance has been completed and validated, and sufficient time has elapsed to decide there are no issues requiring roll back, the TTL is raised back up to its stable value.

Reply on news.ycombinator.com