On Wed, Aug 18, 2021 at 09:52:38PM +0200, Ralph Seichter <ra...@ml.seichter.de> wrote:
> * raf: > > > If you don't mind having a key that lasts "forever", you only > > need one(!) extra line in Bind's zone config, and one(!) manual > > interaction with your domain registrar. > > Well, sort of. As per default settings, BIND does not appear to create a > key signing key (KSK) / zone signing key (ZSK) pair, but instead one > single key to sign each zone. That's sufficient from a technical > perspective, but whenever that combined key changes, some key material > must be refreshed in the parent zone. > > I highly recommend investing the extra time and effort to generate > separate KSK and ZSK for each DNSSEC-protected domain. The KSK data will > need to be published once, but you can roll your ZSK whenever you please > without contacting a third party. This saves a lot of hassle in the long > run. Thanks. I am doing that, and it's really not that much more effort with bind-9.16+, other than initially having to learn and think about what policy you want, and the annual or so interactions with your registrar - but even a KSK should be rolled over occasionally if you want to Do The Right Thing. But the default unlimited CSK policy is fine if people just want DNSSEC and want it to be easy. As Viktor points out, ECDSA keys are fine for longer periods and you should still rotate it annually or so, but the default policy lets you choose when to manually rollover (also easy), rather than being forced to by the software when the key's time is up. But being forced to can also be good if you are beholden to a Cryptographic Key Management System. Knowing that you get to control the timing might be enough to convince people to use DNSSEC that otherwise might have been worried about the maintainence of it, and the very real risk of disappearing off the internet if you get it wrong. These days, 30% of DNS queries are DNSSEC-aware. But you can instead have a KSK with an unlimited lifetime, and manually rollover when it suits you. It's not only the default CSK policy that allows that. It just requires a lot more reading and a little more configuration. The adoption of DNSSEC seems to have increased a lot in the past 12 months (~30% increase). I'm hoping that the fact that it's become so much easier on debian stable might mean that it increases even faster. There is probably another advantange of using a CSK. In the early days of DNSSEC, people were worried about amplification attacks because of the large size of DNSKEY records. Most RSA KSKs are 2048-bit, and most RSA ZSKs are 1024-bit. Mitigations include using new smaller ECDSA keys (256-bit), and/or using only one key (CSK) instead of two (KSK+ZSK). That's probably less of an issue with ECDSA keys, but 256-bits smaller is 256-bits smaller. And Bind's default CSK policy uses a 256-bit ECDSA key. So it's the setup that is least susceptible to amplification attacks. That might be why they chose a CSK policy as the default. > -Ralph > > P.S.: If you're looking for a DNSSEC aware resolver, try Unbound. Thanks. I've heard of it but never tried it. I use Bind at home, and on my external VPS, to host zones, so I use it to resolve as well. But I should put Unbound on my laptop for when it's mobile. You never know what rubbish you get on other people's networks. :-) And it would be a good choice for any server running Postfix that isn't also already running Bind locally. * Viktor Dukhovni: > With ECDSA P256(13) as the DNSKEY (signature) algorithm, the incentive > to rotate keys frequently (~90 days) is substantially lower [...] I still use RSA keys (algorithm 8). My main point is that I find it more convenient to only roll ZSK, and to only place KSK data into the parent zone. The latter requires me to ask my hosting provider to manually update key material in the TLD zones, and I try to keep the frequency of these update low. "Your mileage may vary." ;-) -Ralph Bind can also automatically migrate your DNSKEY records over to ECDSA if you want. You need to be very careful of course (i.e. test it thorougly on a harmless VM that nobody's looking at and ask for advice from the bind users mailing list), but if you can migrate your existing Bind DNSSEC configuration to use the new dnssec-policy mechanism (if it isn't already), you can then just change the algorithm in the policy, reload Bind, and it will work out how to make it happen safely. At least, that's the impression I get. I haven't tried that. I'm only starting with DNSSEC now, so there's nothing to migrate. cheers, raf
