Non-disruptive migration to dnssec-policy possible?
matthijs at isc.org
Mon Apr 6 07:37:56 UTC 2020
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.
On 3/26/20 8:34 PM, Håkan Lindqvist wrote:
> I reported a bug with the requested details:
> 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?
> 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?
>> Ok, I will try this and report back. (Also whether adding a TTL to the
>> .key file avoids the problem)
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>> bind-users mailing list
>> bind-users at lists.isc.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the bind-users