Proper implamentation of A and CNAME records

[Kevin Darcy]

Jonathan de Boyne Pollard wrote:

>KD> In the general case, there would not be an extra lookup, since the
>KD> CNAME and the A record would both come from the authoritative server
>KD> in the same response.
>
>In the real world, this is false.  There is at least one content DNS 
>server software that doesn't follow RFC 2308 and RFC 1034 and that 
>returns responses with just the first client-side alias in the chain and 
>nothing else.  (Quite a few DNS server softwares have various quirks 
>when it comes to client-side aliases.  One content DNS server software 
>by default simply doesn't publish them.  Another resolving proxy DNS 
>server software doesn't cache them.  And all but one resolving proxy DNS 
>server software will fail to handle them if they are used in delegation 
>information.)
>
>KD> the obvious maintenance benefit of only having to update one DNS
>KD> record if the address changes
>
>.... is highly overrated, in these days of text editors with 
>search-and-replace capabilities.  (And yes, I deliberately chose the 
>most basic database modification tool to emphasize the point.)
>
>KD> This primitive "CNAMEs bad!" mindset [...]
>
>.... is a straw man entirely of your own making.  The advice that I and 
>others give is that when there are multiple ways of doing things, only 
>some of which involve the use of client-side aliases, one should use one 
>of the ways that do not.  The irony is that, entirely contrary to what 
>you imply, this is _modern_ thinking, based upon people's experience of 
>client-side aliases, and the fact that they still, after all these 
>years, don't work right in practice.  The _primitive_ thinking here is 
>actually that which declares client-side aliases to be not problematic.
>
Well, I decline to accept that cravenly conceding to the foibles of a 
few broken, non-standards-conforming implementations is in any way 
"forward-looking". As for "theory vs. practice", I've had plenty of 
"practice" with using CNAMEs, and they work just fine, thank you very much.

I also note you completely elided my point about the reverse-lookup 
ambiguity that results from having multiple A records pointing to the 
same IP address. This is actually the *main* reason I recommend the use 
of CNAMEs.

Another valid (IMO) use of CNAMEs is when the alias and the target of 
the alias happen to be in different zones controlled by different 
organizations and/or legal entities with imperfect communication and/or 
co-ordination between them. By using CNAMEs, the org controlling the 
A/PTR/MX/NS/whatever record can change it without having to communicate 
and/or co-ordinate that change to the other org (except for non-DNS 
reasons like firewall rules and whatnot). The most notable example of 
what I am talking about is, of course, RFC 2317's "classless in-addr 
delegation", but actually that's just a special case of the general 
method of using CNAMEs to handle "split organization" situations.

Now, I realize you don't think much of RFC 2317, based on your belief 
that most ISPs are happy to delegate each individual address in sub-/24 
ranges to their customer's nameservers (which, when following Internet 
standards, result in 2 NS records per address, versus only 1 CNAME 
address under RFC 2317), along with your "bailiwick" religious 
affiliation that professes the legitimacy of claiming, on the public 
Internet, to be authority for zones which are not delegated to oneself. 
But, even this individually-delegated-addresses+"bailiwick" magic fails 
to meet the split-org challenge when the names in question don't happen 
to bear a descendant/ancestor relationship to each other.

(And I find it ironic that you would recommend this "bailiwick" 
snake-oil, which has a *huge* risk of producing negative (unintentional 
cache poisoning) results, because of a few popular DNS implementations 
which don't rank data properly as per RFC 2181, while at the same 
recommending against CNAMEs because a few obscure DNS implementations 
supposedly have problems with them...)

                                                                         
                                 - Kevin