Many A-records

[Jonathan de Boyne Pollard]

JSGJ> If you run and manage the DNS servers and zones, then using
JSGJ> CNAME's instead of A records is fine.  But in the end you 
JSGJ> still have multiple records pointing to a single address.  
JSGJ> Using CNAME's can make life easier, as if you change a hosts 
JSGJ> IP address, you update one record and you are done.  If you 
JSGJ> move a virtual web site to another host, you just change the
JSGJ> CNAME.

It's not "CNAME" resource records that make life easier in such situations. 
It is _aliases_.  But there are more than one type of aliases.  "CNAME"
resource records are merely _client-side_ aliases.  But there are also several
kinds of _server-side_ aliases.

ISC's BIND supports only two sorts of server-side aliases, wildcards and
"whole 'zone'" server-side aliases.  With the latter form of server-side
aliases, for example, one _still_ "updates one record" and "is done". 
Consider the case where one has multiple zones ("example.net.",
"example.org.", and "example.com.") all backed by the same "zone" file:

	@   IN SOA  [...]
	@   IN NS   [...]
	@   IN MX   [...]
	www IN A    10.17.34.59

Changing that one "www" line in that one file would change the name->address
mappings for "www.example.org.", "www.example.net.", and "www.example.com." in
one fell swoop.

For aliasing, "CNAME" resource records are not the sole answer, and are often
not even a good answer.  

And it is the _server-side_ aliasing features of a content DNS server
softwares that are the better measure of how easy life can be made in such
situations.