IP Address Abstraction, should you use it?
Previous I blogged about a concept called IP address abstraction, IAA for simplicity, (Zen of Hosting pt 11), where I wrote about using CNAMEs in DNS to abstract yourself away from having lots of IP addresses and needing to update lots and lots of DNS records should your IPs change. It seems like a good idea, however, no good idea seems to be a perfect fit in IT anymore 😒 In this case, the biggest issue is that, according to Common DNS Operational and Configuration Errors (RFC 1912, for those who care), it states a few issues and many an admin may point out that this is the cause of all kinds of things—like email breaking—but as we will see, that may not be the case. But let’s cover the highlights from RFC 1912, which will be pointed out to you:
A CNAME record is not allowed to coexist with any other data. However, DNS servers like BIND will see the CNAME and refuse to add any other resources for that name. Since no other records are allowed to coexist with a CNAME, the NS entries are ignored. Therefore, all the hosts in the podunk.xx domain are ignored as well!
That’s a big one: if you use IAA, it will coexist with MX, NS, etc. It also goes on to say:
Don’t go overboard with CNAMEs. Use them when renaming hosts, but plan to get rid of them (and inform your users). However, CNAMEs are useful (and encouraged) for generalized names for servers—
ftpfor your FTP server,wwwfor your Web server,gopherfor your Gopher server,newsfor your Usenet news server, etc. RFC 1034 in section 3.6.2 says this should not be done, and RFC 974 explicitly states that MX records shall not point to an alias defined by a CNAME. This results in unnecessary indirection in accessing the data, and DNS resolvers and servers need to work more to get the answer.
This basically goes against everything IAA identifies as a reason for using it 😒 Lastly, it states:
Also, having chained records such as CNAMEs pointing to CNAMEs may make administration issues easier, but is known to tickle bugs in some resolvers that fail to check loops correctly. As a result, some hosts may not be able to resolve such names. Having NS records pointing to a CNAME is bad and may conflict badly with current BIND servers. In fact, current BIND implementations will ignore such records, possibly leading to a lame delegation. There is a certain amount of security checking done in BIND to prevent spoofing DNS NS records. Also, older BIND servers reportedly will get caught in an infinite query loop trying to figure out the address for the aliased nameserver, causing a continuous stream of DNS requests to be sent.
Basically, stating that it may make administration issues easier is kind of the point of all this. However, there are a few things that wily admins may not point out: first, this was published in February 1996—that’s 28 years ago! Since then, superior DNS software like BIND (and even inferior software like that which ships with Windows) no longer has these issues. This nullifies the first and last points, but what about that bit in the middle, pointing to RFC 1034 and RFC 974?
Well, RFC 974 deals with MX records and routing, so it’s similar to the first point but does state:
If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name.
So basically, even if you chain CNAMEs, it should not break any email system. RFC 1034 is more about DNS (it’s actually called DOMAIN NAMES - CONCEPTS AND FACILITIES) and covers the overview of how it should work without covering technical details. However, it was written in November 1987 (so even older than RFC 1912) but is not obsoleted by any other RFC. It states:
Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error.
Basically, DNS should be robust, and the idea of IAA should work regardless. The one issue I cannot disprove is that it takes additional time and bandwidth to have lots of CNAMEs. Then again, in 1996, 56k was the blinding speed of the internet—now, that’s not the case. Bandwidth has increased and latency decreased so much that it makes sense to utilize that additional power to make a more stable internet through making administration easier.
Hopefully, we can soon get some tools to test for loops, which are the biggest issue caused by this structure. Looking at all of this, I would state that IAA is worth implementing and there is no significant reason anymore not to utilize it. Hopefully, this document should help answer any questions or be of use when dealing with those admins who haven’t seen the light.