Re: [DNSOP] on private use TLDS

[Joe Abley <[e-mail]>]

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 <[e-mail] (mailto:[e-mail])> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop