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

Stop using low DNS TTLs

blog.apnic.net

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Stop using low DNS TTLs

#31

Post by bigstrat2003 »

garciasn wrote: post #16
fukawi2 wrote: post #11

Earlier quoted context omitted.

That's not how TTL works. Or do you mean propagation after changing an existing RR? It's "common" to lower a TTL in preparation for a change to an existing RR, but you need to make sure you lower it at least as long as the current TTL prior to the change. Keeping the TTL low after the change isn't beneficial unless you're planning for the possibility of reverting the change. A low TTL on a new record will not speed p…

I meant both. Initial (which you say doesn't matter; TIL) and edits after-the-fact. I learned something new today and I've been doing DNS crap for decades; I feel like a doofus.

Technically the initial propagation does depend somewhat on TTL. If you query the server and get the response that the record doesn't exist, that negative response gets cached too (based on the TTL of the SOA record). But it's pretty unusual for that to matter if you're standing up a new server.

Re: Stop using low DNS TTLs

#32

Post by _bernd »

deceptionatd wrote: post #10
c45y wrote: post #3

Earlier quoted context omitted.

Probably an expectation for floating IPs for load balancing instead of DNS. Relatively simple inside a network range you control but no idea how that works across different networks in geographical redundant setups

Agreed; I have no idea how you'd implement that across multiple ASNs, which is definitely a requirement for multi-cloud or geo-redundant architectures. Seems like you'd be trying to work against the basic design principles of Internet routing at that point.

You can configure your assigned network numbers that other AS are allowed to announce certain networks of your own. Not uncommon for in examples authoritative name server addresses.

Re: Stop using low DNS TTLs

#33

Post by deceptionatd »

_bernd wrote: post #32
deceptionatd wrote: post #10

Earlier quoted context omitted.

Agreed; I have no idea how you'd implement that across multiple ASNs, which is definitely a requirement for multi-cloud or geo-redundant architectures. Seems like you'd be trying to work against the basic design principles of Internet routing at that point.

You can configure your assigned network numbers that other AS are allowed to announce certain networks of your own. Not uncommon for in examples authoritative name server addresses.

TIL, I always thought IP:ASN mappings were 1:1.

Re: Stop using low DNS TTLs

#34

Post by _bernd »

deceptionatd wrote: post #33
_bernd wrote: post #32

Earlier quoted context omitted.

You can configure your assigned network numbers that other AS are allowed to announce certain networks of your own. Not uncommon for in examples authoritative name server addresses.

TIL, I always thought IP:ASN mappings were 1:1.

With cloud providers and such the wording could also be "bring your own address".

Re: Stop using low DNS TTLs

#37

Post by electroly »

johntash wrote: post #24
kevincox wrote: post #23

Earlier quoted context omitted.

Because unless your TTL is exceptionally long you will almost always have a sufficient supply of new users to balance. Basically you almost never need to move old users to a new target for balancing reasons. The natural churn of users over time is sufficient to deal with that. Failover is different and more of a concern, especially if the client doesn't respect multiple returned IPs.

I'm assuming OP means cloud-based load balancers (listening on public ips). Some providers scale load balancers pretty often depending on traffic which can result in a set of new IPs.

Being specific: AWS load balancers use a 60 second DNS TTL. I think the burden of proof is on TFA to explain why AWS is following an "urban legend" (to use TFA's words). I'm not convinced by what is written here. This seems like a reasonable use case by AWS.

Re: Stop using low DNS TTLs

#38

Post by compumike »

The big thing that articles like this miss completely is that we are no longer in the brief HTTP/1.0 era (1996) where every request is a new TCP connection (and therefore possibly a new DNS query).

In the HTTP/1.1 (1997) or HTTP/2 era, the TCP connection is made once and then stays open (Connection: Keep-Alive) for multiple requests. This greatly reduces the number of DNS lookups per HTTP request.

If the web server is configured for a sufficiently long Keep-Alive idle period, then this period is far more relevant than a short DNS TTL.

If the server dies or disconnects in the middle of a Keep-Alive, the client/browser will open a new connection, and at this point, a short DNS TTL can make sense.

(I have not investigated how this works with QUIC HTTP/3 over UDP: how often does the client/browser do a DNS lookup? But my suspicion is that it also does a DNS query only on the initial connection and then sends UDP packets to the same resolved IP address for the life of that connection, and so it behaves exactly like the TCP Keep-Alive case.)

Re: Stop using low DNS TTLs

#39

Post by hannasm »

compumike wrote: post #38

The big thing that articles like this miss completely is that we are no longer in the brief HTTP/1.0 era (1996) where every request is a new TCP connection (and therefore possibly a new DNS query). In the HTTP/1.1 (1997) or HTTP/2 era, the TCP connection is made once and then stays open (Connection: Keep-Alive) for multiple requests. This greatly reduces the number of DNS lookups per HTTP request. If the web server i…

  > patched an Encrypted DNS Server to store the original TTL of a response, defined as the minimum TTL of its records, for each incoming query
The article seems to be based on capturing live dns data from some real network. While it may be true that persistent connections help reduce ttl it certainly seems like the article is accounting for that unless their network is only using http1.0 for some reason.

I agree that low TTL could help during an outage if you actually wanted to move your workload somewhere else, and I didn't see it mentioned in the article, but I've never actually seen this done in my experience, setting TTL extremely low for some sort of extreme DR scenario smells like an anti pattern to me.

Consider the counterpoint, having high TTL can prevent your service going down if the dns server crashes or loses connectivity.

Re: Stop using low DNS TTLs

#40

Post by csense »

DNS is something you rarely change that has costly consequences if you mess it up: It can bring down an entire domain and keep it down until TTL passes.

If you set your TTL to an hour, it raises the costs of DNS issues a lot: A problem that you fix immediately turns into an hour-long downtime. A problem that you don't fix on the first attempt and have to iteratively try multiple fixes turns into an hour-per-iteration downtime.

Setting a low TTL is an extra packet and round-trip per connection; that's too cheap to meter [1].

When I first started administering servers I set TTL high to try to be a good netizen. Then after several instances of having to wait a long time for DNS to update, I started setting TTL low. Theoretically it causes more friction and resource usage but in practice it really hasn't been noticeable to me.

[1] For the vast majority of companies / applications. I wouldn't be surprised to learn someone somewhere has some "weird" application where high TTL is critical to their functionality or unit economics but I would be very surprised if such applications were relevant to more than 5% of websites.

Post reply on HN