Paul, On Oct 23, 2022, at 1:27 PM, Paul Hoffman <paul.hoff...@icann.org> wrote: >> 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.
I’m unaware. Could you point me to the ICANN Board resolution, statement from the GNSO, and/or a position from the ICANN CEO on the issue? >> 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. OK, but others may. As a precedent: https://www.iana.org/time-zones <https://www.iana.org/time-zones>. >> 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. I would’ve thought we'd care about (and try to discourage) the leakage into the DNS as a result of IETF action. >> 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. OK. Could you point me to the statement by the RSOs on the topic? > 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. Given the root server infrastructure is shared across the entire Internet globally, in the past, the DNS operational community has gone to significant efforts in relation to proposed changes that could conceivably affect the load on the root servers, e.g., deploying IPv6 or DURZ, even when there was no assurance or even a common belief that there would be a perceptible negative impact. But this is somewhat irrelevant: what we’re talking about here is specific wording that tries to more strongly discourage traffic going to the root, i.e., 'MUST NOT’ instead of ‘should not’. I’m confused why such wording would be considered controversial. > I can't tell from this paragraph if you realize that the example you gave > (.local) already has a SHOULD NOT for resolvers. Yep, I’m aware. I don’t think repeating mistakes is a good idea. > Are you saying that updating RFC 6762 to make it a MUST NOT would have any > noticeable effect? Are you saying you think it would hurt? I’m hopeful in the long term, it would have a positive impact. >> 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. For applications that are misconfigured, instead of blocking at the resolver, you appear to be arguing queries should use the DNS protocol to query the root servers to (presumably) return an NXDOMAIN. I consider this a protocol violation, and as such, I think it appropriate to use language that suggests implementors must not do that. >>> 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? E.g., "GNS is a decentralized and censorship-resistant domain name resolution protocol that provides a *privacy-enhancing* alternative to the Domain Name System (DNS) protocols.” (second sentence of the abstract of https://lsd.gnunet.org/lsd0001/ <https://lsd.gnunet.org/lsd0001/>, emphasis added). Now, what happens on a machine that is unaware of GNS responds to (say) an email from paul@secret_name.alt <mailto:paul@secret_name.alt> (and if you don’t think that’s a privacy violation, then what’s the point of DoH/DoT)? > If the proponents of the non-DNS name resolution protocol suggest that to > them, then those proponents are simply lying. Or, more charitably, they are making an assumption about the environment in which the non-DNS name resolution protocol operates. Pointing this out in the Security Considerations section seems like a no-brainer to me. Regards, -drc
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
