Subject: question about dnssec-protocol-04

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

draft-ietf-dnsext-dnssec-protocol-04, section 2.3 has the following 
paragraph:

   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
   RRsets at any particular owner name.  That is, the signing process
   MUST NOT create (or RRSIG) RRs for owner names nodes which were not
   the owner name of any RRset before the zone was signed.

[There is an editing nit here, too: s/MUST NOT create (or/MUST NOT create 
NSEC (or/, I think.]

I feel sure that I have just forgotten the discussion about this, but why 
does this restriction exist?  What harm would NSEC records of this sort 
cause?

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.

-- 
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: Rob Austein <[email-masked]>
Date: Mon, 22 Dec 2003 15:17:08 -0500

> forbidding such NSEC records should have some real problem associated with 

Empty non-terminals.

---

From: [email-masked]
Date: Tue, 23 Dec 2003 07:41:09 +1100

> does this restriction exist?  What harm would NSEC records of this sort 

	A signed zone should return the same answers as a unsigned
	zone modulo DNSSEC records.
 
> forbidding such NSEC records should have some real problem associated with 

	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.
 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]