Non-disruptive migration to dnssec-policy possible?

Shumon Huque shuque at gmail.com
Wed Mar 25 19:50:55 UTC 2020


On Wed, Mar 25, 2020 at 9:04 AM Matthijs Mekking <matthijs at isc.org> wrote:

> Hi Håkan,
>
> First of all, thanks for trying out the new dnssec-policy feature.
>
> I'll admit there is insufficient documentation and tooling around
> migration to dnssec-policy, possibly there is a bug too.
>
[...]

HI Matthijs,

We are just starting to look at 9.16.x also, and are considering what it
would take to move our current "auto-dnssec maintain" configuration to the
new dnssec-policy feature.

We use NSEC3 though, and from your wiki, I see the following:

" Currently if you want to sign your zone with NSEC3 you can do so by
introducing
an NSEC3PARAM record via Dynamic Update. This is no longer necessary with
dnssec-policy as you can configure NSEC3 usage in named.conf (NOT
IMPLEMENTED YET)."

Is the "NOT IMPLEMENTED YET" still accurate? And if accurate, can you
elaborate on what that means? e.g. NSEC3 zones don't work at all? NSEC3
zones can be generated and served, but NSEC3 parameters cannot be
managed/rolled? Or something else?

If the latter, I was wondering if it is possible to combine pieces of the
old and new ways, e.g. pre-configure an unsigned zone with an NSEC3 param
using dynamic update or "rndc signing -nsec3param", and also use
dnssec-policy to allow for maintenance of the DNSSEC keys? Our requirement
though is that the signed zone needs to be NSEC3 out of the gate. At first
glance, if I'm understanding the new configuration statements, that doesn't
seem possible.

Thanks!
Shumon Huque.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200325/aea7d16a/attachment.htm>


More information about the bind-users mailing list