Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 29 Nov 2019 13:46:40 +0000

I was not aware of the error code draft – seems like a great idea!

Jason

From: Kenji Baheux <[email-masked]>
Date: Thursday, November 28, 2019 at 7:41 PM
To: "Konda, Tirumaleswar Reddy" <[email-masked]>
Cc: Andrew Campling <[email-masked]>, "Livingood, Jason" <[email-masked]>, Stephane Bortzmeyer <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

On Thu, Nov 28, 2019 at 8:05 PM Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
In addition, with the extended error codes defined in https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-08<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-dnsop-extended-error-08__;!rx_L75ITgOQ!Vv9arb-84qRPL_HZNwsjOJMHqbm5VUHarDC9sqa3OZ1zo4mKZ9DgGRQJphmIJ3F9QQaDUg$>, client would know the reason for blocking access to a domain, solves the user experience problem and, DoT/DoH ensures the error response is not spoofed.

Spot on.

A big part of the problem is that the DNS modifications for legit use cases or legal reasons are done in a non-transparent way, with potential security/privacy side-effects (e.g. application left in the dark, forced custom page), and without strong guarantees that this was indeed the original intent. That said, I understand the need for ISP or service operators to explain what happened to the user and how to act on it (e.g. request whitelisting in a parental control situation).

So, I'd love to hear feedback from ISPs in particular, on the extended DNS error draft in conjunction with DoH.
An alternative would be to use/repurpose HTTP status code such as 451 or 450 in DoH, and also define something for the explanation needs.

-Tiru

From: dns-privacy <[email-masked]<mailto:[email-masked]>> On Behalf Of Andrew Campling
Sent: Thursday, November 28, 2019 3:39 AM
To: Livingood, Jason <[email-masked]<mailto:[email-masked]>>; Stephane Bortzmeyer <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
+1 to Jason's comment - suggesting all DNS modification is bad indicates a misunderstanding of some real-world use cases.

Andrew

-----Original Message-----
From: Livingood, Jason <[email-masked]<mailto:[email-masked]>>
Sent: 27 November 2019 16:06
To: Stephane Bortzmeyer <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

On 11/27/19, 9:29 AM, "dns-privacy on behalf of Stephane Bortzmeyer" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

>    For instance, if your access provider has a lying resolver

I just wanted to take a moment to note that choosing to use the term 'lying' when describing resolver behavior is unnecessarily negative and seems designed to be intentionally divisive. This does not IMO contribute to a productive discussion and exchange of views at the IETF.

As has been long demonstrated here and in DNSOP, not all DNS modification can be considered 'lying' - given that lying obviously implies it is a negative thing that is counter to user preferences. For example, an opt-in parental control service that modifies responses is not a negative use case from the perspective of that user/parent. Similarly, a DNS modification in an enterprise that blocks malware C2 FQDNs is also from the enterprise's perspective a good thing.

It seems a better approach is to simply use a neutral term and call this DNS modification. Whether that is good or bad will depend on the particular use case or situation or other factors.

Thanks
Jason

_______________________________________________
dns-privacy mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dns-privacy<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dns-privacy__;!rx_L75ITgOQ!Vv9arb-84qRPL_HZNwsjOJMHqbm5VUHarDC9sqa3OZ1zo4mKZ9DgGRQJphmIJ3GY77Abgg$>

--
Kenji BAHEUX
Product Manager - Chrome
Google Japan