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

  • What is line 53 of /usr/local/etc/namedb/master/parschecks.ca.hosts? Seems there is there a signature that expired, so it can be removed from the file probably. – Patrick Mevzek Jun 7 at 21:36

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.

  • The reason that I resorted to dnssec-signzone was specifically because inline signing was not working and the zone had expired. This setup is a recent transition from BIND-9.8 and the master zone files were transferred from there. I have discovered several defects in those files that did not impact 9.8 but which did 9.11, although without any error log entries. – James B. Byrne Jun 10 at 16:33
  • @JamesB.Byrne Ok, if the goal was to transition to manual signing, I suppose you would want to disable the auto-dnssec + inline-signing config options, remove any conflicting journal files, configure named to use the .signed file. – Håkan Lindqvist Jun 10 at 20:11

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.

  • Reading the last sentence, I was legitimately confused. You start out by writing about "getting dnssec-signzone to work" and, very much in line with that, a list of steps which includes invoking dnssec-signzone. So far, it all seems consistent for doing manual signing (ie, no auto-dnssec maintain + inline-signing yes), but then you end the answer with "It remains to be seen if this has cured the problem with auto-maintain, inline-signing". Based on the rest of the answer, it doesn't sound like that was actually what you tried to make happen? – Håkan Lindqvist Jun 10 at 20:03
  • If you are actually trying to use auto-dnssec maintain + inline-signing yes, then why would you invoke dnssec-signzone? That seems like asking for trouble by immediately stepping on the toes of the automated process. – Håkan Lindqvist Jun 10 at 20:05
  • First problem to solve is to get non-expired signatures created and propagated. That is where dnssec-signzone comes in. I experienced unanticipated difficulties there which led directly to this question. Now that the zone signatures are not expired I have returned to the problem of why inline signing is not working. I believe that the problems uncovered getting the zones signed manually were the likely cause but, as I wrote, that remains to be seen. – James B. Byrne Jun 11 at 16:38
  • The point I am making is specifically that when using auto-dnssec maintain you do not use dnssec-signzone as part of the process of getting non-expired signatures created. Hence why object to the way the last sentence seems to imply a different goal than the steps. – Håkan Lindqvist Jun 11 at 16:52
  • If inline signing is not working and the zone signature has expired then the first objective is to get the zone signed. Then we worry about the inline-signing problem. The two are orthogonal problems. – James B. Byrne Jun 11 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.