Subject: Re: NSEC3 Issue 13: DDNS and Opt-In Determination

From: Sam Weiler <[email-masked]>
Date: Fri, 17 Mar 2006 17:06:36 -0500 (EST)

On Tue, 21 Feb 2006, Geoffrey Sisson wrote:

> Issue:
>
> When a DDNS client sends an UPDATE transaction containing RRs for a new
> unsigned delegation to be inserted into an NSEC3 zone, there is no
> obvious way for the server to determine whether or not the new
> delegation should be included in the NSEC3 chain.
...
> Resolution:
>
> None.  We are still investigating the problem space.

I suggest not resolving this at this time (and, in particular, in this 
document).

Assuming that we retain opt-in at all (why isn't there an open issue 
about that?), I imagine that zones will have different policies for 
which names to include in the NSEC3 chain v. not, and I see no 
compelling case for setting a default.  If we need some DDNS 
extensions to handle NSEC3, we can handle that separately.

-- Sam

--
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: Ben Laurie <[email-masked]>
Date: Sat, 18 Mar 2006 10:26:40 +0000

Sam Weiler wrote:
> about that?),

Because we do not believe it is an open issue.

> I imagine that zones will have different policies for
> compelling case for setting a default.  If we need some DDNS extensions
> to handle NSEC3, we can handle that separately.

I agree.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Sam Weiler <[email-masked]>
Date: Mon, 20 Mar 2006 20:22:22 -0500 (EST)

On Sat, 18 Mar 2006, Ben Laurie wrote:

>> (why isn't there an open issue about [opt-in]?),
>

I don't recall DNSEXT reaching a happy consensus about it.  Am I just 
being forgetful?

-- Sam

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 20 Mar 2006 19:32:24 -0600

On Mar 20, 2006, at 7:22 PM, Sam Weiler wrote:

> I don't recall DNSEXT reaching a happy consensus about it.  Am I  
> just being forgetful?

If nobody has issues its no issue.

As long its no issue, happy consensus will be declared after WGLC, if  
it is an issue we have to consent before.

So if this is an issue for you then please motivate why; provide your  
arguments why it should not be there.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 21 Mar 2006 07:48:55 -0600

On Mar 17, 2006, at 4:06 PM, Sam Weiler wrote:

> I suggest not resolving this at this time (and, in particular, in  
> this document).
>
> Assuming that we retain opt-in at all (why isn't there an open  
> issue about that?), I imagine that zones will have different  
> policies for which names to include in the NSEC3 chain v. not, and  
> I see no compelling case for setting a default.  If we need some  
> DDNS extensions to handle NSEC3, we can handle that separately.
>
>

The opt-in spec has specific language on how to deal with (not being  
able to do) dynamic updates in section 4.1.4. I propose that you  
would add some similar text to the nsec3 doc.

Related. The document updates reference [6] (dynamic update) but does  
not refer to it other than in the introduction.

no hats,

--Olaf

---

From: David Blacka <[email-masked]>
Date: Tue, 21 Mar 2006 22:00:37 -0600

On Mar 21, 2006, at 7:48 AM, Olaf M. Kolkman wrote:

> The opt-in spec has specific language on how to deal with (not  
> being able to do) dynamic updates in section 4.1.4. I propose that  
> you would add some similar text to the nsec3 doc.

Just to be clear, the opt-in spec disallows dynamic update not  
because you cannot get dynamic update to work with opt-in, but  
because it required further specification and no one stepped up to  
produce that specification.

Taking a similar route with NSEC3 seems reasonable to me.  While I  
believe that defining how dynamic update works with NSEC3 is a doable  
task, I also think it isn't necessary to solve it before finishing  
the main work with NSEC3.

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