Non-disruptive migration to dnssec-policy possible?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Non-disruptive migration to dnssec-policy possible?

Bind-Users forum mailing list
Hello,

I have seen essentially this same question/problem posed by others in
other forums but never seen any proper answers to it.
I have now tried this myself with BIND 9.16.1 and faced the exact same
issue that I had previously read about.

How does one migrate an already signed zone from "auto-dnssec maintain"
to "dnssec-policy x" in a non-disruptive manner?

The manual
(https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/Bv9ARM.ch05.html#dnssec_policy_grammar)
does not appear to cover this this scenario and the DNSSEC Guide
(https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html) does not
mention dnssec-policy at all.

However, the wiki
(https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-Policy-(KASP)#key-generation)
appears to suggest that existing keys would be picked up.

With that in mind, one might naively think that switching to a
keytype-compatible dnssec-policy should be safe, but in practice it
appears to be anything but.

Eg existing KSK+ZSK algo 13 keys seem like they could (and arguably
should) be carried over to a policy mandating KSK+ZSK and algo 13
(particularly if the policy has unlimited lifetime for the key, but even
with limited lifetime one would hope that the regular rollover timers
would be applied).

In practice when you change the zone configuration to use dnssec-policy,
all existing keys are immediately yanked and replaced with new keys. No
timers or anything seem to matter.


This is what my own test looked like:

Existing  KSK+ZSK keys with only these timings present in the .key files:

Created:
Publish:
Activate:

And a policy like this (named to reflect what is what while testing):

dnssec-policy alg13-ksk-unlimited-zsk-60day {
     keys {
         ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
         zsk key-directory lifetime P60D algorithm ECDSAP256SHA256;
     };
};

And this is the log output when first loading BIND after changing the
configuration to use that dnssec-policy:

zone zone.example/IN (signed): reconfiguring zone keys
keymgr: DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) created for
policy alg13-ksk-unlimited-zsk-60day
keymgr: DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) created for
policy alg13-ksk-unlimited-zsk-60day
Removing expired key 20481/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/20481 (ZSK) is now deleted
Removing expired key 12506/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/12506 (KSK) is now deleted
Fetching zone.example/ECDSAP256SHA256/49004 (KSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now active
Fetching zone.example/ECDSAP256SHA256/54646 (ZSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now active
zone zone.example/IN (signed): next key event: 22-Mar-2020 15:08:19.805

As can be seen, it immediately deleted the existing keys, claiming that
they were "expired".

One could argue that the ZSK certainly was old enough to be expired
(even though I would still maintain that it must do a proper rollover
starting from now rather than just yanking the key), but the KSK policy
was "lifetime unlimited" and nothing about end of life in the existing
.key file. How can such a key even be "expired"?

I did notice that the key files (both old and new) also got a
corresponding .state file created as part of this process. Is that
relevant to the problem?
Ie, do existing keys need this file to be used properly, if so is there
tooling to generate these?

Any suggestions?


Regards,
Håkan Lindqvist


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

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

Existing keys do not have a .state file, and so named will try to match
those keys with the policy by looking at the data in the .key and
.private files. However, perhaps some metadata is different? If so the
keys don't match the policy and named will try to replace them (I
suspect the DNSKEY TTL is different).

You can use the dnssec-settime tool to write the state file, but it is
more intended to be a method for debugging and testing.

It is odd that it immediately deletes the existing keys. I would like to
follow-up on this. Would you be able to rerun the experiment with the
dnssec log category set to debug? That way we can see what the internal
keymgr decided about those keys.

If so, could you create an issue for it on our GitLab repository?

    https://gitlab.isc.org/isc-projects/bind9/

There exists a system test that tests this case and it passes, so either
or test is wrong, or your setup uncovers a scenario we did not anticipate.

Thanks for reporting, best regards,

Matthijs

On 3/25/20 12:53 PM, Håkan Lindqvist via bind-users wrote:

> Hello,
>
> I have seen essentially this same question/problem posed by others in
> other forums but never seen any proper answers to it.
> I have now tried this myself with BIND 9.16.1 and faced the exact same
> issue that I had previously read about.
>
> How does one migrate an already signed zone from "auto-dnssec maintain"
> to "dnssec-policy x" in a non-disruptive manner?
>
> The manual
> (https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/Bv9ARM.ch05.html#dnssec_policy_grammar)
> does not appear to cover this this scenario and the DNSSEC Guide
> (https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html) does not
> mention dnssec-policy at all.
>
> However, the wiki
> (https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-Policy-(KASP)#key-generation)
> appears to suggest that existing keys would be picked up.
>
> With that in mind, one might naively think that switching to a
> keytype-compatible dnssec-policy should be safe, but in practice it
> appears to be anything but.
>
> Eg existing KSK+ZSK algo 13 keys seem like they could (and arguably
> should) be carried over to a policy mandating KSK+ZSK and algo 13
> (particularly if the policy has unlimited lifetime for the key, but even
> with limited lifetime one would hope that the regular rollover timers
> would be applied).
>
> In practice when you change the zone configuration to use dnssec-policy,
> all existing keys are immediately yanked and replaced with new keys. No
> timers or anything seem to matter.
>
>
> This is what my own test looked like:
>
> Existing  KSK+ZSK keys with only these timings present in the .key files:
>
> Created:
> Publish:
> Activate:
>
> And a policy like this (named to reflect what is what while testing):
>
> dnssec-policy alg13-ksk-unlimited-zsk-60day {
>     keys {
>         ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
>         zsk key-directory lifetime P60D algorithm ECDSAP256SHA256;
>     };
> };
>
> And this is the log output when first loading BIND after changing the
> configuration to use that dnssec-policy:
>
> zone zone.example/IN (signed): reconfiguring zone keys
> keymgr: DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) created for
> policy alg13-ksk-unlimited-zsk-60day
> keymgr: DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) created for
> policy alg13-ksk-unlimited-zsk-60day
> Removing expired key 20481/ECDSAP256SHA256 from DNSKEY RRset.
> DNSKEY zone.example/ECDSAP256SHA256/20481 (ZSK) is now deleted
> Removing expired key 12506/ECDSAP256SHA256 from DNSKEY RRset.
> DNSKEY zone.example/ECDSAP256SHA256/12506 (KSK) is now deleted
> Fetching zone.example/ECDSAP256SHA256/49004 (KSK) from key repository.
> DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now published
> DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now active
> Fetching zone.example/ECDSAP256SHA256/54646 (ZSK) from key repository.
> DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now published
> DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now active
> zone zone.example/IN (signed): next key event: 22-Mar-2020 15:08:19.805
>
> As can be seen, it immediately deleted the existing keys, claiming that
> they were "expired".
>
> One could argue that the ZSK certainly was old enough to be expired
> (even though I would still maintain that it must do a proper rollover
> starting from now rather than just yanking the key), but the KSK policy
> was "lifetime unlimited" and nothing about end of life in the existing
> .key file. How can such a key even be "expired"?
>
> I did notice that the key files (both old and new) also got a
> corresponding .state file created as part of this process. Is that
> relevant to the problem?
> Ie, do existing keys need this file to be used properly, if so is there
> tooling to generate these?
>
> Any suggestions?
>
>
> Regards,
> Håkan Lindqvist
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

Bind-Users forum mailing list
On 2020-03-25 14:03, Matthijs Mekking wrote:
> Existing keys do not have a .state file, and so named will try to match
> those keys with the policy by looking at the data in the .key and
> .private files. However, perhaps some metadata is different? If so the
> keys don't match the policy and named will try to replace them (I
> suspect the DNSKEY TTL is different).

Looking at the .key files, I can confirm that the old files (created by
dnssec-keygen) omit the TTL field, while the new .key files have a 3600
TTL specified.

I suppose that the dnssec-keygen output depends on whether the -L option
was used or not (based on this, I would guess that it's quite common to
have .key files with no TTL in the wild).


> You can use the dnssec-settime tool to write the state file, but it is
> more intended to be a method for debugging and testing.

Ok. No, I don't particularly want the .state files, it was just a
question of whether they were expected/needed ahead of time.


> It is odd that it immediately deletes the existing keys. I would like to
> follow-up on this. Would you be able to rerun the experiment with the
> dnssec log category set to debug? That way we can see what the internal
> keymgr decided about those keys.
>
> If so, could you create an issue for it on our GitLab repository?
>
>      https://gitlab.isc.org/isc-projects/bind9/

Ok, I will try this and report back. (Also whether adding a TTL to the
.key file avoids the problem)


/Håkan


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

Shumon Huque
In reply to this post by Matthijs Mekking
On Wed, Mar 25, 2020 at 9:04 AM Matthijs Mekking <[hidden email]> 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.


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

Matthijs Mekking
Hi Shumon,

The "NOT IMPLEMENTED YET" is still accurate. It means that if you use
dnssec-policy, your zones will be signed with NSEC. Any attempts to make
it work with NSEC3 (with Dynamic Update for example) have undefined
behavior.

You are right that at this moment dnssec-policy is not yet suitable for
your use case. We will implement NSEC3 for dnssec-policy in 9.17 and
backport it to 9.16.

Best regards,

Matthijs

On 3/25/20 8:50 PM, Shumon Huque wrote:

> On Wed, Mar 25, 2020 at 9:04 AM Matthijs Mekking <[hidden email]
> <mailto:[hidden email]>> 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.
>

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

Shumon Huque
Thanks for the information Matthijs.

We were actually looking forward to this particular feature in 9.16.x for easier key rolls. So, if you have any idea yet about the timeframe to develop and backport the NSEC3 support to 9.16, let us know.

Thanks!
Shumon.

On Wed, Mar 25, 2020 at 4:09 PM Matthijs Mekking <[hidden email]> wrote:
Hi Shumon,

The "NOT IMPLEMENTED YET" is still accurate. It means that if you use
dnssec-policy, your zones will be signed with NSEC. Any attempts to make
it work with NSEC3 (with Dynamic Update for example) have undefined
behavior.

You are right that at this moment dnssec-policy is not yet suitable for
your use case. We will implement NSEC3 for dnssec-policy in 9.17 and
backport it to 9.16.

Best regards,

Matthijs

On 3/25/20 8:50 PM, Shumon Huque wrote:
> On Wed, Mar 25, 2020 at 9:04 AM Matthijs Mekking <[hidden email]
> <mailto:[hidden email]>> 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.
>


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

Bind-Users forum mailing list
In reply to this post by Bind-Users forum mailing list
I reported a bug with the requested details:
https://gitlab.isc.org/isc-projects/bind9/issues/1706


A related thing that I've noticed in my tests is that "dnssec-policy x"
seems to also imply "inline-signing yes"?
Is this intended as a strict requirement, it seems a little awkward?

On that note, combining "dnssec-policy x" with "inline-signing no" does
not seem to be handled gracefully.
This makes me suspect that it's not an intended scenario, is that correct?


/Håkan

On 2020-03-25 16:57, Håkan Lindqvist via bind-users wrote:

> On 2020-03-25 14:03, Matthijs Mekking wrote:
>> Existing keys do not have a .state file, and so named will try to match
>> those keys with the policy by looking at the data in the .key and
>> .private files. However, perhaps some metadata is different? If so the
>> keys don't match the policy and named will try to replace them (I
>> suspect the DNSKEY TTL is different).
>
> Looking at the .key files, I can confirm that the old files (created
> by dnssec-keygen) omit the TTL field, while the new .key files have a
> 3600 TTL specified.
>
> I suppose that the dnssec-keygen output depends on whether the -L
> option was used or not (based on this, I would guess that it's quite
> common to have .key files with no TTL in the wild).
>
>
>> You can use the dnssec-settime tool to write the state file, but it is
>> more intended to be a method for debugging and testing.
>
> Ok. No, I don't particularly want the .state files, it was just a
> question of whether they were expected/needed ahead of time.
>
>
>> It is odd that it immediately deletes the existing keys. I would like to
>> follow-up on this. Would you be able to rerun the experiment with the
>> dnssec log category set to debug? That way we can see what the internal
>> keymgr decided about those keys.
>>
>> If so, could you create an issue for it on our GitLab repository?
>>
>>      https://gitlab.isc.org/isc-projects/bind9/
>
> Ok, I will try this and report back. (Also whether adding a TTL to the
> .key file avoids the problem)
>
>
> /Håkan
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

Shumon Huque
On Thu, Mar 26, 2020 at 3:35 PM Håkan Lindqvist via bind-users <[hidden email]> wrote:

A related thing that I've noticed in my tests is that "dnssec-policy x"
seems to also imply "inline-signing yes"?
Is this intended as a strict requirement, it seems a little awkward?

I'm sure ISC colleagues will elucidate more, but it sounds to me like a new interpretation. of "inline-signing", i.e. the dnssec-policy feature takes an unsigned local zone file as input, and generates and maintains a new signed file ("origfile.signed"). UPDATEs continue to go to the orig file and ("inline?") signed deltas go into the signed file (well journal first and synced later). It would probably be helpful to have the mechanics of this new feature written up in detail somewhere so that operators know what is actually going on.

Shumon Huque



_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

Mark Andrews
dnssec-policy should be independent of inline-signing.  If it isn’t then it is a bug.

It just people like editing master files rather than using nsupdate to make changes.

> On 27 Mar 2020, at 08:02, Shumon Huque <[hidden email]> wrote:
>
> On Thu, Mar 26, 2020 at 3:35 PM Håkan Lindqvist via bind-users <[hidden email]> wrote:
>
> A related thing that I've noticed in my tests is that "dnssec-policy x"
> seems to also imply "inline-signing yes"?
> Is this intended as a strict requirement, it seems a little awkward?
>
> I'm sure ISC colleagues will elucidate more, but it sounds to me like a new interpretation. of "inline-signing", i.e. the dnssec-policy feature takes an unsigned local zone file as input, and generates and maintains a new signed file ("origfile.signed"). UPDATEs continue to go to the orig file and ("inline?") signed deltas go into the signed file (well journal first and synced later). It would probably be helpful to have the mechanics of this new feature written up in detail somewhere so that operators know what is actually going on.
>
> Shumon Huque
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

Bind-Users forum mailing list
On 2020-03-26 23:00, Mark Andrews wrote:
> dnssec-policy should be independent of inline-signing.  If it isn’t then it is a bug.
>
> It just people like editing master files rather than using nsupdate to make changes.

Ok, thank you for clarifying what should be expected.

I guess that leaves the question of whether I am reading too much into
the new behavior.

In addition to my DNSKEY issues, I do get two new files when switching a
zone to dnssec-policy: .signed + .signed.jnl.
To me this seems like the result of inline signing having been enabled,
but maybe this could happen for some other reason?


As for "inline-signing no;" not working, that actually appears to cause
an error regardless of dnssec-policy, so that may be a blemish that is
irrelevant to the overall question.

Anyway, that just leads to:

parser.c:2836: REQUIRE(obj != ((void *)0) && *obj == ((void *)0))
failed, back trace
#0 0x55ec613030a3 in ??
#1 0x7f598d6eda90 in ??
#2 0x7f598d77d9ba in ??
#3 0x55ec6130a23c in ??
#4 0x55ec6130f398 in ??
#5 0x55ec61323adc in ??
#6 0x55ec61324b2e in ??
#7 0x7f598d714e51 in ??
#8 0x7f598d1c2669 in ??
#9 0x7f598d0e4323 in ??
exiting (due to assertion failure)


/Håkan

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

Shumon Huque
On Thu, Mar 26, 2020 at 7:27 PM Håkan Lindqvist via bind-users <[hidden email]> wrote:
On 2020-03-26 23:00, Mark Andrews wrote:
> dnssec-policy should be independent of inline-signing.  If it isn’t then it is a bug.
>
> It just people like editing master files rather than using nsupdate to make changes.

Ok, thank you for clarifying what should be expected.

I guess that leaves the question of whether I am reading too much into
the new behavior.

In addition to my DNSKEY issues, I do get two new files when switching a
zone to dnssec-policy: .signed + .signed.jnl.
To me this seems like the result of inline signing having been enabled,
but maybe this could happen for some other reason?

I suspect dnssec-policy is re-using a lot of the code that did inline signing, only applying it to local unsigned zone file rather than one that was fetched from a remote master via zone transfer (hence my last note about a new interpretation of the term).

In fact, "rndc zonestatus" reports the same for a very simple dnssec-policy test on a local zone I did:

$ rndc zonestatus foo.test
name: foo.test
type: master
files: zones/foo.test/zonefile
serial: 1000000251
signed serial: 1000000257
nodes: 5
last loaded: Wed, 25 Mar 2020 17:52:09 GMT
secure: yes
inline signing: yes
^^^^^^^^^^^^^^^^^
key maintenance: automatic
next key event: Sat, 28 Mar 2020 20:45:44 GMT
next resign node: foo.test/NS
next resign time: Sat, 28 Mar 2020 08:40:06 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no

Shumon Huque


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

Bind-Users forum mailing list
On 2020-03-27 00:34, Shumon Huque wrote:

In fact, "rndc zonestatus" reports the same for a very simple dnssec-policy test on a local zone I did:

$ rndc zonestatus foo.test
name: foo.test
type: master
files: zones/foo.test/zonefile
serial: 1000000251
signed serial: 1000000257
nodes: 5
last loaded: Wed, 25 Mar 2020 17:52:09 GMT
secure: yes
inline signing: yes
^^^^^^^^^^^^^^^^^


Thank you for pointing this out, I did not think of that rndc zonestatus also reflects thisthis.

For reference, I reported this behavior as a bug: https://gitlab.isc.org/isc-projects/bind9/-/issues/1709


/Håkan


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Non-disruptive migration to dnssec-policy possible?

Matthijs Mekking
In reply to this post by Bind-Users forum mailing list
To follow-up,

Migration from existing keys to dnssec-policy was indeed not working
properly, because the internal key states were not initialized properly.
Key states were always initialized as "HIDDEN" and that is why the
keymgr thought it could delete those keys immediately.

The fix is to look more closely at key timing metadata and set the
internal key state appropriately.

This is fixed in the upcoming 9.16.2 release.

Best regards,

Matthijs

On 3/26/20 8:34 PM, Håkan Lindqvist wrote:

> I reported a bug with the requested details:
> https://gitlab.isc.org/isc-projects/bind9/issues/1706
>
>
> A related thing that I've noticed in my tests is that "dnssec-policy x"
> seems to also imply "inline-signing yes"?
> Is this intended as a strict requirement, it seems a little awkward?
>
> On that note, combining "dnssec-policy x" with "inline-signing no" does
> not seem to be handled gracefully.
> This makes me suspect that it's not an intended scenario, is that correct?
>
>
> /Håkan
>
> On 2020-03-25 16:57, Håkan Lindqvist via bind-users wrote:
>> On 2020-03-25 14:03, Matthijs Mekking wrote:
>>> Existing keys do not have a .state file, and so named will try to match
>>> those keys with the policy by looking at the data in the .key and
>>> .private files. However, perhaps some metadata is different? If so the
>>> keys don't match the policy and named will try to replace them (I
>>> suspect the DNSKEY TTL is different).
>>
>> Looking at the .key files, I can confirm that the old files (created
>> by dnssec-keygen) omit the TTL field, while the new .key files have a
>> 3600 TTL specified.
>>
>> I suppose that the dnssec-keygen output depends on whether the -L
>> option was used or not (based on this, I would guess that it's quite
>> common to have .key files with no TTL in the wild).
>>
>>
>>> You can use the dnssec-settime tool to write the state file, but it is
>>> more intended to be a method for debugging and testing.
>>
>> Ok. No, I don't particularly want the .state files, it was just a
>> question of whether they were expected/needed ahead of time.
>>
>>
>>> It is odd that it immediately deletes the existing keys. I would like to
>>> follow-up on this. Would you be able to rerun the experiment with the
>>> dnssec log category set to debug? That way we can see what the internal
>>> keymgr decided about those keys.
>>>
>>> If so, could you create an issue for it on our GitLab repository?
>>>
>>>      https://gitlab.isc.org/isc-projects/bind9/
>>
>> Ok, I will try this and report back. (Also whether adding a TTL to the
>> .key file avoids the problem)
>>
>>
>> /Håkan
>>
>>
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> [hidden email]
>> https://lists.isc.org/mailman/listinfo/bind-users

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (499 bytes) Download Attachment