Hi Joe, > On 25 Oct 2023, at 11:32, Joe Abley <[email protected]> wrote: > > On 25 Oct 2023, at 10:10, Johan Stenstam > <[email protected]> wrote: > >> So now there’s a new draft, that further extends the same core idea (locate >> the target for the information being sent via a DNS lookup in the parent >> zone). However, the new draft >> (draft-johani-dnsop-delegation-mgmt-via-ddns-00) proposes that instead of >> sending a NOTIFY (triggering a scan from the recipient) the child sends a >> DNS UPDATE containing the exact change with a signature that can be verified >> by the recipient. > > I am not at all familiar with SIG(0), so bear with me. What is the key > distribution mechanism for the DNS UPDATE originator's public key? RFC 2931 > suggests an unsigned KEY RR, I think?
My answer is “whatever mechanism the child and parent is using today for communicating critical information like that”. The thing here is that I do not primarily expect the TLD registries to change from the current path of either no automation of synchronisation of delegation information OR running a CDS (and perhaps CSYNC) scanner. The problem I have with that is that this leaves out major parts of the namespace. I.e. I want a mechanism that works for the University of Foobar to automate the delegation information for a ~100 departments. I want a mechanism that works for the Stockholm Health Care district to deal with hundreds of hospitals, care givers and other parts of the local health care infora structure. Etc. Neither of those have DNS as a major focus, DNSSEC even less and they are extremely unlikely to run any CDS and/or CSYNC scanners in the foreseeable future. So what do all these parents that are not registries use today? All sorts of semi crappy mechanisms, from email, via webforms to various local APIs, etc. All of these mechanisms have drawbacks, all have security issues and all of them have a certain failure rate because there is manual labor involved. I want to completely get rid of the manual part of maintaining existing delegations and the proposal is to transport the public key to the parent in any way that is acceptable to both child and parent. I don’t think an unsigned KEY RR is a particularly attractive alternative, but I have nothing against a DNSSEC signed KEY RR. Johan PS. In the case where the parent *is* a registry, and there are registrars then I think an EPP extension for the submission of the public SIG(0) keys will work just fine. But, as I said, that’s not my primary goal at this time.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
