On Tue, Sep 24, 2024 at 12:49 AM Michael Paoli michael.paoli@berkeley.edu wrote:
On Tue, Sep 24, 2024 at 12:42 AM Michael Paoli michael.paoli@berkeley.edu wrote:
Not 100% sure what's made that difference between the domains. Some are exact same gTLD and key types and sizes, and dnssec-policy and procedures, etc. used, yet still seeing somewhat different results.
So,
I think I've got the procedures all smoothly worked out ... though some I should still do some more testing on.
So, where'd I hit rough spots?
Yeah, notably the transition from auto-dnssec maintain to dnssec-policy That could've been better documented ... and/or I could've more thoroughly tested that first. Anyway, I believe I've got that all (or at least sufficiently) figured out at this point. BIND documentation implies that under dnssec-policy that rotation of key algorithms should be a non-issue. Of course I want to also be sure and test that on less critical domain(s) before presuming the documentation is quite correct on that.
This is what some of my named.conf.local now contains on the matter: //////////////////////////////////////////////////////////////////////// // dnssec-policy definitions // doc/bind9-doc/arm/reference.html#dnssec-policy-block-grammar // named -C | sed -ne '/^dnssec-policy "default" {$/,/^};$/{/^$/d;p};/^dnssec-policy "insecure" {$/,/^};$/{p;/^};$/q}' // https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy... // https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xht...
// auto-dnssec --> dnssec-policy: // Beware the following which can break DNSSEC: // Keys which are (far) too old, per policy, are instantly dropped, // even if they're in active use. Make use of dnssec-settime to // freshen that metadata and prevent that issue, e.g.: // # (cd /var/cache/bind/keys && // dnssec-settime -f -s Kdnssec.tmp.balug.org.+013+19831) // on key to update. Then to ensure that's (re)loaded, e.g.: // # systemctl reload named.service
If one is curious, lots of testing on dnssec.tmp.balug.org. (And that, useful enough, and perhaps again in future, I'll probably keep it around ... though may move it to, e.g. dnssec-test.balug.org.). One can look over many of those changes, including smooth and proper, and also anything but (and how to thoroughly break things), by looking over relevant history, see: https://dnsviz.net/d/dnssec.tmp.balug.org/dnssec/ And the earlier saved versions, the now current: https://dnsviz.net/d/dnssec.tmp.balug.org/ZvOVUA/dnssec/ and what came before it. Examples of both rotating KSK and ZSK. https://dnsviz.net/ will complain (slightly) about that zone, notably on some of the SOA data (vs. keys), notably: " RRSIG dnssec.tmp.balug.org/SOA alg 13, id 6523: With a TTL of 3600 the RRSIG RR can be in the cache of a non-validating resolver until 54 minutes after it expires at 2024-09-25 04:50:30+00:00. See RFC 4035, Sec. 5.3.3. " That's consequence of the way some of the testing is configured for that domain. Notably quite minimally permissible SOA values (per RFCs), and also quite short key and related timings - notably to be able to run tests on rotations and the like in much more reasonable timeframes (e.g. like around to well under an hour, as opposed to around 30 to 90 days or so), so, the compromises on those values - rather atypical, but quite handy for testing, lead to https://dnsviz.net/ finding one bit in RFCs between SOA data and some DNSSEC data that's not fully okay per RFCs (or, well, one bit of one RFC). Yes, https://dnsviz.net/ does some pretty darn good comprehensive testing - well including DNSSEC, but also quite useful even more generally in that regard for DNS - even without DNSSEC. So, domains and DNSSEC history testing ... now have: dnssec.tmp.balug.org. (though may relocate that to, e.g.: dnssec-test.balug.org.) Just recently got rid of: dnssec-test.mpaoli.net. and earlier dropped: tmp2.mpaoli.net. tmp.mpaoli.net. Though that last one may pop in and out of existence in various forms.