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

["Livingood, Jason" <[e-mail]>]

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

Jason

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



On Thu, Nov 28, 2019 at 8:05 PM Konda, Tirumaleswar Reddy <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Andrew Campling
Sent: Thursday, November 28, 2019 3:39 AM
To: Livingood, Jason <[e-mail]<mailto:[e-mail]>>; Stephane Bortzmeyer <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Sent: 27 November 2019 16:06
To: Stephane Bortzmeyer <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

On 11/27/19, 9:29 AM, "dns-privacy on behalf of Stephane Bortzmeyer" <[e-mail] on behalf of [e-mail]<mailto:[e-mail][e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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