Hi Doug, Quoting Doug Barton on Saturday August 08, 2020: > > I'm not convinced by this draft as-is that there is any purpose to making > this split. You refer several times to proposed novel changes to the ARPA > zone that can't be done because of the entanglement, where are the > references?
The challenges of the current configuration are manifest. On a day-to-day operational level, we have two distinct zones served by the same authorities, one a child of the other. Edits to the NS-set of one zone need to be coordinated with the another. When we change the IP address of a root server, two parallel coordinated edits need to be done synchronously in the arpa zone and the root zone. Approval processes differ for both. As a consequence there are special-casing rules throughout our root management code and business processes that specifically pertain to "arpa" that we are keen to get rid of. Can we continue to cater for it? Certainly. But there appears to be no compelling reason to want to strive to persist this. Distinct from that, the conservative approach to administration of the root zone inhibits potential applicatons of the arpa zone. Just one example is the notion of adding a DNAME record for an arpa application - because such a record would be served using the shared root infrastructure, it is assessed there would be the significant impediment associated with all the due diligence that would go with that. It is foreseeable that any future evolution of the arpa zone to use new resource record types or other kinds of configuration changes will be analysed through the lens of root operations so long as they operate on shared infrastructure. > I realize that I-Ds are not supposed to be used as protocol > references, but this is an example of where referring to them as works in > progress is justified. Folks reading the RFC 10 or 20 years from now won't > have the context that some current readers do, and for that matter, I don't > have it now. Without some way to judge the value that would accrue from > making this change, it's impossible to justify the herculean effort it would > take to do this change, and do it properly/safely. I don't foresee it as herculean, in fact, I think it represents straightforward changes that will result in significant benefits. Other zones, including top-level domains, change their authorities often and it is not considered problematic — it is considered a normal part of zone administration. The root zone is special as the entry point to the DNS, but arpa is only drawn into this specialness by virtue of being on shared infrastructure with the root. > Assuming you convince us that the change is needed, I suggest that you > change the ns name space to arpa-servers. I understand the value of keeping > the name server host names short, but given the unique role of the ARPA zone > I can easily imagine a scenario where it would be desirable to use the ns > name space for something else down the road. I do realize that even today > there are places in the world that are bandwidth-constrained, but using the > same label across the NS set allows for compression which would essentially > eliminate the "cost" of the longer label. Perhaps to level-set: the goal was not to convince this mailing list of the need for a change, it was to get additional perspective to identify potential problems that have not been foreseen with the approach. We manage the arpa zone at the behest of the IAB, and in the context of that relationship we'll ultimately agree the specifics of how to evolve the zone. > Whatever the label turns out to be, I think you should make clear whether or > not (and I assume not) you intend for the name server name space to be a > delegated subzone, or just a host name convention, and why. It's a fairly > nitpicky detail, but when you're making an operational plan that has this > many moving parts, with this many players in the game, and affecting so many > end users, I don't think it hurts to over-specify the requirements a little. > :) What do you see as the operational impact of one versus the other? I think before going into very specific levels of detail it should be rooted in a discussion about the side-effects you are trying to avoid and why they are specifically relevant to the arpa zone. > Finally, by definition splitting the operations of the ARPA zone away from > the current process increases the attack surface. Can you elaborate further what you mean here? Are there any unique risks that pertain to arpa you've identified, or the same general risks as when you change the NS-set of any zone? > You'll have more/different > eyes and hands at every step of the way. That should be acknowledged in the > Security section. I would also like to see a robust description regarding > how the integrity of the content of the zone is going to be secured, how the > change process is going to work, etc. As written the Security section > basically says, "It'll be like it is now," which of course is not, strictly > speaking, the case. My take is this is a high-level expression of an operational change that is notable, but the details that would underly its implementation are not. Of course detailed plans are needed by the operator and other directly involved parties, as is the case of any other zone, but such ephemeral details are probably not best suited for RFCs. I think the most useful thing is to identifying special considerations that pertain uniquely the "arpa", as opposed to general concerns that any other zone would have to consider, and highlight these issues and how they are being addressed. kim _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
