debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes

[raf]

Hi,

I've just upgraded my bind9 server to debian-11 which
has bind-9.16.15. I've been looking forward to this. I
had my local dnssec-policy ("annual") all ready to go.
But it didn't go well at all.

For the first few seconds, I thought it was great. I
uncommented my new config to enable DNSSEC signing, and
the keys directory was full of new files, but there
were too many. There were key files for all of the
RFC1918 zones. I thought that can't be right.

I had put dnssec-policy "annual" in the options {}
stanza, so that it would apply to all zones. This is
suggested as a possibility in the DNSSEC guide and/or
the configuration reference.

But that means that it applies to all of the zones in
/etc/bind/named.conf.default-zones which is not
helpful. It also applies to the zones in
/etc/bind/zones.rfc1918 if that is included in
/etc/bind/named.conf.local (which a comment there
suggested). That's not helpful either. At least, I
can't see how. Can you sign 127.in-addr.arpa and
168.192.in-addr.arpa? Maybe this is a Debian package
issue. Maybe named.conf.default-zones isn't an
upstream thing. But it's good to be aware of when
writing the documentation.

I've come to the conclusion that putting dnssec-policy
in the options {} stanza, so that it applies to all
zones, is a terrible idea. It only makes sense (to me)
to add dnssec-policy to each individual (real)
authoritative zone {} stanza.

It would be great if the DNSSEC guide and the
configuration reference were updated to include a
warning about this.

But that was just a surprise, maybe wasteful, but
possibly harmless (although possibly not).

What I found more upsetting, was that my carefully
crafted, well documented zonefiles in /var/cache/bind
had been overwritten by bind so as to include the
DNSSEC records. It might seem obvious to anyone who
uses DNS updates that that was going to happen, but I
wasn't expecting it. It would be great if the DNSSEC
guide could be updated to mention that this happens,
and include advice to keep your zonefile sources
somewhere other than where bind looks for them.

I never received any indication when reading the
documentation about DNSSEC that this would happen. I
knew that bind would read in my zonefiles and construct
a signed version of it, but the documentation never
mentioned that that signed version would be written to
disk over my original source zonefiles. At least, I
never got that impression. Thank goodness for backups. :-)
I'll know for next time, and I'll restructure things,
but it would have been nice to be warned in advance
by the documentation.

But the real problem is that bind crashed, and dumped
core, and couldn't start at all. There were a hectic
few minutes there. :-) I deleted the coredump and the
key files, and the .jnl files, restored backup
zonefiles, updated the serials to be greater than that
of the new DNSSEC signed zones, and then bind was able
to start again.

Does anyone have any idea why bind-6.19.15 would have
crashed repeatedly? Here's the subset of the
config that I think could be relevant:

  options
  {
    allow-recursion { localhost; };
    dnssec-validation auto;
    directory "/var/cache/bind";
    key-directory "/var/cache/bind/keys";
    dnssec-policy "annual"; # I'm moving this away!
  };

  dnssec-policy "annual"
  {
    keys
    {
        ksk key-directory lifetime 366d algorithm ecdsap256sha256;
        zsk key-directory lifetime 61d algorithm ecdsap256sha256;
    };
    nsec3param iterations 5 optout no salt-length 16;
    publish-safety 7d;
    retire-safety 7d;
    purge-keys 90d;
    signatures-validity-dnskey 14d;
    signatures-validity 14d;
    signatures-refresh 7d;
    dnskey-ttl 1d;
    max-zone-ttl 1d;
    parent-ds-ttl 1d;
    zone-propagation-delay 300;
    parent-propagation-delay 1d;
  };

Might it just be because the RFC1918 zones were signed
and therefore invalid?

I'll try a more gradual approach on a separate test VM
and see how things go. But any advice would be greatly
appreciated. I want to be able to keep using whatever
version of bind9 is on debian stable. So workarounds
that don't involve an upgrade would be appreciated.

Hmm, on a separate VM just adding dnssec-policy "annual"
to one zone {} statement, and reloading, nothing happens.
I should come back to this tomorrow.

I have a new question about the process of updating
zonefiles when dnssec-policy is in use. From now on,
I'll have my zonefile sources somewhere other than
/var/cache/bind (e.g. /etc/bind/zone). When I make
changes, I'll install them to /var/cache/bind and
reload bind9. Bind9 will replace them with the signed
versions. Is it OK for me to modify my unsigned
sources, install them over the top of bind's signed
versions, and will bind happily recreate all of the
DNSSEC records each time? Is that what's expected? That
bind and I keep overwriting each other's zone files?

Thanks for your time, and apologies for the length of
this.

cheers,
raf