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

Reply via email to