> On 28 Oct 2023, at 16:40, Paul Wouters <[email protected]> wrote: > > On Oct 25, 2023, at 13:14, Johan Stenstam > <[email protected]> wrote: >> >> To begin with it works equally well with or without DNSSEC. > > That statements seems a little odd?
Ok, let me rephrase: As a synchronisation mechanism based on a signed DNS UPDATE message that carries both the data to be modified and the proof that the change request originated with the owner (the child) and has not been modified in transit… it works equally well with or without DNSSEC. I don’t know how to make that any clearer. >> Furthermore it is a cleaner solution than what we currently have (i.e. child >> zone published CDS and/or CSYNC and parent at some future time will get >> around to scan for it). Replacing all this this with a single DNS UPDATE is >> something we should have (and could have) done long before either CDS or >> CSYNC were invented. > > You seem to assume we didn’t know this when CDS and CSYNC were created. The > question to ask is, why at the time we thought those new mechanisms were > needed, and whether those reasons have changed since then. Of course we knew. But knowing doesn’t automatically result in a solution that works for everyone. If the DNSSE deployment history should teach us anything at all it is to be humble. We should be humble because we got it wrong so many times. And then we backtracked and got it wrong again. Over time we made progress, but it hasn’t exactly been a straight line. And if this happens to be yet another case where a little bit of backtracking allows us to end up with a better solution that works for a larger class of use cases then I think it would be better to argue about the technical merits of different alternatives rather than by default assume that we got everything right the first time. >> The reason we didn’t was to some extent that we had higher hopes for DNSSEC >> deployment rate than were justified, but primarily that we didn’t address >> the question of how to figure out were to send the UPDATE when used across >> organisational boundaries. Now we know more about the DNSSEC deployment rate >> and we also have a proposal for locating the target for the UPDATE. > > I don’t agree that adoption rate changes any justificstions for new > protocols. I think that’s perhaps the real core for where we perhaps disagree. I do not agree that this is “a new protocol”. This mechanism is more than 15 years old. I think that one important question to ask is “given that we already have the DNS UPDATE based synchronisation mechanism, why isn’t that used?”. And my answer is that it has not been used because of two reasons: 1. Where to send the UPDATE is unclear (when crossing organisational borders). 2. Many parents cannot accept that an UPDATE with a valid signature immediately changes the zone. Additional safety checks are required (as you pointed out). Both of these issues are now being addressed. >> And so this draft was born. > > Mark pointed out we have those “where to send UPDATES” infrastructure already > ? You may have misunderstood what Mark said. We have all the infrastructure EXCEPT where to send the UPDATE. In a local context (inside a sufficiently small organisation) that is easy to figure out. But across organisational borders not so much. >> How many parent zones do we have in the universe? Millions, most likely. How >> many of these parents have deployed CDS and CSYNC scanners? Perhaps a couple >> of dozen. Compared to the deployment rate of DNSSEC in general the >> deployment rate of CDS and CSYNC scanners is so completely lacking that I >> think we, i.e. the DNS community, should ponder the following question very >> seriously: >> >> Do we really think that CDS/CSYNC scanners are the only answer we need to >> the question of how to achieve full automation of delegation information >> between child and parent? >> >> If the answer is “no” then I’d love to hear more suggestions than this >> proposal. > > I think you are confusing two very different use cases. Generic registration > TLDs and DNS deployments within the same organization. The latter can clearly > be done with stock DNS UPDATES. The TLD case is special as it involves the > RRR ICANN model. The *g*TLD case is special as it involves the RRR ICANN model. There are however lots of other TLDs. And I don’t understand why you think I confuse these two cases. I completely agree that in the “TLD case” (that I refer to as the “parent is a registry case” CDS/CSYNC scanners + generic notifications work, and are being deployed. I primarily care about the rest of the infrastructure. However, you simplify too much when you only list two use cases. There are more. To begin with internal delegations within the “same organisation” is not quite as easy as “just do stock DNS UPDATE”. Organisations are sometimes very large. They are really not “the same organisation”. They have internal communication issues, policies and rules. While this draft argues for the advantages of DNS UPDATE as a good mechanism for synchronisation of delegation information I will absolutely not say that it will just work in those cases. Sometimes a DNS UPDATE may be the right approach, sometimes an internal API will be the way to go. Yes, I think we want a “where to send the NOTIFY / UPDATE / etc” scheme that directs the child to use a corporate API, but that’s a topic for later. But if we step outside the “inside a single organisation” part there are large parts of the public name space where the parent is not a registry (academia, health care, various NGOs, etc). And, finally, even when the parent is a registry, TLD or not, well, we can collectively agree that it would be great if everyone and their dog had deployed DNSSEC. But they haven’t. And we can agree that we should not “hack around” the lack of DNSSEC to at a higher complexity cost also provide automation to the non-DNSSEC parts of society. But I argue that when the proposed mechanism is LESS COMPLEX than then existing DNSSEC-dependent synchronisation mechanism (based on CDS and CSYNC scanners) then it is a flawed argument to object on the grounds that it just happens to work fine also for the millions of zones that have not yet seen the DNSSEC light. > Any reasoning about deployments need to take this into account. I fully agree. But let’s ensure that we have identified the correct scope of the problem rather than cherry-picking the two simplest cases. Johan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
