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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
