Comment by metadat | Hacker News Reader

Comment by metadat | Hacker News Reader

> This allows you to share the load between multiple servers, as well as to automatically detect which servers are offline and choose the online ones.

To [hesitantly] clarify a pedantry regarding "DNS automatic offline detection":

Out of the box, RR-DNS is only good for load balancing.

Nothing automatic happens on the availability state detection front unless you build smarts into the client. TFA introduction does sort of mention this, but it took me several re-reads of the intro to get their meaning (which to be fair could be a PEBKAC). Then I read the rest of TFA, which is all about the smarts.

If the 1/N server record selected by your browser ends up being unavailable, no automatic recovery / retry occurs at the protocol level.

p.s. "Related fun": Don't forget about Java's DNS TTL [1] and `.equals()' [2] behaviors.

[1] https://stackoverflow.com/questions/1256556/how-to-make-java...

[2] https://news.ycombinator.com/item?id=21765788 (5y ago, 168 comments)

We accomplish this on Route53 by having it pull servers out of the dns response if they are not healthy, and serving all responses with a very low ttl. A few clients out there ignore ttl but it’s pretty rare.

I once achieved something similar with PowerDNS, which you can use LUA rules to do health checks on a pool of servers and only return health servers as part of the DNS record, but found odd occurrences of clients not respecting the TTL on DNS records and caching too long.

You usually do this with servers that should be rock-solid and stateless. HAProxy, Traefik, F5. That way, you can pull the DNS record for maintenance 24 - 48 hours in advance. If something overrides DNS TTLs that much, there is probably some reason.

Honest question to somebody who seems to have a bit of knowledge about this in the real world: several (German, if relevant) providers default to a TTL of ~4 hours. Lovely if everything is more or less finally set up, but usually our first step is to decrease pretty much everything down to 60 seconds so we can change things around in emergencies.

On average, does this really matter/make sense?

Lower TTLs is cheap insurance so you can move hostnames around.

However, you should understand that not ALL clients will respect those TTLs. There are resolvers that may minimum TTL threshold where IF TTL < Threshold, TTL == Threshold, Common with some ISPs, and also, there may be cases where browsers and operating systems will ignore TTLs or fudge them.

From experience, 90%+ of traffic will respect your TTLs or something close. So on average, it definitely does make a difference. There's always going to be a long tail of straglers though.

Personally, my default for names that are likely to change often is 5 minutes, but 1 minute is ok, but might drive a lot more DNS traffic.

Shameless plug: a FOSS project to provide failover for RR-DNS and it's being funded by NLnet https://codeberg.org/FedericoCeratto/rrdnsd

Reply on news.ycombinator.com