broken trust chain
Josef Moellers
jmoellers at suse.de
Mon Sep 28 09:09:31 UTC 2020
Hello Tony,
Thanks for the reply!
On 25.09.20 21:55, Tony Finch wrote:
> Josef Moellers <jmoellers at suse.de> wrote:
>>
>> I just foudn out that in the good case, the key in /etc/bind.keys is
>> accepted, in the bad case it is not:
>> good:managed-keys-zone: Key 20326 for zone . acceptance timer complete:
>> key now trusted
>> bad:managed-keys-zone: No DNSKEY RRSIGs found for '.': success
>>
>> So the question is: what causes this?
>
> Sounds like you have a stale bind.keys file.
That can't be, as the test is done by restarting the installed named on
a VM, so the "/etc/bind.keys" as well as the managed-keys.bind and
managed-keys.bind.jnl files do not change between test runs.
> You don't need this file:
> `named` has a built-in copy which is up-to-date if you keep up with
> patching. You should be able to fix it by deleting bind.keys and the
> working files managed-keys.bind managed-keys.bind.jnl *.mkeys *.mkeys.jnl
My current solution is to ship an empty /etc/bind.keys (weeeeell ... not
really empty: I've put a comment inside to describe why it's otherwise
empty) and let named use its built-in trust anchors instead, which seems
to work fine.
But, as I wrote above, I still can't figure out why it fails to start
properly once in ~4 times even when the "/etc/bind.keys" file (and its
copy inside the chroot jail) stays the same.
What would make the bind.keys file stale?
Thanks again and ... stay healthy!
Josef
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
More information about the bind-workers
mailing list