Hi Doug, I appreciate the response and I don't doubt your experience, but I do think there is some value in a more robust study around some of these questions. Really the prevalence of no-doubt well-informed but largely unsubstantiated opinions (to the level of detail that I was trying to infer) is what I am arguing we need to do better than.
Joe > On Thursday, Nov 28, 2019 at 17:52, Doug Barton <do...@dougbarton.us > (mailto:do...@dougbarton.us)> wrote: > On 11/28/19 2:20 PM, Joe Abley wrote: > > 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.) > > No worries, but thanks for clarifying. :) (And thanks for your well > thought out questions as well.) > > > 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. > > heh, it's funny you mention that. I actually considered raising that in > my first post, but decided to get over the hump of "let's do this" > first. I agree that we need to consider this issue. I think the obvious > choice would be to pick a word that has meaning in private space but no > value in public, then document several language's worth of it, along > with guidance not to delegate other translations of the word. This would > also solve the issue raised previously that "sometimes you need more > than one." > > > 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 fulfill that expectation by saying more in this message. :-) > > Agreed, but having names documented for this purpose will make the > DNSSEC bits easier, not harder. > > > 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? > > Yes. > > > Or has it just not been received? Could such advice be > > delivered in a more effective way? > > The market has rejected this advice. I could bore you with examples and > reasoning, but I have never worked with a client in an enterprise larger > than a taco stand that didn't have at least one private domains set up. > > It's fair to ask the question of do we need it, and it's also fair to > document answers to most/all of the questions you've raised as part of > the process. But given how things are in the real world, this is > something that needs to happen. > > > - 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"? > > In my experience the practice is so ubiquitous that while these > questions are good in the abstract, spending time on them would be a > waste of effort. That said, ICANN's name collision work is relevant > here, and I encourage anyone with interest in the topic to review that > at length. It was really well done, and well documented to boot. > > > - 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? > > This is a good question to address, although the collision risk for > non-common names in a private TLD is lower than the risk of collisions > of integers. Two orgs using PRIV might each have a www, but if one of > them has a naming convention of host-rack-floor.priv for their data > centers, that's not likely to collide. > > That said, the commonly chosen names already have a non-trivial risk for > collisions. The marginal risk of codifying a set of examples is in the > noise. > > > - 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? > > I don't see how we could make this worse. If you look at ICANN's name > collision work, the results are already concentrated in CORP, HOME, and > MAIL, which is why they were indefinitely-but-maybe-not-forever taken > out of the new gTLD program. > > > 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. > > I think the massive volume of queries for non-delegated TLDs hitting the > roots already makes that case, doesn't it? We know that this is, at > least, incredibly common; and in my experience nearly ubiquitous. I do > agree that we should make sure that we're not making anything worse by > doing it, but the existence of the demand cannot be more obvious. > > 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
