DNSSEC auto-dnssec issue bind-9.7.2-P3

[Kalman Feher]

On 25/01/11 11:20 PM, "Mark Andrews" <marka at isc.org> wrote:

> 
> In message <C964B3CD.13A61%kalman.feher at melbourneit.com.au>, Kalman Feher
> write
> s:
>> 
>> 
>> 
>> On 25/01/11 4:10 PM, "Alan Clegg" <aclegg at isc.org> wrote:
>> 
>>> On 1/25/2011 9:51 AM, Kalman Feher wrote:
>>> 
>>>> If the nsec3param has been removed, the automated signing will be weird if
>>>> you are using nsec3 keys. I havent tested this scenario, since it isnt
>>>> really a working scenario.
>>> 
>>> There is no such thing as an "nsec3 key".
>> Sorry, I was a little sloppy with my vernacular.
>> I meant the algorithm used to create the keys in question. ie using -3 in
>> dnssec-keygen. 
> 
> And *all* keys that support NSEC3 are also NSEC capable.  There
> isn't such a thing as a NSEC3 key.  There are NSEC3 capable keys
> and keys that are not NSEC3 capable.  All keys are NSEC capable.
I don't think this was in question. But it is always useful to have it
explicitly stated. Though hopefully this wont muddy the waters, since it is
the complete opposite of what OP was trying to do.


> 
> As for the NSEC3PARAM going away it is only supposed to exist in a
> *signed* zone and you are attempting to add it to a unsigned zone.
Good point. However I note that it definitely _does_ work when added to an
unsigned zone, which following an rndc sign, (with caveats of appropriately
created keys ) will result in an nsec3 signed zone. This is also the
workflow documented in Alan's nanog presentation (the slide titled "Create &
Sign (NSEC3)"). 

If that isn't ideal, it would be useful to know why. And also why it does
work for now. Does it only work when done in rapid succession?

> 
> The key timing are there for managing keys in a already signed zone.
> You are attempting to use them to start signing the zone which
> requires as whole different set of steps to be done.
> 
> To get named to convert a unsigned zone to a signed zone with NSEC3
> use nsupdate to add the DNSKEYs and NSEC3PARAM record in the same
> UPDATE request.

> 
>>> If you auto-sign a zone that does not contain an NSEC3PARAM record, the
>>> zone will be signed using NSEC.
>> That was the observed behaviour of the OP, which wasn't their preference.
>> Hence the need to add and retain said nsec3param in this instance.
>> 
>>> 
>>> [note that I'm leaving the rest of that mail to be responded to by
>>> someone with more intimate knowledge of the auto-signing mechanism]
I believe this was the original issue with OP. There seemed to be a
misunderstanding of the purpose of the activate value. Specifically,
expecting that the zone would automatically sign updates (the DS in this
case) prior to the activate time.
>>> 
>>> AlanC
>>> 
>>> _______________________________________________
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>> 
>> -- 
>> Kal Feher 
>> 
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher