I've been bitten in the rear far too often with high TTLs. Especially stuff like AWS Beanstalk which tends to delete and recreate resources if you're not extremely careful... thanks but I'll stay with 60s or 300s TTLs.
Stop using low DNS TTLs (2019)
71–80 of 110 posts
Re: Stop using low DNS TTLs (2019)
#72DNS TTLs are fraught with peril. For one, a lot of clients ignore them. [0] Secondly, a lot of ISPs ignore them too. At every place I've worked, we've had trouble where ISPs just ignore TTLs and set them arbitrarily high. When I worked at reddit, it took a month for traffic to shed off of the old load balancer, despite me lowering the TTL to 5 seconds. And even then there was still some traffic, so I just had to cut…
>It doesn't matter what you set your DNS TTL to, so you might as well make it low for your own sake.
IMO that is a little misguided. 60-second and higher TTL will be honored most of the time. And I don't really get what that ISP in Alaska was doing: DNS is about 0.1% of Internet traffic (according to some quick googling), so decreasing that will save you only a tiny tiny bit of bandwidth at disproportionate inconvenience for your customers.
Re: Stop using low DNS TTLs (2019)
#73DNS TTLs are fraught with peril. For one, a lot of clients ignore them. [0] Secondly, a lot of ISPs ignore them too. At every place I've worked, we've had trouble where ISPs just ignore TTLs and set them arbitrarily high. When I worked at reddit, it took a month for traffic to shed off of the old load balancer, despite me lowering the TTL to 5 seconds. And even then there was still some traffic, so I just had to cut…
It doesn’t help that Java’s default configuration is to cache DNS entries forever for “security”[0]. Any long running server that makes external requests will eventually hit an issue where one their dependencies no longer works because DNS has changed and the TTL is ignored. I’ve seen this bite teams for 15 years and it will probably keep doing so well into the future.
0 - https://docs.oracle.com/javase/7/docs/technotes/guides/net/p...
Re: Stop using low DNS TTLs (2019)
#74Even if the DNS update is available to an end user, if you're using HTTP2 then web browsers will keep the connection to the old IP address until they receive a GOAWAY frame.
Re: Stop using low DNS TTLs (2019)
#75DNS TTLs are fraught with peril. For one, a lot of clients ignore them. [0] Secondly, a lot of ISPs ignore them too. At every place I've worked, we've had trouble where ISPs just ignore TTLs and set them arbitrarily high. When I worked at reddit, it took a month for traffic to shed off of the old load balancer, despite me lowering the TTL to 5 seconds. And even then there was still some traffic, so I just had to cut…
It doesn’t help that Java’s default configuration is to cache DNS entries forever for “security”[0]. Any long running server that makes external requests will eventually hit an issue where one their dependencies no longer works because DNS has changed and the TTL is ignored. I’ve seen this bite teams for 15 years and it will probably keep doing so well into the future. 0 - https://docs.oracle.com/javase/7/docs/techno…
.NET HTTP clients used to suffer from this, too, but they no longer do as of .Net Core 3, as long as they're used correctly.
Re: Stop using low DNS TTLs (2019)
#76Ooops! good point, I should check the DNS TTL for my shelf-hosted email server.
Re: Stop using low DNS TTLs (2019)
#77DNS TTLs are fraught with peril. For one, a lot of clients ignore them. [0] Secondly, a lot of ISPs ignore them too. At every place I've worked, we've had trouble where ISPs just ignore TTLs and set them arbitrarily high. When I worked at reddit, it took a month for traffic to shed off of the old load balancer, despite me lowering the TTL to 5 seconds. And even then there was still some traffic, so I just had to cut…
It doesn’t help that Java’s default configuration is to cache DNS entries forever for “security”[0]. Any long running server that makes external requests will eventually hit an issue where one their dependencies no longer works because DNS has changed and the TTL is ignored. I’ve seen this bite teams for 15 years and it will probably keep doing so well into the future. 0 - https://docs.oracle.com/javase/7/docs/techno…
Only if you have a security manager enabled (=are running in an applet/webstart). The entire security manager concept has been deprecated, so things are looking better
Re: Stop using low DNS TTLs (2019)
#78There are use cases for low TTLs and use cases for high TTLs
The statement here is misguided.
Use whatever TTL serves your purpose.
DNS was designed to be distributed and scalable. And in my opinion it is THE MOST scalable protocol as it basically allowed the entire internet to work that way. Any user in the world can get any public DNS record for a site.
Re: Stop using low DNS TTLs (2019)
#79As an admin, I use low TTLs when I do some major DNS maintenance. I wouldn't mind upping the TTLs after, but... what about if I need to do some emergency maintenance, like the IPs on a load balancer change and I can't get the old IPs back? I don't want to wait an hour for clients to pick up the new IP.
It would be great if there were some reverse notification to let revolvers know to refresh their caches.
Re: Stop using low DNS TTLs (2019)
#80DNS TTLs are fraught with peril. For one, a lot of clients ignore them. [0] Secondly, a lot of ISPs ignore them too. At every place I've worked, we've had trouble where ISPs just ignore TTLs and set them arbitrarily high. When I worked at reddit, it took a month for traffic to shed off of the old load balancer, despite me lowering the TTL to 5 seconds. And even then there was still some traffic, so I just had to cut…
The service I worked for in AWS faced this as a routine pain. No matter what the TTL, stuff completely ignored it. In the end the only sensible thing we could do was accept that we were going to impact customers and that we just can't realistically account for misbehaving DNS infrastructure. We had something like a 5 minute TTL on our public record, and would wait 15 minutes after removing the IP from the DNS records before we would take action that would potentially break connectivity.
By setting the DNS TTL, we had established the terms by which we offered the service. Failure to accept those terms is not something we can control.
What we generally found was that clients disconnected would reconnect almost immediately to one of the other IP addresses. Any disruption to the client appeared to be almost negligible.