| Beide Seiten, vorherige ÜberarbeitungVorherige ÜberarbeitungNächste Überarbeitung | Vorherige Überarbeitung |
| pr:bind-lost-keys [2026/04/06 17:56] – 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. |
| zone_maintenance: zone security.fail/IN (signed): enter | zone_maintenance: zone security.fail/IN (signed): enter |
| zone_resigninc: zone security.fail/IN (signed): enter | zone_resigninc: zone security.fail/IN (signed): enter |
| zone_journal: zone openpgp.wtf/IN (signed): enter | |
| dns_zone_findkeys: error reading Ksecurity.fail.+010+24081.private: file not found | dns_zone_findkeys: error reading Ksecurity.fail.+010+24081.private: file not found |
| dns_zone_findkeys: error reading Ksecurity.fail.+014+65102.private: file not found | dns_zone_findkeys: error reading Ksecurity.fail.+014+65102.private: file not found |
| |
| 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> |
| dig @::1 DNSKEY $d | dnssec-importkey -f - $d > /dev/null | dig @::1 DNSKEY $d | dnssec-importkey -f - $d > /dev/null |
| |
| # expire it | if [ -f $k.key ] ; then |
| dnssec-settime -D now $k.key | # expire it |
| | dnssec-settime -D now $k.key |
| |
| # save for manual apply | # save for manual apply |
| chown bind:bind $k.* | chown bind:bind $k.* |
| echo $k.* | echo Created: $k.* |
| mv $k.* ./dist/ | mv $k.* ./dist/ |
| | else |
| | echo Not in RRset: $k |
| | fi |
| | |
| | # cleanup work dir |
| | rm K$d+*.{key,private} |
| done < ~/missingkeys.txt | done < ~/missingkeys.txt |
| </code> | </code> |
| Why ''loadkeys'' //and// ''sign''? The first only removes the signature and CDS binding, the second also the CDNSKEY records. | Why ''loadkeys'' //and// ''sign''? The first only removes the signature and CDS binding, the second also the CDNSKEY records. |
| |
| | |
| | ===== Cleanup ===== |
| | |
| | It's worth mentioning again: do NOT delete the key files, even after we've removed them from the zone. BIND will have taken the Deleted value we gave it, turned it into Inactive and added the usual delay to the new Deleted timer. Once that expires, the fake key files will be purged automatically. |
| |
| |
| |
