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

Reply via email to