Subject: Re: wcard-clarify violating RFC 2119, section 6

From: Paul Vixie <[email-masked]>
Date: Thu, 04 Sep 2003 04:24:06 +0000

>   | 	RFC 1034 provided no way to express such a construct.  It would
>   | 	require meta data to be transmitted.
> 
> Yes, I guess the closest currently possible would be a name with just
> a NULL RR - which is about as useful as a name with no RR's, given that
> NULL has no defined uses (or syntax) that I'm aware of.

if it had a NULL RR then it wouldn't be empty.

--
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: Thu, 25 Sep 2003 18:24:19 +0000

ok, i get it.  so to clarify this document further, one could add a
note that says "as a result of not being allowed to cache these names,
the caching name server will never have an opportunity to assume the
role of synthesis, which is therefore reserved for authority servers."

---

From: Paul Vixie <[email-masked]>
Date: Sun, 28 Sep 2003 22:58:56 +0000

> But, if you follow the algorithm in section 4.3.2 precisely (exactly as
> it is written, with no latitude for common sense) then a wildcard would
> match a CNAME only for a lookup of type CNAME, and no other.

i consider that the correct, and sensible, interpretation.  clarification
is needed only because it's astonishing to some, not because it's unclear
as written.

> That's because 4.3.2 (3) c says...
> 
> 	    If the "*" label does exist, match RRs at that node  
>             against QTYPE.  If any match, ...
> 
> So, if the '*' is of type CNAME, and QTYPE is A (or AAAA or MX or
> whatever), then no data gets copied into the answer, and the "goto 6"
> doesn't happen.

right.  cname processing happens earlier than, and exclusive of, wildcarding.

> Of course, in this case, since nothing says "set an authoritative name
> error" (as it does if the '*' doesn't exist), one must presume that
> the correct answer is NODATA (no answer, no error code).

i think if someone puts a wildcard cname into their zone, then noerror/nodata
is the correct answer.  (the workaround is, don't put in a wildcard cname.)

> I disagree with Paul's suggestion though - I don't think it is rational
> to simply leave 1034 unchanged here - either CNAME at a '*' label needs
> to simply be made invalid, or 4.3.2 (3) c needs to be fixed to allow
> CNAME processing to take place there.

then at least our disagreement requires no clarification.

> ps: Paul, I won't be in Minneapolis, so if you want to give the longer
> rant as to why a better change would be to make "* IN CNAME ..." illegal
> rather than making it effective, you have better do it on the list.

i don't expect that we'd entertain anybody by such ranting.  let's see if
anyone else has a view on this topic.

> I think this is one area however where a fix is essential - and this is
> a fix to wildcard processing, so this draft is where it should happen.

at a minimum, i think that this draft should only clarify, not "fix" things.
separately, we can rant about whether rfc1034 needs to be "fixed".