0

I'm having trouble with getting DNSSEC automatic signing to actually be automatic. It fails to sign automatically (well, it does sign automatically, but apparently signs the wrong thing, see below). In addition, cryptic errors are occasionally generated at unpredictable times, and then seem to go away again.

The setup:

zone "example.com" in {
   # file "/etc/bind/zones/db.example.com";  # raw data comment out
   file "/etc/bind/zones/db.example.com.signed";
   key-directory "/etc/bind/keys";
   auto-dnssec maintain;
   inline-signing yes;
};

Then I sign the zone:

dnssec-signzone -o example.com -t -k ../keys/Kexample.com.+008+04309.key db.example.com ./keys/Kexample.com.+008+21996.key

and then update everything:

rndc reload
rndc reconfig
rndc loadkeys example.com
rndc signing -list example.com

Seems like everything worked. No errors, not even in syslog, and dig @ns.example.com example.com responds appropriately. As does dig @ns.example.com +dnssec +cd +multiline example.com. Looks healthy as a horse. Well, almost. When I look at the directory: ls -la /etc/bind/zones I see things that struck me as peculiar:

-rw-r--r-- 1 root root  4578 Apr 14 11:06 db.example.com
-rw-r--r-- 1 root bind 21189 Apr 14 13:01 db.example.com.signed
-rw-r--r-- 1 bind bind   512 Apr 14 13:01 db.example.com.signed.jbk
-rw-r--r-- 1 bind bind  4720 Apr 14 13:15 db.example.com.signed.signed
-rw-r--r-- 1 bind bind 67248 Apr 14 13:24 db.example.com.signed.signed.jnl

Signed signed files? Huh? OK, but everything works. Well, almost everything. Soon thereafter, I start seeing errors in syslog:

named[25494]: malformed transaction: /etc/bind/zones/db.example.com.signed.signed.jnl last serial 2021041421 != transaction first serial 2021041404
named[25494]: zone example.com/IN (signed): zone_sign:dns_journal_write_transaction -> unexpected error

This will appear in bursts, repeating once a minute, and then they go away for a while (no predictable pattern). They seem to go away when I say rndc sync -clean. A new copy of db.example.com.signed.signed shows up every so often, on unpredictable timescales: maybe after 5 minutes, maybe after half an hour, maybe after a few hours.

Whatever. We're all good now. Ignore things for a month, come back and find the DNSSEC signatures have expired! How can that be? ls -la shows that the timestamps on db.example.com.signed.signed and db.example.com.signed.signed.jnl are recent: obviously, bind9 thinks that these need to be regularly updated. The timestamp on db.example.com.signed is old - a month old, and looking at it's contents, I see that, indeed, RRSIG SOA has a now-expired timestamp on it.

Obviously, something is wrong. Since having the double-signed db.example.com.signed.signed file seems wrong, and since db.example.com.signed was never automatically updated, I figure that, ah hah! I should not have manually signed things! So I go back and edit the zone file to read:

zone "example.com" in {
   file "/etc/bind/zones/db.example.com";  # oh, maybe use this, the unsigned zone
   # file "/etc/bind/zones/db.example.com.signed"; # manual signing must be wrong.
   ...
};

But if I use the above, there is no combination of starting and stopping bind9 or issuing rndc commands that makes things work: nothing is signed, and the zone won't get served, and there are no errors. This includes trying rndc sign example.com which appears to do nothing: no errors, no messages, no changes to what is being served.

I can certainly resolve the above by sticking the manual dnssec-signzone into a crontab file, but that seems to evade the whole point of "automatic signing". What's going wrong, here? What did I do wrong?

This is named -v version BIND 9.11.3-1ubuntu1.14-Ubuntu.

Linas
  • 101
  • 3
  • If you want bind to sign automatically, you must use the file without signature, like in the last example. No need to sign anything with any command : just "rndc reload ZONE" and the signature is applied and in functional. The signed file is added in the /etc/bind/zones directory but must not be used in the configuration – Dom Apr 14 '21 at 19:30
  • Hi @Dom Well, by the end, that's what I concluded. Tried that (described above) but no signed files ever show up, and the server won't serve anything at all (`dig` comes back blank). There aren't any error messages, either ... just that nothing happens and nothing is served. – Linas Apr 14 '21 at 19:47
  • Indeed, you are not supposed to use the old tooling like dnssec-signzone together with the newer automated signing (auto-dnssec maintain). What does it mean that "dig comes back blank"? What does it say? And anything relevant in the logs? See https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html#easy-start-guide-for-authoritative-servers for reference – Håkan Lindqvist Apr 14 '21 at 20:32
  • 1
    I *suspect* that you have some combination of zone files and journal files that are out of sync? – Håkan Lindqvist Apr 14 '21 at 20:34
  • "dig comes back blank" == dig prints headers and a question section; there is no answer, authority or additional sections printed. – Linas Apr 15 '21 at 02:35

1 Answers1

0

I found a "nuclear option" that appears to restore the system into a state consistent with documentation. It consists of the following steps:

service bind9 stop

Halt the daemon while we work on things. The other nameservers will pick up the slack.

Next, remove autogenerated/cached files:

rm -r /var/cache/bind/*

This directory contains assorted auto-generated files. These appear to contain stale data that interferes with the interpretation of the zone files and the ZSK/KSK state (i.e. contain cached values that are inappropriate). These will be recreated upon startup.

Next, edit all zone files (not just some of them!), and increment the serials by 50 to 100. This number needs to be large enough to avoid potential complaints about malformed transaction, last serial != transaction first serial. This large increment may need to be done more than once.

Edit all zone files, convert any $INCLUDE statements to use absolute paths, instead of relative paths. Although relative paths work just fine for unsigned zones, it seems that when a zone is signed, the relative path is misinterpreted (this smells like a bind9 bug to me... its hard to see why it would matter.).

There are also more autogenerated/cached files that are found in /etc/bind/zones; these should be removed.

rm *.signed *.jnl *.jbk

These files will all be recreated upon server startup. They contain cached information (such as the old serial numbers) that lead to spurious errors.

Do not use dnssec-signzone. This is not needed, and using it will generate files that conflict with automated zone signing.

Finally, restart the server.

service bind9 start

The above seems to be enough to clear out inconsistent cached data, and at this time, seems to be generating valid, signed zones, for me. It will take some number of TTL's and rollovers to see if things continue to work. For now, at least, behavior is consistent with documentation and with "common sense", for me.

Linas
  • 101
  • 3