| Beide Seiten, vorherige ÜberarbeitungVorherige ÜberarbeitungNächste Überarbeitung | Vorherige Überarbeitung |
| pr:bind-lost-keys [2026/04/06 18:14] – [Diagnosis] martok | pr:bind-lost-keys [2026/04/07 10:40] (aktuell) – martok |
|---|
| |
| BIND has changed their DNSSEC management mechanism from ''auto-dnssec maintain;'' to policy-based management. This by itself does cause many headaches, but not immediate bugs. | BIND has changed their DNSSEC management mechanism from ''auto-dnssec maintain;'' to policy-based management. This by itself does cause many headaches, but not immediate bugs. |
| Unless the policy chooses to generate keys for signature schemes that are not actually used, for example because one later changes the policy defintion (i.e. initially RSA signatures were defined, but the registrar doesn't actually want them so you later change the policy to not generate them - but there are now some RRSIG in the dynamic signed zone. So we just adjust the policy and remove the unneeded keys, right? <color #ed1c24>WRONG</color>! [[https://narkive.com/5GuCbBeC|Do not stupidly delete ZSK files]]! | Unless the policy chooses to generate keys for signature schemes that are not actually used, for example because one later changes the policy definition (i.e. initially RSA signatures were defined, but the registrar doesn't actually want them so you later change the policy to not generate them - but there are now some RRSIG in the dynamic signed zone. So we just adjust the policy and remove the unneeded keys, right? <color #ed1c24>WRONG</color>! [[https://narkive.com/5GuCbBeC|Do not stupidly delete ZSK files]]! |
| |
| This used to be mostly fine with ''maintain'', but it absolutely breaks keymgr in many fun ways. The most obvious is that any time incremental signing is to be done (so usually every few weeks), BIND runs into an infinite loop that attempts to clean up the (expired) signature, fails to find the key file to keep track of the key state, and retries a few milliseconds later. Forever. And each of those also leaves journal entries in the zone's ''.signed.jnl'' file, which depending on settings can make these infinitely large - although something else usually breaks first, leading to "non-minimal diff" log messages. | This used to be mostly fine with ''maintain'', but it absolutely breaks keymgr in many fun ways. The most obvious is that any time incremental signing is to be done (so usually every few weeks), BIND runs into an infinite loop that attempts to clean up the (expired) signature, fails to find the key file to keep track of the key state, and retries a few milliseconds later. Forever. And each of those also leaves journal entries in the zone's ''.signed.jnl'' file, which depending on settings can make these infinitely large - although something else usually breaks first, leading to "non-minimal diff" log messages. |
| |
| Now we need to give BIND something to write its state in. But we don't have the key material anymore? | Now we need to give BIND something to write its state in. But we don't have the key material anymore? |
| Turns out we do (at least the public part), in the currently RRset! So we query ourself for every domain that repots an issue and let ''dnssec-import'' create a fake state file. We then immediately expire this key. | Turns out we do (at least the public part), in the currently RRset! So we query ourself for every domain that reports an issue and let ''dnssec-import'' create a fake state file. We then immediately expire this key. |
| |
| <code bash> | <code bash> |
| #!/bin/bash | #!/bin/bash |
| |
| # https://bind9-users.isc.narkive.com/5GuCbBeC/do-not-stupidly-delete-zsk-files | |
| |
| test -d dist || mkdir dist | test -d dist || mkdir dist |
| dig @::1 DNSKEY $d | dnssec-importkey -f - $d > /dev/null | dig @::1 DNSKEY $d | dnssec-importkey -f - $d > /dev/null |
| |
| if [ -f $k ] ; then | if [ -f $k.key ] ; then |
| # expire it | # expire it |
| dnssec-settime -D now $k.key | dnssec-settime -D now $k.key |
