5 ms·
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.otherdo
by JoachimSchipper 13y ago
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.
- donavanm 13y agoCan 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.
- JoachimSchipper 13y agoI 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!)
- imbriaco 13y ago"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.
- donavanm 13y agoYeah, 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.
- belorn 13y ago> 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.
- vidarh 13y agoThe 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.
- viraptor 13y agoWhat'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.