spf-discuss
[Top] [All Lists]

RE: CNAME limit

2005-07-21 19:19:09
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Stuart 
D. Gathman
Sent: Thursday, July 21, 2005 9:39 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] CNAME limit


On Thu, 21 Jul 2005, william(at)elan.net wrote:

Counting each CNAME as dns lookup is probably best. Then all
other issues
as far as limits and loops are already addressed by the spf draft.

I agree, but it has to be official.  Otherwise, people will get
different results depending on how they limit CNAME loops.
The current standard doesn't mention CNAME.  For that reason,
I think that the safest approach is to *not* count CNAME as "lookup",
but have an independent limit that is outside of the standard.

I will consider CNAME analogously to the limits on MX names and PTR
names, and apply a limit of 10 CNAMEs followed for each name lookup.

To be consistent, I would return TempErr on reaching it (since it
is not mentioned in the processing limits that return PermErr),
but I'll probably be ornery and return PermErr anyway, since the
domain has serious problems that need manual intervention to fix.

FWIW, I tried to come up with an "Official" answer before Stuart posted.
Here's what I found:

From RFC 1034:

"Of course, by the robustness principle, domain software should not fail
when presented
with CNAME chains or loops; CNAME chains should be followed and CNAME loops
signalled as an error."

and from RFC 2181 (which officially updates 1034):

"10.1. CNAME resource records

   The DNS CNAME ("canonical name") record exists to provide the
   canonical name associated with an alias name.  There may be only one
   such canonical name for any one alias.  That name should generally be
   a name that exists elsewhere in the DNS, though there are some rare
   applications for aliases with the accompanying canonical name
   undefined in the DNS.  An alias name (label of a CNAME record) may,
   if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
   other data.  That is, for any label in the DNS (any domain name)
   exactly one of the following is true:

     + one CNAME record exists, optionally accompanied by SIG, NXT, and
       KEY RRs,
     + one or more records exist, none being CNAME records,
     + the name exists, but has no associated RRs of any type,
     + the name does not exist at all."

The way I read the former is that this is no limit on the length of a CNAME
chain, but loops are an error.  The way I read the latter (which has
official status as updating the first) is that a CNAME can't point to
another CNAME.  In other words, a "canononical name record" actually has to
point to the actual canononical name.  Is that right?

In fact, the next paragraph goes on to say:

"10.1.1. CNAME terminology

   It has been traditional to refer to the label of a CNAME record as "a
   CNAME".  This is unfortunate, as "CNAME" is an abbreviation of
   "canonical name", and the label of a CNAME record is most certainly
   not a canonical name.  It is, however, an entrenched usage.  Care
   must therefore be taken to be very clear whether the label, or the
   value (the canonical name) of a CNAME resource record is intended.
   In this document, the label of a CNAME resource record will always be
   referred to as an alias."

That tends, I think, to reinforce the interpretation that CNAME chains are
disallowed by RFC 2181.

So, a conservative approach, that a validator might take, would be be
PermError if they hit a chain, because receivers might do that based on
2181, but, even though 2181 is 8 years old, it's not entirely clear and so
an operational checker would likely want to be more liberal.....

Comments?

Scott K


<Prev in Thread] Current Thread [Next in Thread>