Hi Doug, I am not suggesting that you are wrong in your final paragraph, and I am not philosophically opposed to reserving a label in the root zone for private use, somehow analogously to RFC1918, but I think it's worth challenging how obvious this really is. (Yours is just a convenient hook to hang this reply to; it's not really directed just at you.)
I do think the semantic meaning of the label is worth thinking about, and I am wary of particular scripts or languages being chosen arbitrarily. I realise "internal" and "private" are sensible labels to use for this kind of thing if you are English-speaking and used to reading Latin script; I don't know that it's reasonable not to care that they might not be sensible in other contexts. This to me is a much more important conversation than bikeshedding about what regulatory agency has said what about what. It's also perhaps worth mentioning that the mechanics of how to provision (or not provision) such a name with regard to DNSSEC validation by various elements of the wider ecosystem have been a matter of some debate in other venues. I doubt that dnsop is immune to that. I won't fulfil that epectation by saying more in this message. :-) So, on the subject of how obvious it is that we need to reserve a top-level label for private namespaces, - has the advice to anchor a private namespace in a registered domain in the private namespace really been received and judged to be insufficient? Or has it just not been received? Could such advice be delivered in a more effective way? - does the growth in observed query traffic for names with non-existant top-level labels really support the idea that squatting on arbitrary undelegated TLDs is on the rise? Is it possible there are other effects? Have we normalised the observed growth against other known causes of growth? If this phenomenon is actually becoming less common, does it need a solution beyond "wait"? - what are the possible negative effects of providing a TLD label for use in private namespaces? We know that in the addressing realm, RFC 1918 and similar private-use addresses lead to collisions during M&A, interconnections, etc. Perhaps these are reasonable trade-offs for addresses. Is the same true for names? - does promoting a single anchor for private namespaces concentrate traffic that leaks from those internal contexts to the Internet's DNS? If the leakage of queries that are intended to be private represents a security concern, does the concentration of targets for that traffic on the Internet make the security concern worse? For the record, I don't personally see any enormous harm from standardising something like Warren's ".internal" (or Roy's ".zzz", to make it clear that I'm not talking about the specific label). But I do think questions like the ones I mentioned are worth putting some effort into answering. Perhaps I've missed some elegant and robust analysis, but to date all I've seen is "nobody likes the advice to register MYCO.COM (http://MYCO.COM) and use that, so obviously we need to do something". If that's really where we are, it seems like it would be comforting to be able to say so more convincingly. Joe > On Thursday, Nov 28, 2019 at 16:38, Doug Barton <do...@dougbarton.us > (mailto:do...@dougbarton.us)> wrote: > On 11/28/19 8:55 AM, John Levine wrote: > > In article <71ad677a-8c88-8916-fe02-7d0d8ae93...@dougbarton.us> you write: > > > I agree with Matt, Bill Woodcock, Steve Crocker, and others that have > > > expressed that we should stay out of ISO's sandbox. Whatever the rules > > > are today, they can change, and poaching their stuff for our purposes is > > > bad form (and yes, I feel that poaching is what is being proposed, in > > > spite of the arguments to the contrary). > > > > I don't see how relying on ISO's advice is poaching. They say: > > You, like Ted, are ignoring the fact that ISO can choose to change those > rules. > > > > ICANN has already said that it's not going to ever delegate CORP, HOME, > > > or MAIL. > > > > They said indefinitely defer which is not the same thing at all. > > Ok, so if you think there is a risk here, then it should be mitigated by > working together with ICANN on a draft that codifies that they will > never be delegated. Since there is apparently a need for additional such > names (like INTERNAL) then they should be included. > > Other than some sort of gratuitous "we hate ICANN so we don't want to > work with them" thing, it's not at all clear to me why we wouldn't want > to lock the necessary resources down in cooperation with the only other > entity that has anything to say about what happens in the root zone. > > > The IETF has already decided to stay out of the home/corp/mail > > argument > > The IETF can change its mind too. :) > > Seriously, there is obviously a need to have private-use TLDs that we > can guarantee will never be part of the public root zone. So let's make > that happen, in a way that we can be sure will never be pulled out from > under us. > > Doug > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
