On Oct 23, 2022, at 12:00 PM, David Conrad <d...@virtualized.org> wrote: > 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. > 2) whether there will be a registry of .alt uses (i.e., non-DNS name > resolution systems) and if so, who will operate that registry. > 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. > > FWIW, my views: > > 1) Ask the stupid question.
Again? It has already been answered many times in the negative. There are even RFCs about it. Asking it again is a waste of people's time. > 2) A voluntary, lightweight registry operated by IANA can help developers > avoid collision. True, if we care about collision in namespaces we don't control. I certainly don't care about those namespaces. > 3) Identifying leakage to the DNS as a protocol violation can, over time, > help reduce that leakage. True, but so what? It is leakage from namespaces we don't control, and many/most of us don't care about them. > >> 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. I'm personally happy to defer this to those volunteers instead of speaking for them. In the past, they have said that the amount of leakage is not of concern to them, and there is no indication that .alt will increase it perceptibly. > 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. I can't tell from this paragraph if you realize that the example you gave (.local) already has a SHOULD NOT for resolvers. Are you saying that updating RFC 6762 to make it a MUST NOT would have any noticeable effect? > 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. Can you say what you mean by "reliance on the DNS"? Defining .alt as a name that won't appear in the root zone does not have any reliance on the DNS. >> 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. Why on earth would those users think that? If the proponents of the non-DNS name resolution protocol suggest that to them, then those proponents are simply lying. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
