virtualmin / virtualmin-gpl

Virtualmin web hosting control panel for Webmin
https://www.virtualmin.com
GNU General Public License v3.0
308 stars 95 forks source link

DNSSEC RRSIG and TLSA records not updated with TTL changes and with `modify-dns --add-record-with-ttl` command #410

Open beat opened 2 years ago

beat commented 2 years ago

We had many problems with DNSSEC records not being updated automatically properly on many DNS changes, so they are probably related:

The general problem is that imho a DNSSEC-enabled zone should be automatically DNSSEC re-signed on any change (including file edits and modify-dns command-line command.

The effect of this bug is big but very hard to spot, specially when moving a site with short TTLs and then re-increasing the TTL: As RRSIG records remain very low, this provokes e.g. sporadic long delays, but only for users that use DNSSEC, as re-validating processes, are sometimes slow.

  1. When changing the TTL of a record, the DNSSEC and TLSA records default TTL of a domain, the records themselves are updated, but not when chaning them back to "default".
  2. They are not updated when changing the default TTL of the zone.
  3. As there is no command to just change a DNS entry, in my DynDNS script, I have to do a modify-dns --remove-record followed by a modify-dns --add-record-with-ttl command. However, there is no DNSSEC re-signing performed with the new record, and the domain is not accessible anymore by DNS clients using DNSSEC.

To reproduce:

  1. Sign a domain with DNSSEC
  2. Check in file that the TTL of the RRSIG records are same as the A records.
  3. Change an A record to a different TTL
  4. Change the default TTL of the domain
  5. Apply domain
  6. Check in file that TTLs of the RRSIG have been updated: They are not! Still the old TTLs are present
  7. Click "Sign" in "DNSSEC Setup key" to re-sign the domain
  8. Check in file that TTLs of the RRSIG have been updated: They are now with same TTL!
  9. Issue a command virtualmin modify-dns --add-record-with-ttl mydomainname A 90 10.0.0.11
  10. Check in file that TTLs of the RRSIG have been added: They are not!
  11. Click "Sign" in "DNSSEC Setup key" to re-sign the domain
  12. Check in file that RRSIG with correct have been updated: They are now with same TTL!
chris001 commented 2 years ago

Which version of BIND are you using @beat ? Because if you're using 9.16 or newer, (and you really should upgrade if you're not on 9.16 or newer) then you (or ideally, Virtualmin) should enable features in BIND to automatically manage creating, removing, updating, deleting all DNSSEC records, keeping DNSSEC signatures current/valid, automating key rotation, taking into account TTLs.

https://github.com/nitmir/bind-dnssec (Used to need to write scripts or use additional code, such as this, to manage the DNSSEC things that earlier versions of BIND didn't maintain, such as key generation and key rotation that accounts for key expiration time and the various TTLs. This code while helpful to understand how DNSSEC maintenance happens, is no longer needed as its functionality is now a built in part of the more recent versions of BIND.)

Since version 9.7, BIND9 added support for auto-dnssec. After initial configuration, servers using auto-dnssec will automatically sign and re-sign zones at the appropriate time as determined by key metadata. However, keys generation and rotation planning is (was) left to the DNS operator.

Since BIND9 9.9, BIND9 support inline signing. This means that the signature process in completely transparent with regard to the DNS zone file. Virtualmin doesn't need to run any BIND sign zone commands! Instead, every time you create or modify a DNS record, BIND signs the record's corresponding DNSSEC record!

. . .
options {
  . . .
  dnssec-enable yes;
  key-directory "/usr/local/etc/namedb/master/";
  dnssec-validation auto;
. . .
}
. . .
zone example.com {
  type master;
  file "/usr/local/etc/namedb/master/example.com.hosts";
  key-directory "/usr/local/etc/namedb/master/";
  auto-dnssec maintain;
  inline-signing yes;
};

Official BIND DNSSEC Signing guide: https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html#dnssec-signing

https://www.sidn.nl/a/dnssec/dnssec-signatures-in-bind-named

If you use the auto-dnssec maintain option, the key directory is checked every hour for changes to the key pairs. Depending on the meta-data in the key files, each key pair is assigned the status 'unpublished', 'published', 'active', 'expired' or 'withdrawn'. Thus, the published DNSKEY records are automatically kept up to date. In addition, the digital signatures (in the RRSIG records) can be reset where necessary. The effect of this option is therefore the same as the effect of including the 'rndc sign' command in a cron job, in combination with the 'auto-dnssec allow' option.

https://www.sidn.nl/en/news-and-blogs/dnssec-signing-and-key-management-fully-automated BIND 9.16 DNSSEC signing and key management fully automated

From version 9.15.6, policies for key management and zone signing can be specified in the configuration file named.conf. The software will then automatically ensure that signatures (RRSIG records) and ZSK/KSK pairs are always up-to-date. As a result, scripts and cron jobs are no longer necessary to keep signed zones updated.

From version 9.15.6 of BIND named, you can specify a 'dnssec-policy' in named.conf. That's done by adding a statement to the zone configuration, as follows:

  zone "example.nl." {
      type master;
      file "db.example.nl";
      dnssec-policy "dnssec-policy-1";
  };

The DNSSEC policy in turn points to a definition in the global configuration:

    dnssecpolicy "dnssec-policy-1" {
    ...
    }

On page 136 of the BIND 9 Administrator Reference Manual (ARM) for version 9.15.7 and on the BIND wiki a number of specimen policies (KASP configurations) are provided.

As a result, signing and rollovers can be fully automated, and new ZSK and KSK pairs will be generated automatically whenever they are needed.

chris001 commented 2 years ago

Since BIND named can function as both an (authoritative) name server and/or as a (caching) resolver...

How To Configure BIND as a DNSSEC validating resolver (a very good idea to protect all from DNS spoof cyber attacks):

  dnssec-enable yes;
  dnssec-validation auto;

Helpful commands to verify and troubleshoot your BIND DNSSEC config:

sudo rndc managed-keys status
sudo rndc secroots -
sudo rndc validation check
dig @localhost servfail.nl

The latter command (dig @localhost servfail.nl) should return status SERVFAIL. If not, DNSSEC validation on the local BIND DNS resolver, is not working, and should be enabled in config.