Subject: Re: Comment on draft-ietf-dnsext-wcard-clarify-01.txt

From: Simon Josefsson <[email-masked]>
Date: Wed, 03 Sep 2003 00:14:12 +0200

Repost from a private thread in order to get input from WG:

,----
| 4 Impact of a Wild Card Domain In a Query Message or in an RDATA field
| ...
| R4.1 A wild card domain name acting as a QNAME MUST be treated as any
|        other QNAME, there MUST be no special processing accorded it.
`----

This appear to be over-qualified; it isn't valid in the point of view
of a client.  Specifically: RFC 1034 section 4.3.3 says results from
wildcard queries should not be cached.  Hence there actually is
special processing accorded to wild card labels in a QNAME.

The last note of section 2, and the entire appendix A, seems at least
partially inconsistent with RFC 1034.  Specifically: RFC 1034 says a
wildcard RR look like *.<anydomain> where <anydomain> should not
contain other * labels.  So *.*.example is not a valid wild card
according to RFC 1034, contrary to what the draft claims.  If
something needs to be clarified, how about making a clarification
saying that <anydomain> 'MUST NOT' contain other * labels?  If the
draft intend to redefine RFC 1034 on what <anydomain> may contain,
that should IMHO be made more clear, as the abstract now give the
impression that the draft doesn't alter any definitions.

Thanks,
Simon

--
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: Edward Lewis <[email-masked]>
Date: Wed, 3 Sep 2003 09:23:06 -0400

>special processing accorded to wild card labels in a QNAME.

Splitting hairs, the requirement in wcard-clarify talks about the 
query, not the caching of the result.  I can make a note that 1034 
states to not cache the result, but otherwise I don't see special 
processing during the query process.

>impression that the draft doesn't alter any definitions.

There's a quite explicit contradiction here.  On the one hand, 1034 
bars multiple '*'-names.  When doing the research behind 
wcard-clarify, this was missed, but we did find that they "work" on 
paper and even when tested in some software laying about.

There are two options here, just as Simon mentions.

1) Undo what's in Appendix A to remain in line with 1034.

2) Allow "them" and alter the intro/abstract to say that definitions 
are changed.

I may need to soften the statements that nothing is changed because 
we have redefined "CNAMEs at wild cards."

I'll say one thing in defense of allowing multiple-*'d names.  They 
work without a meltdown.  I.e., the don't seem to cause harm.  Why I 
favor them for this is that if we retain the restriction against 
them, we should specify what happens if they are seen - in 
configurations, in zone transfers, and in responses and queries.  If 
we allow them, there are no special rules to specify and enforce.

I'm for fewer error conditions.

When the doc was individual I mentioned that nothing was changed 
other than existence, and any changes were in error.  Being that it 
was then an individual submission, I didn't want to propose changes. 
Now that this is a WG doc, it's up to the WG and the WG can make 
changes.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Sponge Bob Square Pants?  I'm still trying to figure out the Macarena.