Greetings!

>At 2:54 AM -0700 1/1/02, Don Yuniskis wrote:
>>  >>Note that CNAMEs can be a problem with some tools.
>>  >
>>>My protest
>>
>>CNAMES are huge sources of potential screwups...
>
>"CNAMES are a huge source of potential screwups" is a *MUCH* 
>different statement than "CNAMEs can be a problem with some tools."

If the end result is the tool doesn't achieve the desired result
*because* of the CNAME's presence, then I think it safe to say
that "CNAMEs can be a problem with some tools."  Whether you blame
the tool's author for imperfectly implementing CNAME resolution
*or* the DNS administrator for needless use of a CNAME, the
end user finds that he doesn't get what he wants...

>DNS in general is a huge source of potential screwups ;-). That was 
>why we were discouraging a newbie from attempting in the first place 
>;-). That's also why the DNS and BIND book is so freaking huge. If 
>you set up your files correctly, there is no difference between a 
>CNAME and an A record WRT their ability to work with every tool & 
>utility.

Your argument is a bit naive.  You're expecting every DNS
to be configured properly.  Then, isn't it just as fantastic
to assume that all software that relies on name resolution
will be "100% bug free"?  :>

Would it be "acceptable" for a tool to crash the system if
it encountered a misconfigured DNS?  I.e. look through the
logs and find:
    "Tried to resolve X.y.z but the DNS was misconfigured
     so I am now repartitioning the system disk prior to
     crashing..."
(this is the argument I use with clients who claim that they
"don't care" what happens in some particular situtation  :>)

Note that this puts "me" at the mercy of every DNS operator
at any SOA that I might eventually want to interact with
(along with every DNS operator at any SOA that *he* does...).
If he hasn't done his job right, *I* pay the price (since "my"
tool only works with "correctly configured" DNS's...)

Of course not!  When *designing* a good tool, you have to 
either scrutinize everything *literally* and complain if 
things don't match your expectations (and then quit) *or* 
be tolerant of things that are possibly (*probably*!) not 
set up properly.

Perfectly legitimate DNS database:
    A CNAME B
    B CNAME C
    C CNAME D
    D CNAME E
    E CNAME F
    F CNAME G
    G CNAME H
    H CNAME I
    I CNAME J
    ...
    YY CNAME ZZ
    ZZ CNAME foo
(I didn't claim it was *rational* -- just "legal"  :>)

Now, your tool needs to resolve a name -- "A".  If it
assumes everything is configured correctly (see above),
it will *eventually* find "foo"... after burning gazillions 
of CPU cycles  :-(

But, *assuming* everything is configured properly, we
would crash and burn if:
    A CNAME B
    B CNAME A
(or countless variations thereon).

So, it seems prudent to design some mechanism to check
for circular references in (misconfigured) DNS's.

The *ideal* algorithm would note every name that it
resolved and, when encountering a CNAME, check the
*entire* list of names to see if this appeared
anywhere else in the list previously.  If so, assume
a circular reference (I am ignoring for the moment the
pedantic case of a TTL on one of those entries expiring 
in the process and a second encounter of a name could
actually be legitimate and ultimately lead to a
definite resolution).

But, keeping that list can get expensive (memory as
well as time to scan it for duplicates -- even with
a simple hash).  Especially since you could have
several clients trying to resolve names at the
same time.

And, hey, if CNAMEs are "fine and dandy", then I should be
able to use them whenever and wherever (and as deep as!)
I want, right?  :>

So, you economize on the algorithm and just limit
the *length* of the chain you will follow.  I.e. you
restrict the "diameter" of the circular list you can
detect (anything that *appears* larger than N links
*must* be a circle).

What value for N?  I can create a chain of CNAMEs
that has N+1 members.  It *will* resolve to a unique
host name -_ *if* you are persistent.  But, if your
tool gives up after N tries, you will *never* be able
to resolve that name!

The DNS administrator hasn't "misconfigured" anything.
He may be a triffle insane, but he hasn't done anything
wrong.  Yet, the tool either works and is susceptible
to circular references (the first example) *or*
doesn't work but is immune to circular misconfigurations
(the second example).

Blame the tool for a less than ideal implementation?
"75% of all DNS names are CNAMEs" (?)  What if folks
chose to implement *all* of those as long chains??
"Entirely within your rights..."

Ah, OK.  Let's make a rule -- no more than N links
in a CNAME chain.

Fine.

But, now if you specify a canonical name that is in a different
SOA as the target of your CNAME, you have imposed a limit
of "N-1" on the DNS administrator of that other SOA for
that particular targeted name!  If he/she opts to slip
another name in the chain on *his* end, suddenly, your CNAME
is N+1!  Likewise, if some DNS administrator of an SOA that
*he* references decides to increase his chain from N-2 (!),
then he *and* you can be screwed...

Remember, I haven't "misconfigured" anything, here.
I am just exploiting a *feature* to it's fullest!  :>

This is analagous to placing a limit on the number of
levels of #include in a C source file.  If your coding
standards allow *any* nesting, then each person who
#includes a file suddenly has to check the depth of the
#includes since his "added level" may put this "over the
limit".  :-(  So, you see coding standards that outright
DISALLOW this "feature" (nesting).

I *think* the trend in the RFC's is to disallow CNAMEs
in MX records "officially" (I think there has been some
vagueness about the actual verbage in the past... some
conflicting RFC's, etc.).  So, is sendmail "broken"
if it follows (but complains!) a CNAME in an MX record?

>>As I said previously, DNS is not trivial to set up
>>*right*...
>
>Correct. Again, that is a much different statement than "CNAMEs don't 
>work right".

Hmmm... I don't seem to find where *I* said "CNAMES don't work
right".  Or, have I misplaced an email?  :-/  (late nights...)

>As for your "examples"...all but one were the result of incorrect 
>configuration on the part of the DNS administrator, whether just 

Or some *remote* DNS administrator!

>getting local config wrong, or by making longevity assumptions WRT 
>other domains. That is not a shortcoming of the CNAME directive. The

Is typing:
    if (x = y) { ... }
a shortcoming of the language definition (= vs. ==)?  Or, just
a "programmer error"?  If the latter, then why do languages
evolve to eliminate these "problems"?  (A:  because they are
prone to misuse or abuse! -- shortcomings of the language as
originally defined... note "=-" et al. are no longer legal C)

The same sort of argument can be applied to things like
#define's, mixed uppper/lower-case in identifiers, etc.
"Features" that tend to *increase* problems (granted,
*ALWAYS* because they were misused or typographical errors,
etc.) are eventually weeded out of protocols, languages, etc.

Using your "75%" example (specious), how many of those
are simple CNAMEs like:
    ftp    CNAME    myhost1
    www    CNAME    myhost2
etc.?  I.e. these could be handled with A records just
as easily.  Or, automate the process with m4(1)...

CNAMEs allow the *local* DNS administrator to place himself at
the mercy of *other* DNS administrators since CNAMEs can
reference canonical names in other SOA's.  As such, it
*increases* the chances of *your* DNS being wrong -- even 
though *you* have done everything "right".  And, of course, it
increases the chances that *you* will do things wrong as
well!
 
>other "example" is a failing on the part of the "security officer" 
>who is deluded into thinking that every machine on the Internet 
>should validly have exactly one A record and a single PTR record. 
>That ain't gonna happen. Not today, not ever. Example...do a lookup 
>on ftp.apple.com, and you'll see that it points to 17.254.0.31, 
>17.254.0.26, and 17.254.0.27. When you reverse those, you'll get 
>ftp08., ftp06., and ftp07.apple.com. Lookup www.cnn.com, and you get 

This is exactly the problem.  Though smarter authentication agents
would do a double lookup (i.e. forward on ftp08.apple.com to verify
that it resolves to 17.254.0.26) and satisfy themselves that
all *appears* consistent...

How do you deal with "certificates" built using one name
but authenticated against *another* (based on reverse of IP)?
I.e. changing:
    A CNAME B
    B IN A x.x.x.x
to:
    B CNAME A
    A IN A x.x.x.x
(with the implied PTR changes) *should* be equivalent.  
But, certificates made on that physical host while configured 
as "A" may suddenly stop working when the DNS is tweeked and 
the same *physical* machine now appears to be "B"...  How many
users on "A" are affected?  If the mapping of name to IP
was one-to-one, then this wouldn't happen (unless you changed 
the actual name or IP address)

So, another potential pitfall that the unwary DNS admin
can get caught in *because* of the CNAME...

Another source for bugs in a browser that now must try to
be CNAME aware when attempting to handle certificates
in a "user friendly" manner...

Just like "=" vs. "==" is a pitfall that C programmers
face *because* of the language definition...

>5 IP addresses...only one of which should properly be reverse mapped 
>to www.cnn.com ;-). Here's a few more:
>
>alpha# nslookup pop3.mail.com
>Name:    pop15.pr.outblaze.com
>Address:  205.158.62.124
>Aliases:  pop3.mail.com, mail-com-p3.pr.outblaze.com
>
>reverse on this failed
>
>alpha# nslookup pop.mail.com
>Non-authoritative answer:
>Name:    pop.mail.com
>Address:  165.251.32.211
>
>reverse on this produced 205-158-62-124.outblaze.com

You can, of course, use CNAMEs as you wish.  Until the powers
that be (IETF?) decide that a "feature" becomes a "liability".
Then, the feature goes away and you figure out how to live
without it!  :>

I have multiple names for many of my hosts (www, ftp, mail,
fonts, bootp, etc.) but all are defined using A records.
Of course, only one PTR record exists for each.  And, I am
disciplined enough to always use the *real* name of the
host/ionterface (i.e. none of the vanity names) in that
case.  And, I make sure I build all my certificates,
ssh key files, etc. with *that* name instead of any of the
vanity names.  But, I can do this because I am intimately
aware of all of the names, aliases, etc.  I don't think I
could count on another user to avoid those pitfalls...

You will note that many large institutions actually have
policies in place that "strongly discourage" (if not
outright forbid) the use of CNAMEs in their DNS...  I
guess the adage "once bitten, twice shy" (?) applies.

YMMV,
--don