Subject: Re: question about dnssec-protocol-04

From: David Blacka <[email-masked]>
Date: Mon, 22 Dec 2003 22:33:22 -0500

On Monday 22 December 2003 3:41 pm, [email-masked] wrote:

> 	A signed zone should return the same answers as a unsigned
> 	zone modulo DNSSEC records.

Where does this requirement come from? 

> > It is true that I cannot think of any useful reason to do this, but
> > forbidding such NSEC records should have some real problem associated
> > with it.
>
> 	Without the rule it also means that a UPDATE client needs
> 	to know to delete NSEC when the last regular record is
> 	deleted.  This introduces race conditions between the client
> 	and the server which don't exist if the server is left to
> 	manage the creation and deletion of NSEC.

I don't see how allowing solo NSEC records is incompatible with the server 
manging the NSEC records.  That seems like a policy issue to me.  I will 
agree that UPDATE clients shouldn't deal with NSEC records directly.

I'll be clear here:  I am not bothered by this restriction per se.  While I 
haven't seen the light as to why solo NSEC records are bad, I also think that 
they are useless.  What bothers me is that a) if they are harmless, then they 
shouldn't be forbidden, and b) if they aren't, then the "why" of the rule 
needs to be in the document as well.  If I'm confused by this now, then 
someone two years from now will probably be confused by this as well, and 
telling them to search the namedroppers archives for a explanation is 
not...good.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

--
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: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 23 Dec 2003 11:56:55 -0500

</chair>

>Where does this requirement come from?

This requirement was placed on the work that lead to RFC2065
thus it has been there for about 10 years in both RFC2065 and RFC2535
this was viewed as backwards compatibility.

>agree that UPDATE clients shouldn't deal with NSEC records directly.

With the requirement this is a snip of a "random" large delegation zone
(RRsig's omitted for clarity>

ogud.com        NS      <ns set with 3 servers>
                 NSEC    ogue.com NS DS NSEC RRSIG
                 DS

ogue.com        NS      <ns set with 2 servers>
                 NSEC    <points somewhere>

Without the restriction following is a valid zone snip

ogud.com        NS      <ns set with 3 servers>
                 NSEC    ogud1.com NS DS NSEC RRSIG
                 DS

ogud1.com       NSEC    ogud2.com NSEC RRSIG
ogud2.com       NSEC    ogud3.com NSEC RRSIG
....
ogud99999.com   NSEC    ogude.com NSEC RRSIG

ogue.com        NS      <ns set with 2 servers>
                 NSEC    <points somewhere>

but what is the value of this ?
The zone is larger (not a good thing) and to a non DNSSEC aware resolver
it looks like there is wild card in the zone when there is none.

Second point, without this rule a dynamic update nameserver may elect
not to delete NSEC records when the other records at the name are deleted
as it is looks like less work, but it is not.
In either case one NSEC record needs to be updated either the one
at the name or the one of the name preceding the updated.

>telling them to search the namedroppers archives for a explanation is

The records are almost harmless.

<chair>
I think this is a good point, if David is confused someone else will be
thus we should add text to the document explaining the reasons.

         Olafur