0

Three months ago I upgraded my DNS servers to BIND 9.16 (currently running 9.16.25) to take advantage of the new dnssec-policy default option which would allow me to easily run DNSSEC for my domains. Documentation indicated that key management would happen automatically. I implemented this, tested locally, looked like everything was getting signed just fine, and all seemed right with the world. I had not previously implemented DNSSEC in any form for these zones.

I later learned that I should have uploaded my DS records to my registrar to report to the TLD that my zones were signed and that would complete the circuit to allow DNSSEC to actually happen... so I started doing that this month. However, doing so, things started failing, and I quickly learned that all my signatures had expired 15 days after I implemented DNSSEC.

I tried doing a manual rollover of the keys for one zone. That changed the sigs for some of the records, but not all (no A, AAAA, CNAME records, for example). I looked in the docs for details of how dnssec-policy default is implemented, and found that the keys are set to not expire, but that the signatures are set to expire after 15 days or so... and that if the keys don't expire, no rollover will ever be scheduled. So what am I supposed to do about the expired sigs?

Does the dnssec-policy default really work as advertised and I'm missing something crucial, or should I really be rolling my own here?

Relevant settings in named.conf.options:

options {
[..]
        dnssec-validation auto;
        dnssec-policy default;
        dnssec-dnskey-kskonly yes;
        managed-keys-directory "/var/lib/bind";
[..]
};
Christopher Hinkle
  • 36
  • 5
  • "I later learned that I should have uploaded my DS records to my registrar to report to the TLD that my zones were signed" Yes otherwise there is no DNSSEC chain of trust so the fact that your zone is signed is pretty much irrelevant. This is kind of core of DNSSEC design, I recommend you make sure to fully understand this before going further (you mention not having done DNSSEC before there). As for "that all my signatures had expired 15 days after I implemented DNSSEC." this may be the case but is separate from the fact of sending the DS to the registry through registrar. – Patrick Mevzek Feb 18 '22 at 19:44
  • Thanks Patrick. The problem I ran into was that once I did upload my DS records, everything broke because the signatures had expired. I need to fix the signature expiration before I can upload the DS records in order to keep things from breaking when I do. Do you have any insight on how I can do that? – Christopher Hinkle Feb 18 '22 at 19:48
  • Did you look at your bind log files? Zones signatures and key updates should be logged? This can help: https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-Policy-(KASP) (it is about changes in 9.17 and if you can you should switch to it). See https://bind9.readthedocs.io/en/v9_16_26/dnssec-guide.html: "The dnssec-policy statement causes the zone to be signed and turns on automatic maintenance for the zone. This includes re-signing the zone as signatures expire and replacing keys on a periodic basis. " – Patrick Mevzek Feb 18 '22 at 19:50
  • I did indeed. I found the same documentation that you quoted, and that's exactly why I upgraded to Bind 9.16 to begin with (I mentioned that in the post). The logs show "reconfiguring zone keys" for each zone once an hour. Nonetheless, the signatures expired without them being renewed. The dnssec log shows the initial configuration, and then nothing except repeated reconfiguration entries despite the expirations. – Christopher Hinkle Feb 18 '22 at 20:00
  • Increase log level and double check all files/directories permissions. Do note also that 9.17 should be even simpler regarding DNSSEC than 9.16. I recommend you just try calmly from scratch with a toy zone and experiment. At this stage with the elements given I have no idea why things do not work for you. This: "I tried doing a manual rollover of the keys for one zone." is concerning. You either have to let bind do everything for you or you do everything manually but mixing the too might be a recipe for problems. – Patrick Mevzek Feb 18 '22 at 20:14
  • "The logs show "reconfiguring zone keys" for each zone once an hour." I don't think this should be the expected case. keys do not have to change so often. KSK are like for a year, ZSK for a few weeks. What can change more often is signatures. If bind is talking about keys so often there may be a problem there. – Patrick Mevzek Feb 18 '22 at 20:16
  • "There may be a problem there." RIGHT! That's why I'm asking the question. :) I've only got it using `dnssec-policy default` with no other configuration. It's using CSK instead of KSK/ZSK. I cannot use 9.17 because I'm using this on Ubuntu 20 which only appears to support 9.16 at the moment. – Christopher Hinkle Feb 18 '22 at 20:21

1 Answers1

0

See example in https://bind9.readthedocs.io/en/v9_16_26/dnssec-guide.html that says:

Enabling Automated DNSSEC Zone Maintenance and Key Generation

To sign a zone, add the following statement to its zone clause in the BIND 9 configuration file:

options {
    directory "/etc/bind";
    recursion no;
    ...
};

zone "example.com" in {
    ...
    dnssec-policy default;
    ...
};

The dnssec-policy statement causes the zone to be signed and turns on automatic maintenance for the zone. This includes re-signing the zone as signatures expire and replacing keys on a periodic basis. The value default selects the default policy, which contains values suitable for most situations.

Not that dnssec-policy can be in a zone statement, or in options but then it applies everywhere. Specially at the beginning, to test things, you might want to restrict things per zone. But other than that, it should work out of the box with that configuration.

If not the case for you, you need to give more details based on your logfiles.

Later in the same page you can have a look at the expected log lines with the above configuration:

07-Apr-2020 16:02:55.045 zone example.com/IN (signed): reconfiguring zone keys
07-Apr-2020 16:02:55.045 reloading configuration succeeded
07-Apr-2020 16:02:55.046 keymgr: DNSKEY example.com/ECDSAP256SHA256/10376 (CSK) created for policy default
07-Apr-2020 16:02:55.046 Fetching example.com/ECDSAP256SHA256/10376 (CSK) from key repository.
07-Apr-2020 16:02:55.046 DNSKEY example.com/ECDSAP256SHA256/10376 (CSK) is now published
07-Apr-2020 16:02:55.046 DNSKEY example.com/ECDSAP256SHA256/10376 (CSK) is now active
07-Apr-2020 16:02:55.048 zone example.com/IN (signed): next key event: 07-Apr-2020 18:07:55.045

See the signed on last line and the timestamp given when something (probably new signatures) will happen. As for:

I need to fix the signature expiration before I can upload the DS records in order to keep things from breaking when I do.

Even without problems, NEVER upload a DS without having checked locally the validation works end to end. You can do it with an online tool like DNSViz, specifying explicitly the new DS that you are about to add, and the tool will test things as if the DS is ok already. Note that normally the KSK (of which the DS record is an hash basically) is supposed to change "regularly" to the tune of once yearly to each 2 years or things like that. At which point you need to rotate the DS as well, but with cautions if you don't want to break resolution.

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
  • _Config_: I put the `dnssec-policy` line in my options statement intentionally because I wanted it to apply to all zones. _Logfiles_: my /var/log/named/dnssec log has the entries you describe except that it never says "(signed)" after any zone entry, and the "next key event" is always 60 minutes hence. When the 60 minutes is up, I get an entry: `zone example.com/IN: reconfiguring zone keys` and immediately after that another `next key event` entry. Nothing ever gets reconfigured. There are no errors present in the logs related to this process. – Christopher Hinkle Feb 18 '22 at 20:18