Why does a dnssec signed zone fail to reload

binddns-zonednssec

FreeBSD-12
BIND-9.11

After some effort I have changed the error. Now I see this:

07-Jun-2019 18:01:25.299 zone parschecks/IN/public (unsigned): loaded serial 2019070701 (DNSSEC signed)
07-Jun-2019 18:01:25.299 dns_master_load: file format mismatch (not raw)
07-Jun-2019 18:01:25.299 zone parschecks.ca/IN/public (signed): loading from master file /usr/local/etc/namedb/master/parschecks.ca.hosts.signed failed: not implemented
07-Jun-2019 18:01:25.299 zone parschecks/IN/public (signed): not loaded due to errors.

Original question:

I have this domain which reports that its key has expired when I reload named: 

Jun  7 15:32:24 dns38 named[19583]: /usr/local/etc/namedb/master/parschecks.ca.hosts:53: signature has expired
Jun  7 15:32:25 dns38 named[19583]: zone parschecks.ca/IN/public (signed): receive_secure_serial: unchanged

However I have manually signed this domain:

2019-06-07 15:26:34: dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE parschecks.ca
2019-06-07 15:26:50: dnssec-keygen -a ECDSAP256SHA256 -n ZONE parschecks.ca
2019-06-07 15:27:05: dnssec-signzone -N increment -S -o parschecks.ca parschecks.ca.hosts Kparschecks.ca.+013+37572

And the hosts files seem to have been updated:

-rw-r--r--  1 bind  bind     609 Mar 12 12:59 Kparschecks.ca.+008+29077.key
-rw-------  1 bind  bind    1776 Mar 12 12:59 Kparschecks.ca.+008+29077.private
-rw-r--r--  1 bind  bind     479 Mar 12 12:59 Kparschecks.ca.+008+32223.key
-rw-------  1 bind  bind    1200 Mar 12 12:59 Kparschecks.ca.+008+32223.private
-rw-r--r--  1 bind  bind     479 Feb 19 21:17 Kparschecks.ca.+008+43116.key
-rw-------  1 bind  bind    1200 Feb 19 21:17 Kparschecks.ca.+008+43116.private
-rw-r--r--  1 bind  bind     346 Jun  7 15:24 Kparschecks.ca.+013+35858.key
-rw-------  1 bind  bind     187 Jun  7 15:24 Kparschecks.ca.+013+35858.private
-rw-r--r--  1 bind  bind     346 Jun  7 15:26 Kparschecks.ca.+013+37572.key
-rw-------  1 bind  bind     187 Jun  7 15:26 Kparschecks.ca.+013+37572.private
-rw-r--r--  1 bind  bind     345 Jun  7 15:26 Kparschecks.ca.+013+50724.key
-rw-------  1 bind  bind     187 Jun  7 15:26 Kparschecks.ca.+013+50724.private
-rw-r--r--  1 bind  bind     344 Jun  7 15:27 dsset-parschecks.ca.
-rw-r--r--  1 bind  bind    9515 Apr 18 12:03 parschecks.ca.hosts
-rw-r--r--  1 bind  bind     512 Mar 22 17:28 parschecks.ca.hosts.jbk
-rw-r--r--  1 bind  bind    2395 Apr 18 12:28 parschecks.ca.hosts.jnl
-rw-r--r--  1 bind  bind   15960 Jun  7 15:32 parschecks.ca.hosts.signed
-rw-r--r--  1 bind  bind  128161 Jun  7 15:43 parschecks.ca.hosts.signed.jnl

named.conf contains this:

zone "parschecks.ca" {
type master;
file "/usr/local/etc/namedb/master/parschecks.ca.hosts";
key-directory "/usr/local/etc/namedb/master/";
auto-dnssec maintain;
inline-signing yes;
};

We are in the process of moving to inline signing but we have not managed to get it working as yet. If we remove the auto maintain clauses from the zone entry in named.conf the zone file is still reported as being expired.

rndc -s 127.0.0.1 reload parschecks.ca
zone reload up-to-date

Nothing has been changed in the hosts file. But it will not load after resigning. What step am I missing?

Best Answer

The combination of configuring named to handle the signing process for you (auto-dnssec maintain), with it working from a manually managed zone file (supposedly unsigned) as input (inline-signing yes) but then also manually signing the zone (by invoking dnssec-signzone) is not something that is expected to work and more than likely explains how things got messy.

As for how to clean the mess up (I expect this will be required regardless which direction you decide to go), I would suggest just starting over from an unsigned version of the zone file (clean it up by hand if need be, although it sounds like parschecks.ca.hosts should be unsigned).
I say this because now you have all these auto-generated files (journal file for the zone file itself, auto-signed zone with journal) containing data that may not match your intentions and with the journal files there is the issue that the journal may be out of sync with the corresponding zone file. (It sounds like you have overwritten the auto-generated signed file, as named was complaining that this file was not in the expected format for an inline-signing setup, and then that journal file is probably out of sync as well).
I also see a remarkable number of key files in that directory, but without seeing the key metadata it's hard to say if that will cause a problem (may be prudent to clean that up as well).

Anyway, of course back everything up first, but then the cleanup process would probably consist of deleting everything but the unsigned zone file + the key files actually in use and start from a clean slate with named configured for the signing mode that you actually intend to use (you need to decide).

Overall, I would suggest to just avoid dnssec-signzone entirely as it's rather outdated and inconvenient (you have an extra step when making changes, but also a recurring time-based extra step to refresh signatures whether you make any changes or not and need to handle that somehow).
The automated signing process in BIND has been around for ages (at least closing in on 10 years), so it doesn't really make sense to me to consider dnssec-signzone when you don't even have a working setup based on that as the starting point (unless of course you are intimately familiar with that setup and would need to prepare more before switching).
For how to set up automated signing, see the BIND DNSSEC Guide.

Related Topic