3 ms·

Im missing quite a lot in this article. Personally i have my reservations about ALIAS. Recursion backed implementations in particular are full of Dragons and sh

Im missing quite a lot in this article. Personally i have my reservations about ALIAS. Recursion backed implementations in particular are full of Dragons and sharp corner cases. It's a shame that its missing any substantial critisicm or examples of poor implementations of ALIAS records. An authoritative nameserver ... can deliver records in a predictable speed Thats a nice to have. And totally unrelated to the AA bit. Query latency is usually implemented via caching then querying multiple/fastest available authoritative NS. An ALIAS record resolves on request the IP address of the destination record and serves it as if it would be the IP address for the apex domain requested First, backing with dns resolution is just one implementation of the idea. Secondly it is the ip address of the domain requested. An authoritative ns setting AA makes it so. There's nothing that specifies what the backing data store or resolution method is for AA answers. Implementation detail. you will send traffic for your mapped apex domain to the wrong address until the record expires in all caching resolvers. Now weve discovered, but not actually mentioned, TTLs. How is this any different than the ttl & expiry on a traditional CNAME + A record chain thats proposed at the end? you request the IP address from the nameserver of your DNS provider, not from your actual location. Assuming implementation is backed by dns recursion, sure. Good thing theres a standard like EDNS client-subnet that provides a method to propagate and vary based on the network of the original requester. But point taken, DNS is a complicated protocol and you should probably understand it before developin new features and implementations.

belorn 13y ago
> How is this any different than the ttl & expiry on a traditional CNAME + A record chain thats proposed at the end? The TTL on a CNAME is about caching the canonical name, not the IP address. Example with CNAME: Client ask the authoritive nameserver for example.com about bar.example.com. and get back a CNAME to foo.example.com. with a TTL of 2 days. The client store this in his resolver cache. Client then goes to ask about foo.example.com. and get back a A record for 203.0.113.3, with a TTL of 2 hours. Client cache looks like this: "bar.example.com. CNAME foo.example.com." that expires in 2 days, and "foo.example.com. A 203.0.113.3" that expires in 2 hours. If the domain foo.example.com. changes its A record, it will be reflected in 2 hours for clients who uses bar.example.com. Example with ALIAS: Client ask the authoritive nameserver for example.com about bar.example.com. and get back A record to 203.0.113.3 with a TTL of 2 days. Client resolve cache will be a single entry of: "bar.example.com. A 203.0.113.3" that expires in 2 days. If the foo.example.com. changes IP address, its TTL is not considered by clients who uses bar.example.com., because its not in their cache.
- bredman 13y ago
  I see your point; ALIAS records are not a CNAME substitute and should not be treated as one. However, they do have their uses and the risk is minimal if you understand what ALIAS records are doing and how to use them. I'm having a bit of a hard time following your example but I believe if the authoritative DNS provider simply inherited the TTL of the alias target then the behavior would be as desired. This gets back to donavanm's point that this is more an issue with the way ALIAS records are implemented then a problem with the concept of ALIAS records. One other issue that the author doesn't touch on is that we now have 3 implementations of ALIAS records that I'm aware of (Route 53, github, and Heroku) and there are differences about how they behave. However we have those 3 providers using the same ALIAS to describe similar but significantly different things. This is clearly confusing and potentially disastrous for users.

belorn 13y ago

> How is this any different than the ttl & expiry on a traditional CNAME + A record chain thats proposed at the end? The TTL on a CNAME is about caching the canonical name, not the IP address. Example with CNAME: Client ask the authoritive nameserver for example.com about bar.example.com. and get back a CNAME to foo.example.com. with a TTL of 2 days. The client store this in his resolver cache. Client then goes to ask about foo.example.com. and get back a A record for 203.0.113.3, with a TTL of 2 hours. Client cache looks like this: "bar.example.com. CNAME foo.example.com." that expires in 2 days, and "foo.example.com. A 203.0.113.3" that expires in 2 hours. If the domain foo.example.com. changes its A record, it will be reflected in 2 hours for clients who uses bar.example.com. Example with ALIAS: Client ask the authoritive nameserver for example.com about bar.example.com. and get back A record to 203.0.113.3 with a TTL of 2 days. Client resolve cache will be a single entry of: "bar.example.com. A 203.0.113.3" that expires in 2 days. If the foo.example.com. changes IP address, its TTL is not considered by clients who uses bar.example.com., because its not in their cache.

bredman 13y ago
I see your point; ALIAS records are not a CNAME substitute and should not be treated as one. However, they do have their uses and the risk is minimal if you understand what ALIAS records are doing and how to use them. I'm having a bit of a hard time following your example but I believe if the authoritative DNS provider simply inherited the TTL of the alias target then the behavior would be as desired. This gets back to donavanm's point that this is more an issue with the way ALIAS records are implemented then a problem with the concept of ALIAS records. One other issue that the author doesn't touch on is that we now have 3 implementations of ALIAS records that I'm aware of (Route 53, github, and Heroku) and there are differences about how they behave. However we have those 3 providers using the same ALIAS to describe similar but significantly different things. This is clearly confusing and potentially disastrous for users.