Subject: Re: DNSSEC wildcard optimization.

From: Olaf Kolkman <[email-masked]>
Date: Thu, 24 Oct 2002 08:15:17 +0200

David Conrad <[email-masked]> writes:
 * 
 * Modifying the DNSSEC specs in non-backwards compatible ways _yet again_ is a
 * "BAD" idea.
 * 
 * Can we please stop?  I would personally like to see DNSSEC deployed in my
 * lifetime.

I think that the draft brings considerable optimizations for the
common case of zones without wildards. If there would not have been a
cut of date I would not have brought it to the table.  Either it flies
with opt-in/DS or it does not fly at all.

DNSSEC should fly, preferably yesterday, but I think this helps
interpreting denial of existence of wildcards for both operators and
in code. 

 * > Thus if the misunderstanding is corrected and we explain to the few
 * > application communities that are using wild cards in a legit way
 * > to push names out of DNS, what the DNS problems are, maybe we can make
 * > wildcards go away.
 * 
 * Don't be silly.
 * 
 * Wildcards are seen as providing useful functionality.  Attempts to remove
 * them, regardless of the validity of the attempt, will get dragged down into
 * non-terminating IETF politics.
 * 
 * Given wildcards exist, any attempt to remove them from DNSSEC will simply
 * mean disincentives for DNSSEC deployment.  We do NOT need more disincentives
 * to deploying DNSSEC.
 
This draft is not about removing wildcards from DNSSEC. It is about
making the processing of denial of existence easier, somewhat faster
and reduce packet size in the common case. 

Wildcards should not be removed from the DNS protocol just to make DNSSEC
fly. 

--Olaf

--
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: Derek Atkins <[email-masked]>
Date: 24 Oct 2002 09:55:14 -0400

Hi,

<DNSDIR Hat>

I happen to agree with Olaf here.  The issue with wildcard processing
is that in the _NORMAL_ case (i.e. a zone without wildcards) you need
to ALWAYS provide not only the proof of non-existence of the QNAME but
ALSO proof of non-existence of the wildcard.  Indeed, you need to
provide both proofs in ALL responses.

If we can (quickly, before DS goes out) agree on an optimization for
wildcards it would ease the network issues, because in the "normal"
case you can just send the proof of non-existence of your QNAME with a
flag that says "and there is no wildcard either".

If we cannot agree on an optimization, then we are forever required to
send multiple NXT/SIG records for all responses, or we must remove
wildcard support.

</DNSDIR Hat>

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: David Conrad <[email-masked]>
Date: Fri, 25 Oct 2002 05:34:08 -0700

Olaf,

> common case of zones without wildards.

I do not disagree that your draft can provide optimizations.  My concern is
that the corner cases not addressed in your draft (e.g., ddns) will require
additional iterations before we can be confident it doesn't have weird side
effects.  Should the new DNSSEC wait for those iterations to complete?

I'm also worried about _any_ additional complexity within the server --
optimizing tends to add special cases and code shortcuts.  DNSSEC is already
far too complex, as we all know.

Finally, at least with both opt-in and DS, I know of implementations.  Has
anyone implemented your proposal yet?

> This draft is not about removing wildcards from DNSSEC.

Right.  I was addressing Olafur's comments.

Rgds,
-drc