Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems with low DNS TTLs

00f.net

Post reply on HN
Print view View original

11–20 of 163 posts

Re: Problems with low DNS TTLs

#11

Post by aequitas »

codyb wrote: post #6
JimWestergren wrote: post #2

What is the use cases for having the TTL shorter than 5 minutes?

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,…

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.

Re: Problems with low DNS TTLs

#12

Post by dawnerd »

codyb wrote: post #6
JimWestergren wrote: post #2

What is the use cases for having the TTL shorter than 5 minutes?

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,…

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.

Re: Problems with low DNS TTLs

#13

Post by mschuster91 »

aequitas wrote: post #11
codyb wrote: post #6

Earlier quoted context omitted.

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,…

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…

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

Re: Problems with low DNS TTLs

#14

Post by ilikepi »

irishsultan wrote: post #9
codyb wrote: post #6

Earlier quoted context omitted.

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,…

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.

Re: Problems with low DNS TTLs

#15

Post by ru552 »

codyb wrote: post #6
JimWestergren wrote: post #2

What is the use cases for having the TTL shorter than 5 minutes?

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,…

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.

Re: Problems with low DNS TTLs

#16

Post by JimWestergren »

JimWestergren wrote: post #7
nathanaldensr wrote: post #5

Earlier quoted context omitted.

The article posits why: Why are DNS records set with such low TTLs? - Legacy load balancers left with default settings - The urban legend that DNS-based load balancing depends on TTLs (it doesn’t - since Netscape Navigator, clients pick a random IP from a RR set, and transparently try another one if they can’t connect) - Administrators wanting their changes to be applied immediately, because it may require less plann…

But those are no valid use cases which was my question. So there are no valid use cases at all?

Found an earlier HN discussion about this question from November 2019: https://news.ycombinator.com/item?id=21437160

Re: Problems with low DNS TTLs

#19

Post by codyb »

ru552 wrote: post #15
codyb wrote: post #6

Earlier quoted context omitted.

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,…

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…

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

Re: Problems with low DNS TTLs

#20

Post by JimWestergren »

hiq wrote: post #8
JimWestergren wrote: post #7

Earlier quoted context omitted.

But those are no valid use cases which was my question. So there are no valid use cases at all?

> Administrators wanting their changes to be applied immediately, because it may require less planning work. Why is this not valid?

But 5 minutes should be fine? It surprised me that so many has 1 second or 20 second TTL.
Post reply on HN