I was not aware of the error code draft – seems like a great idea! Jason
From: Kenji Baheux <[email protected]> Date: Thursday, November 28, 2019 at 7:41 PM To: "Konda, Tirumaleswar Reddy" <[email protected]> Cc: Andrew Campling <[email protected]>, "Livingood, Jason" <[email protected]>, Stephane Bortzmeyer <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [dns-privacy] Trying to understand DNS resolver 'discovery' On Thu, Nov 28, 2019 at 8:05 PM Konda, Tirumaleswar Reddy <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> On Behalf Of Andrew Campling Sent: Thursday, November 28, 2019 3:39 AM To: Livingood, Jason <[email protected]<mailto:[email protected]>>; Stephane Bortzmeyer <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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 protected]<mailto:[email protected]>> Sent: 27 November 2019 16:06 To: Stephane Bortzmeyer <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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 protected] on behalf of [email protected]<mailto:[email protected]%20on%20behalf%20of%[email protected]>> 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 protected]<mailto:[email protected]> 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
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
