I think this proposal is promising, but I agree with Stephane that the registry of participating resolvers is unappealing. However, I believe it is also unnecessary. Instead, the EXTRA-TEXT can simply convey an "https://" URL for the Incident Description. The client can enforce that this URL's hostname be the same as the one used to reach DNS server, ensuring authenticity.
(A hostname matching rule of this kind was previously proposed in draft-reddy-dnsop-error-page-07 [1]. However, that proposal involved an HTML response, rather than JSON as proposed here.) For clients using insecure DNS, I would probably rule out this mechanism entirely, since the authenticity of the report cannot be established. --Ben Schwartz [1] https://author-tools.ietf.org/iddiff?url1=draft-reddy-dnsop-error-page-06&url2=draft-reddy-dnsop-error-page-07&difftype=--html ________________________________ From: Stephane Bortzmeyer <bortzmeyer=40nic...@dmarc.ietf.org> Sent: Wednesday, November 6, 2024 3:40 AM To: Mark Nottingham <mnot=40mnot....@dmarc.ietf.org> Cc: dnsop@ietf.org <dnsop@ietf.org> Subject: [DNSOP] Re: Fwd: New Version Notification for draft-nottingham-public-resolver-errors-00.txt On Tue, Nov 05, 2024 at 10:26:44AM +0000, Mark Nottingham <mnot=40mnot....@dmarc.ietf.org> wrote a message of 170 lines which said: > Public DNS resolvers (such as 1.1.1.1, 8.8.8.8, and others) are > increasingly subject to requirements to censor responses flowing > through them. When this happens, it's important to be transparent to > end users. The mechanism in this draft is intended to allow that in > a way that addresses the concerns that browser engineers have about > security and user experience. Strong no from me. 1) We already have a mechanism to report this censorship. The security argument is not convincing since you know your resolver, you choosed it and you have to trust it, anyway. 2) The entire idea of a registry of public resolvers open so many issues that I cannot count them. Specially the mention that IANA can reject some of them (on which grounds?) 3) The problem of censorship information is no specific to public resolvers. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org