Non-disruptive migration to dnssec-policy possible?

[Håkan Lindqvist]

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
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users