Primary zone not fully maintained by BIND

[Matthijs Mekking]

Sandro,

What version are you using? We had a bug with dnssec-policy and views 
(#2463), but that has been fixed.

Since 9.16.18 you should not be able to set the same key-directory for 
the same zone in different views.

Matthijs

On 23-05-2022 16:12, Sandro wrote:
> 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