Tim Wicinski <[email protected]> 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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
