CNAME Definition

[Kevin Darcy]

Erik,
        The SIG, KEY and NXT record types are "special" in specific ways that
negate the justifications for the "CNAME and other data" rule. Since they are
intrinsically connected to *other*records* within DNS (in the case of NXT,
the "other record" to which it is intrinsically connected is the one which
delimits the gap into which the non-existent queried record falls), the
concept of an inconsistency between SIG/KEY/NXT records owned by an alias
name and SIG/KEY/NXT records owned by the canonical name to which that alias
points, is meaningless. Another justification for the "CNAME and other
data" prohibition is so that recursive servers won't have to perform extra
fetches when the only thing they have cached is a CNAME matching the name
which a client queries (i.e. without the "CNAME and other data" rule, they'd
not only have to resolve the canonical name, but also query the authoritative
server(s) for the zone containing the CNAME to see if maybe the name owns one
or more records of the requested type). While it's true that a "security
aware" nameserver may sometimes have to perform this extra fetch to get the
SIG record associated with a cached CNAME, this is a *general* burden imposed
by DNSSEC on *all* record types, e.g. it would also have to do a fetch to get
the SIG record associated with a cached A record, a cached MX record, or any
other record. So waiving the "CNAME and other data" rule in this case doesn't
*add* any extra workload beyond what DNSSEC itself does.

Now, can one make the same case for waiving the rule in the case of
SOA and/or NS records? They are "special" records, to be sure, but are they
special in any way that negates the justifications of the "CNAME and other
data" rule? Nope. The danger of inconsistency is real (should I use the
NS records owned by the CNAME or the NS records owned by the canonical name,
or some combination of the two?) and the potential for excessive fetching by
recursive servers is imminent. The reasons for enforcing the "CNAME and other
data" rule with respect to SOA and/or NS records are just as compelling today
as when RFC 1034 was written, if not more so because SOA records are now used
in conjunction with the negative caching mechanism.

Of course, you're always welcome to propose a protocol change on
namedroppers...


- Kevin

Erik Aronesty wrote:

> Dear Joseph,
>
> By definition, yes.  I would never dispute that.
>
> But logically, SOA/NS's should be exempt from CNAME chaining.
>
> RFC2535/2.3.5 proposes that SIG/KEY/NXT records be exempt from CNAME
> chaining because they are 'special records' for which it is not logical to
> process chaining.
>
> In the case of doing nslookup -type=SOA on an aliased domain... the SOA
> should also be exempt from chaining for the same reason.
>
> The returned results from the current set of resolvers are misleading and
> incorrect for any purposes.
>
>                 - Erik
>
> ----- Original Message -----
> From: "Joseph S D Yao" <jsdy at cospo.osis.gov>
> To: "Erik Aronesty" <erik at primedata.org>
> Cc: <asenec at senechalle.net>; <comp-protocols-dns-bind at moderators.isc.org>
> Sent: Monday, February 05, 2001 1:41 PM
> Subject: Re: CNAME Definition
>
> > On Mon, Feb 05, 2001 at 10:08:32AM -0500, Erik Aronesty wrote:
> > > Or maybe BIND was right from the very beginning and the RFC's were
> wrong?
> >
> > Since BIND strives to implement the RFCs, if it were not implementing
> > an RFC then by definition it would be wrong.
> >
> > --
> > Joe Yao jsdy at cospo.osis.gov - Joseph S. D. Yao
> > COSPO/OSIS Computer Support EMT-B
> > -----------------------------------------------------------------------
> > This message is not an official statement of COSPO policies.
> >
> >