[dns-operations] NSEC3

[Roy Arends]

On Jun 27, 2006, at 7:19 PM, Edward Lewis wrote:

> At 18:15 +0200 6/27/06, Roy Arends wrote:
>
>>>  The rationale was that a server has to do very different  
>>> processing for
>>> NSEC and NSEC3, so how would it choose the code path?
>>
>> non sequitur
>
> Not exactly.  If a server is capable of both, how does it choose to  
> answer with NSEC or with NSEC3.

Configure it as such, or fallback to NSEC if there is no NSEC3  
record, or maybe with a NSEC3-PARAM record at the apex, if it is  
decided that that is the best way for a server to determine the  
status of the zone. In any case, not a showstopper.

>   Besides the difference between plaintext and hashed names,  
> there's also a difference in what the records return.  For NSEC,  
> you demonstrate that the name is absent. For NSEC3 you demonstrate  
> that a closest encloser is present.
> Although I can think of ways for a server to decide, at the time of  
> the workshop (which was held before discussion about transition  
> issues) it hadn't been considered.
>
>> I'd like that implementer to step forward, if he/she actually exists.
>
> I don't see any need to be so antagonistic.

Well, since you said:

     That's not what I was led to believe at the workshop[1] in May.  I
     was told to switch between NSEC and NSEC3 I would need a completely
     different code base and would have to cut over all of my  
instances in
     a flash - not just zone data but name server software.  To me,  
that's
     a high cost.

and

     This was said by at least one implementer in the room, probably  
without considering how it could be done.

I was there at the workshop as well. If there is ANYONE who was at  
the workshop who either told you this, or who actually agrees with  
what you were led to believe, I'd like to hear him/her say that.  
Maybe I'm antagonistic, or maybe I'm tired of debunking NSEC3/opt-out  
horror stories. I understand that people have concerns. We can  
discuss those concerns. But it seems to me that when I hear you state  
this stuff about NSEC3, it reads like a negative conundrum.

What is important to me is that if there is anything we can do to  
improve NSEC3 in any way, shape or form, I'd like to hear about it.  
If NSEC3 is broken, I'd like to hear about it too. So far, it is just  
hearsay. And to me, repeating hearsay without any constructive aid,  
is planting fear, uncertainty and doubt.

> The workshop consisted of mostly implementers, code writers, and  
> the temper was mostly a desire to see of the code that had been  
> built did what it was expected to do.

In a sense that 'expected' is exactly the same as 'to behave as  
specified according to the draft', yes.

> When a collection of implementers gather to discuss issues,  
> generally the results are a recommendation to do what's easy to  
> implement.

Sure.

> From this, being able to do both NSEC and NSEC3 was seen as "code  
> bloat."

Again, this is absolutely new to me.

I can imagine you'd confuse that with: including both NSEC and NSEC3  
in a single response defies the sole purpose of NSEC3.

> The workshop didn't test operational considerations.  For one, the  
> test environment was wholly NSEC3, no NSEC at all.

Yes. It was an NSEC3 workshop, we kind of expected that NSEC works  
the way it should.

> Secondly, none of the NSEC3 parameters were changed within a zone  
> over the duration of the workshop, and the same parameters were  
> used for all zones that were NSEC3'd.  I'm not the first one to  
> bring this up, I'm repeating what others have said.

This doesn't mean anything. If it works for salt=AABBCC it works for  
salt=CCBBAA, if it works for iterations=12 , it works for  
iterations=16. We indeed haven't tested rolling from NSEC to NSEC3,  
traversing from NSEC3-NSEC-NSEC3 or rolling parameters. We only had  
three days and a lot of distraction. So we decided to have another  
workshop, probably somewhere in september, where the remaining issues  
are resolved/stuff is tested.

> I'm not against NSEC3.  I'm against jumping with both feet into a  
> pond before knowing how deep it is.

Don't jump then.

> I'm also against jumping into a pond before I know that it is what  
> I need to do, and what I want to do.

Understandable. I do the same.

Roy