Hacker News Reader

Comment by akl | Hacker News Reader

You are crazy for doing that - one instance of downtime doesn't justify ignoring all the advantages DNS brings.

When I made that design decision I wasn't considering the possibility of DNS outages at all; I was just thinking in terms of "there's a huge number of places between me and ultradns where someone could insert a spoofed DNS response".

What if amazon gets a new netblock assigned ?

Can you forcibly upgrade the software in that case ?

Of course I can upgrade the software; and there's nothing forcible about it. We're talking about code I'm running on my server here...

Ah, my bad, sorry I thought you meant in the tarsnap client. Then I really don't know why people would make a fuss over you hardcoding the ips in there. All you need to do is keep an eye out in case they change them (which you could even automate).

All you need to do is keep an eye out in case they change them

Exactly, and that's what I do. (With the caveat that I look for AWS endpoints being taken out of service, not for changes in what DNS tells me.)

Are there DNS servers that support versioning? The best solution I could imagine would simply be to set Tarsnap to normally use the current DNS records for S3, but be able to rollback to a valid zone record if they encounter an update that makes the servers stop resolving.

The Tarsnap client only talks to the Tarsnap server, but I do cache that lookup in order to avoid problems with glitchy DNS resolution.

I could have the Tarsnap server cache DNS lookups if I was only worried about working around DNS outages -- but as I said, that wasn't something I was considering at all when I made the decision to eschew DNS.

Some DNS caches will continue to try giving out expired records if no newer ones can be found. Unclear that it's worth it, though.

you can expect such downtimes every Christmas. why? ask yourself how much protection money UltraDNS was told to pay.

Reply on news.ycombinator.com