Subject: NSEC3 Dynamic Update (proposed)

From: Ben Laurie <[email-masked]>
Date: Wed, 17 May 2006 09:09:54 -0700

An NSEC3 zone may accept dynamic updates for delegations. If it does,
then there are four possible actions it should take, depending on
whether the zone is opt-out or not and whether the update is an add or a
delete.

If the zone is not opt-out and the update is an add then the server MUST
generate new NSEC3 records for the newly added owner name and each empty
non-terminal it generates (or update the existing NSEC3 records).

If the zone is not opt-out and the update is a delete which removes the
ownername from the zone, then the server MUST remove all NSEC3 records
which contain names made non-existent by the removal of the deleted
record, and generate new NSEC3 records for those names still in the zone
whose NSEC3 records were removed by that deletion.

If the zone is opt-out and the update is an add then, if the update is
for any record type other than NS, the server MUST generate new NSEC3
records for the newly added owner name and each empty non-terminal it
generates (or update the existing records). For NS records, the server
MUST update any existing NSEC3 records, but MUST NOT generate any new
NSEC3 records.

If the zone is opt-out and the update either removes the ownername or
leaves only NS or glue address records at that ownername, then the
server MUST remove all NSEC3 records which contain hashes of names made
non-existent by the removal of the deleted record's ownername, and
generate new NSEC3 records for those opted-in names still in the zone
whose NSEC3 records were removed by that deletion.

Comments?

Cheers,

Ben.

-- 
http://www.links.org/

--
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: Mark Andrews <[email-masked]>
Date: Thu, 18 May 2006 10:22:28 +1000

As background we were also discussing whether a zone should
	be all opt-out or allow a mixture of opt-out and plain nsec3
	records.

	As far as I can tell there is no real benefit for a mixed
	zone.  You would have to work out which nsec3 spans a given
	delegation that you wanted to be opted in would has hash into.

	Also removing the ability to mix and match would simplify
	update and the initial signing of the zone especially if
	you didn't also have to track which delegations had to
	provably exist or not.

	The rules below give secure delegations probably exist and
	insecure delegation do not probably exist for opt-out.  A
	zone would be opt-out / plain based on the setting of the
	opt-out flag in apex's NSEC3 record.

	I think KISS is a good principle to apply here but it is
	a trade off.

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

---

From: Roy Arends <[email-masked]>
Date: Fri, 19 May 2006 14:30:31 +0200

>    delegation that you wanted to be opted in would has hash into.

I agree. There is no real benefit.

>    you didn't also have to track which delegations had to

Signing needs an extra 'round' over all the added NSEC3 records to wether 
it covers hashes of unsigned delegations or not. There are many approaches 
to this, but they all lead to more work than just 'optout=0' or 'optout=1' 
for the entire zone.

>    opt-out flag in apex's NSEC3 record.

Provably, right ? 

>    I think KISS is a good principle to apply here but it is

I agree with all of the above. I think that Ben's 'dynamic update' text is 
sufficient.

Roy