Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Wes Hardaker <[e-mail]>]

Tim Wicinski <[e-mail]> writes:

> This starts a Call for Adoption for draft-arends-private-use-tld

TLDR: As is, I'm afraid I can't support this draft for adoption.  First,
this seems an end-run around two other organizations.  And second, I
think there are potential concerns with how the RSS is expected to
handle this increased load.  Both of these, I think, are fixable but as
is it's a no-go from me.

The more complete version:

I agree with your assessment that it is "extremely unlikely" that ISO
3166 Maintenance Agency or ICANN would change their position on the
usability of these codes.  But, this document still makes use of the
codes without even asking either organization "what do you think if we
do this?". All because asking is difficult?  Why would the IETF take on
this land-grab without even consulting these other two agencies.

You claim that these reservations don't require "special handling", and
are thus not part of the special use namespace.  You state that they're
"special on a policy level, but not on a technical or protocol level",
to which I must disagree.  You're asking for new non/never-TLDs to be
not-created and this requires no technical or code-changes.  That
appears true on the face of the situation, until you consider what
happens when these queries leak to the real DNS, which they assuredly
will (we have piles of data proving this as you know).

What happens when an organization/company full of .zz configured
devices, many mobile, start assuming they can query for something under
.zz and they're not behind their organization's resolver that knows to
forward those requests to somewhere internally-special?  They end up at
the root.

I'm sure you're aware that we already have a code-base out there
generating vast numbers of requests that leak to the root [1].  And
that's only on a network change.  Imagine if all of these devices were
generating queries that leak to the root only based on the negative TTL
cache value and how many more queries those might generate.  Now, the
large negative cache in the root should make me feel better, but there
is also a lot of evidence that many resolvers don't seem to follow that
SOA field guidance. Thus, I have a hard time estimating the impact of
this but I have fears it may be larger than ideal (0).

In the end, I think this proposal *does* require technical changes.
Resolvers should black-hole these types of queries.  Better yet, place
this new domain in a place that has public NS records pointing to
non-routable addresses spaces (127.53.53.53 as an example) so that they
can't leak.  This really is, IMHO, a case of a special-use domain.

Meanwhile, your draft talks about the need for this to be a TLD but
doesn't actually argue for it.  You argue extensively why these 2 letter
codes will never cause problems and are used by many other organizations
in different ways too in attempt to achieve [2] status, but you don't
ever argue why this must be at a TLD rather than under something like
.arpa which the IETF has exclusive control over.  I get that a TLD is
easier, more friendly to-users, etc and I don't even disagree.  But I
think if you want this document with its extensive arguing to succeed,
this argument should be included too.


[1]: https://blog.apnic.net/2020/04/13/whats-in-a-name/
[2]: https://xkcd.com/1170/
-- 
Wes Hardaker
USC/ISI