Hi David, Thanks, again with no hats, except for my comment on the first question. Please see inline …
From: David Conrad <[email protected]> Sent: 23 October 2022 20:01 To: Rob Wilton (rwilton) <[email protected]> Cc: [email protected] Subject: Re: [DNSOP] [Ext] Possible alt-tld last call? Rob, On Oct 22, 2022, at 10:33 AM, Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> wrote: As I read it, the partitioning of the domain name namespace is really to achieve two aims: On this mailing list, I think there is a pretty good understanding of the intent of .alt and I don’t think there is much in the way of disagreement on that intent. As far as I can tell, the points of contention are: 1. whether the IETF “reserving” a TLD is intruding on ICANN’s territory. RW: With a “responsible AD for this document hat on”, I would like to ask the WG to consider this question as being out of scope for the moment, and assume that this work is within the scope of the IETF. After WG LC, I propose that the WG chairs, ADs, IAB, and ICANN liaison discuss this. My current expectation is that we probably will send ICANN a liaison to politely let them know what we are doing, so that they have the opportunity to comment, and we would consider any feedback that they give, returning the document back to the WG, if needed. 1. whether there will be a registry of .alt uses (i.e., non-DNS name resolution systems) and if so, who will operate that registry. RW: The document should only define a registry of .alt uses if the registry is managed by IANA. 3) whether the inevitable leakage of .alt queries to the DNS represent potential issues, and if so, should there be an effort to address those issues. RW: I’ll defer answering that one to the experts, on which I am not one. FWIW, my views: 1) Ask the stupid question. 2) A voluntary, lightweight registry operated by IANA can help developers avoid collision. 3) Identifying leakage to the DNS as a protocol violation can, over time, help reduce that leakage. This is outside my area of expertise, but I'm not convinced that the global DNS would see any significant increase in load, because the stub resolver would generally not be sending the requests to the DNS assuming that they are valid domains, and if they are not valid domains then that would seem to be the same as what DNS already handles today. The root of the DNS is a commons, supported by volunteers who are paying out of their own pocket to provision a global infrastructure. I’m personally not comfortable recommending techniques that can add undefined (could be minimal, might not be: no one knows for sure) load to that infrastructure. If you look at the ICANN OCTO web page Paul referenced earlier (https://magnitude.research.icann.org) and filter for “special use” TLDs, you’ll see data related to the number of queries received. Some of those (e.g., .local) are non-trivial and, in my opinion, are indications of brokenness that should be fixed — the root shouldn’t be seeing those queries. My suggestion of using RFC 2119 “MUST NOT” language (i.e., queries for names in .alt MUST NOT be sent to the root server system supported by IANA) is in an effort to discourage an increase in that query volume over time. RW: If this is a general problem for “special use” TLDs then it would be better to have a separate document that handles those consistently and generically rather than creating a new rule specifically for .alt domains. It seems obvious to me that if a namespace is explicitly defined to not be in the DNS, embedding a reliance on the DNS would be a protocol violation. I am actually surprised that this would be controversial. And as for the eavesdropping concern, doesn't this equally apply for all domain lookups, particularly invalid ones? As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS name resolution protocol is specified to not be plain text (presumably any new protocol would be encrypted), then users of that protocol have an expectation that their queries are protected. By falling back to DNS, that expectation is silently violated. RW: This is a reasonable point to consider, even though it also feels like the world may end up moving to DoH, or DoQ fairly quickly. Personally, I think that it is somewhat hard for users to have that general expectation if the name resolution is using a combination of name resolution protocols (including unencrypted DNS). Regards, Rob Regards, -drc
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
