Subject: Re: NSEC3 and dynamic update issues.

From: Edward Lewis <[email-masked]>
Date: Wed, 1 Nov 2006 11:30:55 -0500

At 9:35 AM -0500 10/30/06, Ólafur Guðmundsson /DNSEXT co-chair wrote:

Okay, I'll bite...

>#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.

Perhaps this is true.  Then my consternation is 
focused on dynamic update's inadequacies or 
perhaps on that the implications of dynamic 
update haven't been fully addressed.

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

From this summary, I'm not convinced that 
NSEC3PARAM shouldn't be dynamically updated. 
Assuming that only after seeing an updated 
NSEC3PARAM will an authoritative server generate 
all of the new NSEC3 records, sure.  But what is 
lost on me is why a slaving server can not be 
pre-fed the records before the NSEC3PARAM 
"switches" them on?

>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.

Oh my Postel, "careful engineering?"  Is that a 
euphemism for "complicated operations?"  Or do we 
still need more engineering of the protocol to 
nail down the NSEC3PARAM record's semantics (and 
syntax too apparently, from another thread).

I had a soppy dramatic retelling of the delays in 
RFC 2065 and RFC 2535 that begat RFC 4034, 
et.al., but I don't think it is worth sending it. 
Just to say - we need to crest the hill of 
complexity in this protocol before it can stand a 
chance of working.  (Assuming that "careful 
engineering" refers to operations.)

>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.

Well, I won't put up a fight, but considering 
that if a registry has a large zone and the 
requirement to push changes out rapidly (less 
than 10 minutes say), dynamic update or 
modifications is an important part of the 
operation.  Even if the registry uses non-XFR 
zone replication, dynamic modifications are 
needed somewhere.

The proposed path runs the risk of completely 
defining (as in depth first) a protocol extension 
that does not work in all environments.  Perhaps 
that is acceptable, NSEC3 has been stated to be 
applicable to just some environments.

>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.

Keeping in mind: 
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00664.html:

"I suggest that unless Ed plans to actually 
deploy NSEC3 he should not be permitted to attach 
new requirements for advancement at this late 
stage in the process."

I am raising this just as a caution.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.

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