On 25 Oct 2023, at 17:31, Johan Stenstam <[email protected]> wrote:
> On 25 Oct 2023, at 11:32, Joe Abley <[email protected]> wrote: > >> 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”. Isn't the usual answer to that the same kind of ad-hoc, manual mechanisms you are trying to avoid? > 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 understand the desire for automation. I'm not sure I understand the part where automation is predicated on a manual exchange of a token. If manual exchange is an option, why not just manually exchange the DS RDATA? I'm also not sure I understand why bending the DNS into providing an authenticated API to signal between the system signing the child zone and the system producing the parent zone is better than building one using more conventional techniques like TLS, HTTP, REST, etc. Lastly, I'm not sure why people want to roll non-compromised keys anyway, or under what circumstances it's ok to trust a compromised system to automate a key replacement under those circumstances. I mean, there surely are some, but this feels like a difficult thing to match to a general solution. (People in Hamburg this week are tired of hearing me go on about this. Hopefully they have already pressed delete and are not freshly irritated by reading the same thing here.) Joe _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
