Under DANE, the digital chain of trust goes (roughly):
- [Public visibility of the ceremony for the generation of the]
- ICANN Root Zone Key, which
- something something involving the TLD authorities and registrars, which culminates in validation of the
- DS Record which lists the domain's authorized
- KSK, [which may certify other,
- intermediate KSKs,] which certify/ies authorized
- ZSKs, which are used to produce
- RRSIGs on the
- TLSA Records containing the fingerprint of the
- TLS key which the server (certifies • ephemeral keys with; which it then) uses to encrypt communications.
Now, normally, (that is, pre-DANE,) if your main DNS server gets hijacked, this still isn't (yet) an unqualified "game over", as far as SSL is concerned: since there's still the issue (assuming HSTS) of getting a certificate matching the domain (and given OCSP, HPKP, etc, this is thankfully at least slightly nontrivial.)
However, for a browser or other client which actually implements DANE for positive authentication (that is, in the absence of a trusted-authority-anchored x509 certificate sequence), doesn't this mean that any access to publish new DNS records now allows complete and immediate destruction/spoofing of—not just access to, but, now—authenticity of all affected servers?
So what I am asking is if there's a way to define ZSKs which do NOT have the authority to generate any RRSIGs for TLSA records.
I would like to keep anything which is capable of directly certifying new TLS certificates (TLSA-signing keys, intermediate CAs' private keys, etc.) under cold storage and do all issuances/renewals in an offline/airgapped manner; while I will very likely need to commission more frequent updates to A/AAAA/SRV/TXT/other records.
Or am I stuck with having to secure a simple DDNS update infrastructure as if all my domains' HTTPS directly and immediately depended on it?