Subject: On wild cards

From: Edward Lewis <[email-masked]>
Date: Thu, 4 Sep 2003 09:56:54 -0400

While I appreciate discussion of existence, the difficulty of 
detecting when an answer indicates no data is available, what this 
means for DNSSEC, and the general need of the DNS protocol to be 
overhauled with a jackhammer and backhoe, there are a few issues 
outstanding that aren't getting the attention they deserve.

These issues are in Simon's recent message.  He caught a few things 
in RFC 1034, section 4.3.3. that the wild card clarification 
conflicts.  (Most importantly, these *are* issues dealing with the 
synthesis and treatment of wild cards.)  Please take time to review 
those issues and decide if the document will change 1034, or will we 
rescind the proposed text?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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

--
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: Peter Koch <[email-masked]>
Date: Sun, 07 Sep 2003 23:46:52 +0200

> rescind the proposed text?

wildcards are counter intuitive enough and there's little use for them
today anyway. I've never seen multi-wild cards in the wild (pun intended)
and didn't miss them so far. Multi-wild cards are not really that general,
since the name has to start with a '*' anyway (i.e. it's still not allowed
to define "www.*.example.com", although a certain group of people would love
this) and there's enough space for ambiguity left (for example, how is
"sub.sub.sub.sub.example" matched against "*.sub.*.example"?). So, although
you put really some brain cycles into appendix A I'd rather see a clarification
that translates "should not" as in RFC 1034 into "MUST NOT" as of today.

I do not, however, understand why a cache shouldn't remember a response
to a "wildcard" (i.e. "*.<something>") query. Probably that was meant to
discourage synthesis of responses by (non-authoritative) caches. Wildcard
synthesis should of course only be performed by an authoritative server.

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Mon, 8 Sep 2003 09:40:05 -0400

>that translates "should not" as in RFC 1034 into "MUST NOT" as of today.

No argument at all about multi-wild cards being "perverse" (to borrow 
the words of another person in private email), and the brain cycles 
would have been lost to beer anyway.

But the question is - if we say "MUST/SHOULD NOT" what are the 
implications?  Do we refuse to load a zone into the master if such a 
name is found?  Do we drop an AXFR connection if one is found (and I 
do mean an "AXFR")?  (Or IXFR?)  What if the name is in a dynamic 
update?  (An issue for RFC2136++.)

>synthesis should of course only be performed by an authoritative server.

I agree, how does the WG want to proceed.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Peter Koch <[email-masked]>
Date: Mon, 08 Sep 2003 17:30:14 +0200

> update?  (An issue for RFC2136++.)

a less drastic approach than explicitly dropping RRs owned by a "multi-
wildcard", would be to just not treat the inner wild card(s) "special".
I.e. for "*.sub.*.example" the inner "*" would only be matched literally.
Would, however, be hard to list the parents of "*.sub.*.example" because
the '*' can't be escaped.

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Mon, 8 Sep 2003 12:42:06 -0400

>wildcard", would be to just not treat the inner wild card(s) "special".

This adds a step to 4.3.2c - (instead of just determining that a 
match is impossible and then seek the wild card) you have to then 
also see if the wild card found has descendents.

Again, I agree that these things are of no real use.  But every time 
I've tried to defend the outlawing of behavior on the basis of it 
being "useless" or "senseless" or "undesirable" (as opposed to being 
truly harmful) I keep finding more tar pits to build fences around. 
(This "philosophical moment" extends beyond the wild card issue.)

If we don't admit the names to the DNS because the syntax is 
offensive, then we are setting a precedent as no (other) names are 
illegal - and the added work load is in finding all the places an 
"illegal" name would have to be detected.  If we allow these names 
into the service but restrict their impact, we have to modify what's 
in 4.3.2 and in the instructions for the readers of the message.  (So 
long as there are legacy servers, these names might be sent.)  If we 
accept them despite what 1034 says, then wcard-clarify is 
inconsistent when it says it doesn't change 1034.

>the '*' can't be escaped.

Well, 'sub.*.example' wouldn't need any escaping because we would be 
changing the semantics of the name, not the syntax.

...I guess we could look at the question in another light...is the 
passage in 1034 (4.3.3) sufficient when it says they should not be 
there?   Are implementers comfortable with the lack of specificity 
here?  Is there a reason to try and define one way of doing this, or 
is the drive for interoperability preceding the need to interoperate 
in this case?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer