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

[Tony Finch]

raf via bind-users <bind-users at lists.isc.org> wrote:
>
> 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.

A tangential point, but I think this kind of setup (with lots of empty
zones) isn't necessary, if you are doing DNSSEC validation and you turn on
synth-from-dnssec - much less configuration clutter.

> Can you sign 127.in-addr.arpa and 168.192.in-addr.arpa?

You can: it's harmless but pointless and wasteful.

> 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 makes sense to configure dnssec-policy in one place if you have an
authoritative-only primary server, which is configured with just the zones
that it is signing. (The extra zones in the Debian config are only
suitable for a recursive server.)

> 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.

Yes, this is a relatively common gotcha. You can avoid overwritten zone
files by turning on inline-signing mode, so that your source zone files
are separate from the signed zone files maintained by named. If your
configuration uses dynamic updates or DNSSEC then the zone files are
normally owned by named and will be rewritten, and you are right that
there isn't much warning of this in the documentation.

> But the real problem is that bind crashed, and dumped core, and couldn't
> start at all.

There should be something in the logs to indicate why this might have
happened; failing that a stack trace from the core dump would have been
helpful.

> 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?

No, I'm afraid it's more complicated than that.

You can do what you suggest if the server uses inline-signing mode. If
not, your process will go wrong horribly: you need to use `rndc freeze`
and `rndc thaw` if you are manually editing a zone file that is owned by
named, BUT if you do that with a signed zone, you will lose all the
signatures and it will have to be re-signed from scratch. Not good.

Another alternative is to enable `update-policy local`, and use nsdiff and
nsupdate to make the live zone match your source files.
http://dotat.at/prog/nsdiff/

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  https://dotat.at/
North Fitzroy, Sole: Westerly or northwesterly 4 to 6 veering
northerly or northwesterly 3 to 5. Rough becoming moderate. Showers
then fair. Good, occasionally moderate.