3 ms·

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.m

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.

JoachimSchipper 13y ago
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!)
- 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 ago
  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.
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.

JoachimSchipper 13y ago

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!)

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 ago
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.

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.