Subject: thesaurus attack

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Sep 2004 10:13:39 -0400

Now that I've got your attention, let's talk wild cards...

In the past week or so -

1) The history of wanting to clean up what's the deal with wild cards 
has returned, with some talk about legal names.  (This is one of the 
issues on the table.)

2) A well known coder supported the idea of making some names 
illegal, presumably this makes the coding cleaner as you then know to 
have "if"'s in some places.

3) A well known protocol analyst rejected the idea of makeing some 
names illegal because imposing restrictions would have two impacts - 
possibly retroactively creating bugs in code and restricting the 
theory and concept of the protocol.

4) Many unnamed operators have remained silent on the subject because 
no one really does this anyway.  Oh, 'cept that the MARID WG seems to 
have thought they might have wanted to open this box belonging to 
Pandora.

As editor of the document, I'd like to see us all get to something we 
can live with.  From the MARID experience, it's clear that we want to 
clarify what's going on here, ergo, we need to do something.

I'll float this idea.  It's an idea, I think it can work, but it's up 
to the WG.

REMOVE the restriction in 1034: "<anydomain> should not contain other 
* labels".

This opens the protocol to places it's not been, so there's no danger 
to old code.  Further, by relaxing a restriction it does not impinge 
another part of the protocol.

As far as "is it doable" - a lot of text has already been floated 
showing how the matching is "supposed to" work in the face of 
interior "*"s.  No one pointed out a problem with it until the words 
in 1034 were raised.

Those words in 1034 are the only ones that define "illegal" names in 
DNS.  Without them, we have no restrictions other than length (label 
and name).  In addition, dropping the restriction drops one more "if" 
statement (whose "then" clause wasn't really defined) while still 
leaving us with a "decidable" algorithm.

Comments?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

--
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: Sat, 11 Sep 2004 00:14:08 +0200

Robert Elz <[email-masked]> wrote:

> Here, the "empty terminal" only appears in the answer to a query, where it
> cannot be detected as being terminal, so there's no need to do anything
> special to avoid this case, just leave it.

OK, but then for the sake of clarity the draft should mention this case
explicitly, e.g.:

Empty Terminals

  Empty terminals (leaves) do not exist without wildcards because there is no
  defined way to bring a name into existence without making it or one of
  its descendants (then it would be no longer a terminal) the owner of at
  least one RR. Although there is a NULL RR type specified in RFC 1035,
  its purpose is left open.
  With '*' names in the zone, empty leaves can exist iff the '*' does not
  own any RRSets.
  Given example.org,
	@	SOA ...
		NS  ...
	_.*	NULL {or any other type}
  any name X.example.org with $X != '*' will exist (not result in an
  authoritative name error if queried for) but have no RRs associated with it.

-Peter

PS: Wouldn't that stop me from "enumerating" enum zones ?-)

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Sep 2004 07:45:04 +1000

> >Yes, though I'm not real sure I like that term - but I'm not sure what
> >would be a better one.
> 
> If you imagine the name space as a two-dimensional field (like the 
> Venn diagrams I learned sets from), domains would be nested.  That's 
> where the notion of "closest enclosure" comes from.  It's not so 
> clear if you think of the stick and node tree diagram.

	deepest match / longest match
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Sep 2004 08:11:19 +1000

>     Date:        Mon, 13 Sep 2004 16:38:55 -0400
>     From:        Edward Lewis <[email-masked]>
>     Message-ID:  <a0602040bbd6bb479d3e3@[192.136.136.102]>
> 
>   | >as I understand it, the proofs need to involve the '*' record explicitly
> ,
>   | 
>   | On the first cut, authenticated denial ("DNSSEC purposes") doesn't 
>   | require proof that there is no "*"/"wild card"/"source of synthesis," 
> 
> I'll reply to other messages later, but in the above, I wasn't talking
> about denial at all, but proof of legitimacy of a RR generated (synthesised)
> from a wildcard RR.
> 
> That is, I lookup foobar.example. MX, which doesn't exist, but example.
> contains *.example. MX 10 whatever.   That means the answer I get is
> foobar.example. MX 10 whatever.   That RR needs to be authenticated, but
> there cannot be a SIG for it (or not without on-line keys).
> 
> Without having attempted to find the actual answer to this, I'd assume that
> what is required is the *.example. record itself, its SIG, plus proof that
> foobar.example. doesn't exist - all being used as positive proof that the
> MX record in the answer section is indeed what it is supposed to be.
> 
> kre

	If * has data of the requested type then the RRSIG(type) for *
	+ noqname proof (NSEC + RRSIG(NSEC)).

	If * has data but not of the requested type then NSEC for * +
	RRSIG(NSEC) + noqname proof.

	If * has no data but has children the NSEC that spans * +
	noqname proof.

		e.g. qname d.a.example
		a.example NSEC b.*.a.example	(nodata proof, wildcard exists
						 with nodata)
		b.*.a.example NSEC e.example	(noqname proof, deepest match
						 gives a.example -> *.a.example
						 for wildcard)

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Sep 2004 18:13:02 -0400

>	deepest match / longest match

The reason I avoided those terms is that they are too lexically close 
to what's used in routing to mean the same thing, only completely 
differently.  I.e., the most significant bit in an address is on the 
left, the most significant label is on the right.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer