IP Address Abstraction, should you use it?

Previous I blogged about a concept called IP address abstraction, IAA for simplicity, (see 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) states a few issues and many an admin may point out that this is the cause for all kinds of things like email breaking, but as we will see that may not be the case. But lets 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 since if you use IAA it will co-exist 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 -- `ftp' for your ftp server, `www' for your Web server, `gopher' for your Gopher server, `news' for 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 goes on to state

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 it may make administration issues easier, is kind of the point of all this. However there is a few things that the wiley admins may not point you to, first off this was published in Feb '1996! That’s 12 years ago, since then the superior DNS software like BIND, no longer has the issues that are stated, and to that point even the inferior DNS software like that which ships with Windows doesn’t show these issues. Basically that nulifies 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 is 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 CNAME’s 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 should work without covering the technical details. However it was written in Nov of 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 that DNS should be robust and that 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 is not the case. Bandwidth has increased and latency decreased so much since then, that it makes sense to utilize that additional power to make a more stable internet through the use of 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 not a 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.