Re: [DNSOP] on private use TLDS

[Doug Barton <[e-mail]>]

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