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

141–150 of 163 posts

Re: Problems with low DNS TTLs

#141

Post by wongarsu »

don-code wrote: post #103
gertrunde wrote: post #82

I've seen issues with some DNS caches not honouring the TTLs if they're too short (less than 1 hour iirc, although memory is a bit hazy, it was some years ago) - in particular academic institutions tended to be the biggest culprits for this.

I've seen this happen with mobile providers and ISPs in APAC, especially Australia and New Zealand. In the worst case, a migration we expected to take place within an hour actually long-tailed to a full 24 hours - where within an hour, practically all of the US and Europe had migrated, and practically none of ANZ had.

Australia and New Zealand probably feel the pain from short TTLs much more simply because they are so far away from most servers. Sure, the large CDNs and DNS providers have edge nodes there, but to everyone else they have 200-300ms ping.

Re: Problems with low DNS TTLs

#142

Post by znpy »

marcosdumay wrote: post #84
sparrish wrote: post #29

As a sysadmin with 20+ years experience, I've had long TTLs cause issues on several occasions. I've never regretted a short TTL.

> I've never regretted a short TTL. I've seen enough people complaining about overloaded DNS servers.

I haven't.

Re: Problems with low DNS TTLs

#143

Post by znpy »

avidiax wrote: post #122
topranks wrote: post #113

Earlier quoted context omitted.

That is an insane amount of state for auth dns servers to maintain. “Pushing” the message out that the record has changed would also prove tricky to implement I’d say.

Worst case, 2^32 bits is 500MB. If you think that you'll get less than 134 million distinct queries, a simple list or a sparse array may be better. Obviously you need one of these bitmaps for every change domain (i.e. 1 per zone, or 1 per A/AAAA/CNAME record set, operator choice), and you need to clear it every (extended) TTL. So a CDN with 100,000 dynamic IP records might split themselves into 1,000 change domains o…

so that also means that the client has to be kept connected to the dns server ?

if so, that's a nice spot for user tracking.

if not, how do you push data to clients behind a nat, without a stateful and persistant tcp connection? for most dns queries udp is sufficient (although sometimes tcp is necessary).

500GB ram for 100k records seems quite a lot btw.

Re: Problems with low DNS TTLs

#144

Post by znpy »

meltedcapacitor wrote: post #130

LOL lot of arguments for a feature that makes sysadmin/dev life easy once a year at the expense of degraded user experience every day (lot of sporadically broken ISP etc DNS servers civilians can't be expected to bypass). Digital littering.

quite the opposite, actually.

more dns queries with a lower-ttl (say 10 minutes) means one additional round-trip every 10 minutes. how long can a round-trip be, 200msec worst case scenario?

that looks good.

now on the other hand, assume a 48h ttl and something breaks. now you've got all your users unable to reach your services for up to 48h. or worse, some of your users will go to the old ip, some to the new.

what's worse for the user, a round-trip from time to time, or an extended outage ?

Re: Problems with low DNS TTLs

#145

Post by znpy »

cstejerean wrote: post #63
askbill wrote: post #55

>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) That's just not how this works at all. While you could use RR records for this purpose, I believe the author is suggesting that load balancing will happen automatically when the client simply can't connect to one of the…

I think load balancing in that argument happens via “clients picks a random IP” and failover happens via “transparently try another if they can’t connect”. So that would be both load balancing and failover, why doesn’t the argument hold up?

load balancing is more like you have 5 records, I'll serve 3 of them back to you.

next client comes in, I'll serve three again, possibly different from the three i've served before.

the client doesn't even know that there are two other possible endpoints (unless maybe until the next query).

edit: i just tried running this

    watch dig -t A www.amazon.com @8.8.8.8
and saw the record change from time to time.

Re: Problems with low DNS TTLs

#147

Post by selcuka »

ProtoAES256 wrote: post #126
pas wrote: post #93

Earlier quoted context omitted.

Use a new (sub)domain. Your main domain can then simply redirect to whatever subdomain you wish.

A new subdomain normally will do the trick, but might be suboptimal due to the work needed to be done according to scale/tech/job involved. For example, doing this as a sys in a big company requires jumping through bureaucracy hoops, not to mention setting up ssl for it(I know there is letsencrypt but you know, some coporate doesn't want them). A short TTL will just be "Well just try it again in 10 minutes and it'll…

Besides we might still want other caches (such as the browser cache) to work. A new subdomain would invalidate those too.

Re: Problems with low DNS TTLs

#148

Post by jrockway »

The article claims that web browsers will automatically pick a healthy backend when you return multiple A records, but the behavior doesn't seem acceptable to me. I was going to post "I've never seen it work", but I just tried it and it does indeed work -- the browser hangs for 30 seconds while it waits for the faulty IP address to time out, and then it eventually tries the other IP address, and it does work. (It then retains its selection for a while; I was too lazy to see what happens if I invert the healthiness of the two backends. I also didn't try more than 2.)

I think most people would call a website down if it was just a white screen for 30 seconds, so while it's a nice try on the part of the browsers, you can see why people use short TTLs to get bad backends out of the pool as quickly as possible.

Re: Problems with low DNS TTLs

#150

Post by sondel »

avidiax wrote: post #78

The problem is that the DNS TTL is a feature designed for a static internet of the 70's or 80's. What this points to is a need for an authenticated DNS pushes for refresh/invalidation. All supporting resolvers could keep a list of supporting clients that were told that "foo is at address 42". If the record changes, the authoritative DNS server sends a DNSSEC signed unsolicited response to all previous requesters to u…

What you're describing is somewhat like DNS Push Notifications (RFC 8765): https://tools.ietf.org/html/rfc8765
Post reply on HN