Home / server / Questions / 970610
In Process
James B. Byrne
Asked: 2019-06-08 12:05:55 +0800 CST

Why does a dnssec signed zone fail to reload

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

bind

2 Answers

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

    • 1

  2. The fix for my situation, insofar as getting dnssec-signzone to work, was:

    1. Ensure that the domain name in the SOA matches exactly the domain for which one is publishing the DNS zone for.

    2. Ensure that any .jnl and .jbk files for the zone are removed.

    3. Ensure that any .signed file for the zone is removed.

    4. Ensure that any embedded RRSIG records are removed from the master file.

    5. Ensure that the zone signing key (ZSK) used is properly signed by the key signing key (KSK) for that zone.

    6. Ensure that the DSKEY Resource Records in the zone match the hashes for the keys that you are going to use.

    7. Remove any other keys for the zone that may be present.

    8. Use dnssec-signzone using -S 'smart signing' option and the -o domain.name option when the master zone file does not have exactly the same name of the zone. Do not provide a specific key file. Do not use the -N option to override the default zone numbering scheme of 'increment'. (Unless you know a lot more about this subject than I do)

    9. Zones do NOT have to be dynamic when using inline signing. (ISC Inline Signing in ISC BIND 9.9.0 -- Examples

    A number of zone master files initially suffered from one or more of the defects corrected above, many of which then were made worse by efforts to diagnose the problem leaving artifacts in the zone masters directory. These zone files had worked fine with BIND-9.8 but evidently some conflicted with the expectations of 9.11. and inline-signing requirements.

    These defects were likely the reason that inline signing did not appear to work for some zones while it did for others. I could not find any any log entries which identified the type of error and named-checkconf -z did not identify any either. Running named in the foreground on a different port and loading the defective zones using the debug options provided hints on how to proceed but never pointed to a smoking gun record in the zone files.

    It remains to be seen if this has cured the problem with auto-maintain, inline-signing.

    • 1