Subject: NSEC3 and dynamic update issues.

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Mon, 30 Oct 2006 09:35:56 -0500

Following was observed in the NSEC3 workshop in September 2006.
#1 NSEC3PARAM controls how an authorative server looks for negative
    answers in a zone.

#2 Changing NSEC3PARAM implies that there is a full chain of corresponding
    NSEC3 records in place before the NSEC3PARAM record is added.

#3 If NSEC3PARAM is changed via dynamic update the primary server should
    generate the new NSEC3 records before inserting the new NSEC3PARAM,
    possibly taking a long time. The dynamic update client may time out
    and retry the operation.

#4 Changing the NSEC3PARAM via dynamic update may cause significant work load
    on the master server and large number of Notify and IXFR transaction
    possibly causing operational issues for some/all of the nameservers
    serving the affected zone.

#5 This is per se is NOT a NSEC3 issue BUT a dynamic update issue.
    Some of the issues above apply to any DNSSEC signed zone
    when signing keys are changed.

Recommendation:
The sense-of-the-room at the workshop was that dynamic update of
the NSEC3PARAM RR should be discouraged.

The sense-of-the-room was that this issue could be overcome with
careful engineering. It is important that the dynamic update client and
server know each others expectations and policies, these can be
communicated in-band using (currently unspecified) flag fields
in the NSEC3PARAM record.

The workshop recommends that the current NSEC3 document proceed without
addressing this any further and if the need arises for solving
issues in this space it addressed at later point by an update
to RFC2136 and NSEC3.

The chairs are inclined to follow the workshop's recommendation.
This observation is raised here to record what was observed and
the recommendation.
If you disagree with the recommendation please speak up now.

	Olafur & 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/>