Primary zone not fully maintained by BIND

[Sandro]

On 23-05-2022 15:48, Tony Finch wrote:

> The place I would look first is the log messages from `named`: is it
> complaining about anything?

Plenty of:

zone penguinpee.nl/IN/external: reconfiguring zone keys
zone penguinpee.nl/IN/external: next key event: 22-May-2022 01:00:01.961

When the log files rolled over at 00:00 on 22 May, named.log just reported:

22-May-2022 00:00:07.093 general: info: reloading configuration succeeded
22-May-2022 00:00:07.272 general: info: reloading zones succeeded
22-May-2022 00:00:07.402 general: notice: all zones loaded
22-May-2022 00:00:07.402 general: notice: running

> One of the things I have to take care with (because I have got it wrong
> several times!) is filesystem permissions: can `named` read the .private
> keys? can it read and write to the zone files? can it read and write to
> the directories containing the keys and the zone files?

Yeah, that's all fine. All keys for internal and external, forward and 
reverse zones are stored in the same directory with rw access for named. 
On the internal zone, the records look just fine:

RRSIG   CNAME 13 3 259200 (
                 20220605095654 20220522085940 56132 penguinpee.nl.
                 Geyl5Rz6Kqwfp5JUf09A1NB3fRU6EhdszCihduKlJat7
                 W8780MyS2awJjI+xDi9zG9fkO8yQx48hGeDDFxc3dA== )

The reverse zone in the external view was up to date and named was able 
to re-sign the affected zone after the restart. So, permissions are 
good, I'd say.

I'll do some more digging through the log files. I meanwhile increased 
the severity to 'debug 3' for dnssec_debug.

-- Sandro