Non-disruptive migration to dnssec-policy possible?

[Håkan Lindqvist]

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