If I point foo.mydomain at bar.otherdomain with a CNAME, otherdomain can transition to a new IP without doing anything more than is required to make bar.otherdomain work.

If I point foo.mydomain at whatever bar.otherdomain's IP is (i.e. use an A record), otherdomain breaks my stuff whenever they change IP addresses, and there's not a lot they can do about that. Automating this (via the ALIAS mechanism mentioned in this article) just means that the breakage eventually goes away.

The correct solution, as pointed out, is to use CNAME - which requires that you use a subdomain.

The problem you cite is only a problem if the operators of otherdomain are either not aware of what you're doing, or otherwise don't want to support it, or are unable to handle a transition. If they are aware, it's generally a non-issue: They can ensure the site works on both addresses for a transition period.

Can you illustrate this with an example? How about explicit records and a 60 second ttl on A and CNAME to humor me.

If implementing recursion based ALIAS foo.mydomain RRs MUST respect the TTL of bar.otherdomains RRs. With that proviso Im missing what the effective cache lifetime difference is between the two.

I agree that this would work decently well if you could actually specify a 60-second TTL; but there are quite a few DNS resolvers that cache responses for at least a day, and there's not a whole lot you can do to change that. (This makes some sense - re-resolving all the time doesn't help performance!)

"Quite a few" is actually a very very small percentage these days.

If your ISP is disregarding TTL, you're just as bad off with CNAMEs pointing at a third party as you are with the ALIAS-type record.

Yeah, around 1% of resolvers seriously disregarding TTLs is what Ive seen. But if thats the argument theres absolutely no difference in cache lifetime of a single A backed by an ALIAS resolution and the typical A + CNAME. In either case all of the records should be cached for the broken resolvers lifetime. To counter that you do dns cache busting with prepended GUID labels or the like. Which totally breaks caching anyways.

> If implementing recursion based ALIAS foo.mydomain RRs MUST respect the TTL of bar.otherdomains RRs.

There is only two ways that I can think of. The nameserver could sets foo.mydomain TTL to be the reminder of bar.otherdomains current cached ttl, but it would mean that at some point it could go down as little as 1s long.

Or, the name server could make a new fresh resolving of bar.otherdomains, and forward that as the answer to foo.mydomain with bar.otherdomains TTL intact. However, that would make requests for foo.mydomain quite slow and severely increase the workload for the nameserver.

Given the problem of each of those solutions, its seems the common approach is to simply put a short TTL on foo.mydomain regardless of the TTL on bar.otherdomains, and then pray. Thus this article.

What's the difference between the ip changing via ALIAS and ip changing via the next hop after CNAME? In both cases you'll be stuck with the old address until the record times out in your cache, so either the provider has to make sure the old address works correctly for the whole TTL period after the record change, or you're going to hit the old/dead host.

Using a subdomain? What's wrong with "www."? For the apex all you need then is a tiny server that issues a permanent redirect. Why are people so obsessed with getting rid of "www."? The lack of dot causes issues with cookies, makes SSL a lot harder and is currently badly supported by DNS.

> What's wrong with "www."?

People (rightly) expect the url to work without it. I say rightly, because it can, so it should. The www hads no value to the user.

That's an extremely web-centric view of the world. There is more to DNS than its use in URLs. And doesn't redirecting to www. do the expected thing anyway?

To redirect to www.example.org I need a server listening at example.org. If I have www.example.org on heroku because I don't want to run a server, I suddenly need a server just for that redirect that I need to have because I don't want to run a server.

Or just use http://wwwizer.com/

EDIT: Or use DNSMadeEasy, they provide HTTP redirect options as part of their service (although I wish the default option would not be to wrap the target URL in an iframe...)

Or use an S3 bucket with a redirect.

But there's already a non-Heroku server running for that domain, i.e. the one serving DNS requests. That server can be re-purposed to do HTTP-level redirects, too, and indeed many name server operators offer that feature.

It does, but then can you do that without using an ALIAS record, which is one of the reason invoked to use "www"?

Also, web-centric is fine, browsing the net is 99% of my URL manipulation, and I'm a developer that has to work with web APIs.

For a high-availability site, you need a cluster of redirect servers behind the same IP. For the reasons you name, it's generally still worth redirecting web traffic to www.*, but it's trivial only for a non-HA site.