Subject: Re: wcard-clarify's change

From: Paul Vixie <[email-masked]>
Date: Fri, 03 Oct 2003 18:12:11 +0000

>   | > I can live with either, no problem outlawing CNAME in a '*' record.
>   | 
>   | as paul said, that is a change, not a clarification, and hence
>   | outside the range of this document.
> 
> Randy, something has to be done.  The option that can be argued that
> is not a change is to explicitly permit CNAME in wildcards, and actually
> make it work correctly.   That would be OK too.   But just doing nothing
> is unacceptable.

i think that clarifying rfc1034 is the right goal, and that in this case,
that means clarifying that wildcard CNAME's will result in noerror/nodata
responses, which is (a) useless and (b) counterintuitive and (c) probably
not what the zone editor wants and so therefore (d) it's not recommended.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Sat, 04 Oct 2003 15:40:22 +0000

robert,

presenting wildcard cnames that way (declaring them broken vs. fixing them)
presumes facts not yet generally accepted.

consider this text from rfc1034:

	If a CNAME RR is present at a node, no other data should be
	present; this ensures that the data for a canonical name and its
	aliases cannot be different.  This rule also insures that a
	cached CNAME can be used without checking with an authoritative
	server for other RR types.

this argues that a wildcard cname would be legal if there were no other
descendents of the same parent.  what's strange is that pvm said "at a
node" rather than "whose owner matches the qname".  but the last sentence
is compelling evidence that the pseudocode is not in error, that the
behaviour you're calling "broken" was intentional, and that wildcard
cnames really just don't do what people intuitively feel they ought to.

paul