Many A-records

[Jonathan de Boyne Pollard]

JL> Every time you create a CNAME where you could have used an A
JL> record you create a situation where every resolver looking 
JL> for your service must do two lookups instead of one.  

BM> Unless the server is authoritative for both the CNAME record 
BM> and its target.  In that case the server will return both 
BM> records, [...]

If the first client-side aliase leads out of the server's bailiwick, then 
the resolving proxy DNS server _still_ needs to perform further lookups, 
because the second alias in the chain will be discarded as poison.

The classic example is the response from one of the "openwatcom.com." 
content DNS servers to an "A" query for "www.openwatcom.com.":

    [207.234.248.200:0035] -> [0.0.0.0:0000] 143
    Header: 0001 1+3+2+0, R, AUTH, query, no_error
    Question: www.openwatcom.com. IN A
    Answer: www.openwatcom.com. IN CNAME 7200 www.openwatcom.org.
    Answer: www.openwatcom.org. IN CNAME 7200 openwatcom.org.
    Answer: openwatcom.org. IN A 7200 69.0.238.41
    Authority: openwatcom.org. IN NS 7200 ns1.zoneedit.com.
    Authority: openwatcom.org. IN NS 7200 ns2.zoneedit.com.

The "www.openwatcom.org." client-side alias and the "openwatcom.org." 
"A" resource record set and partial delegation data are all out of 
bailiwick (because the bailiwick is "openwatcom.com.") and are discarded 
as poison.  The resolving proxy DNS server has to make further queries 
to look up "www.openwatcom.org.".

It's worth noting that the most common rationale that people give for using
client-side aliases is to deal with the case where a domain name is an alias 
for another domain name at a wholly different point in the namespace tree; 
but that that situation is also where this sort of out of bailiwick aliasing 
is most likely to occur, too.

It's also worth noting, as an aside, that, whilst BIND will provide the 
complete alias chain (if it has it in its database) in its response, some 
other content DNS server softwares do not.  (BIND even contains a bodge to 
try to cope with such responses.  Strictly speaking, according to RFC 2308, 
such responses are "lame" self-delegation responses, and BIND is free to
treat servers that provide such truncated alias chains as "lame".)  As I 
said before, one reason to avoid client-side aliases is that several DNS 
server softwares (both proxy and content) don't deal with them at all well.