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

On Thu, Nov 28, 2019 at 8:05 PM Konda, Tirumaleswar Reddy <
TirumaleswarReddy_Konda@mcafee.com> wrote:

> In addition, with the extended error codes defined in
> https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-08, 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 <dns-privacy-bounces@ietf.org> *On Behalf Of *Andrew
> Campling
> *Sent:* Thursday, November 28, 2019 3:39 AM
> *To:* Livingood, Jason <Jason_Livingood@comcast.com>; Stephane Bortzmeyer
> <bortzmeyer@nic.fr>; dns-privacy@ietf.org
> *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 <Jason_Livingood@comcast.com>
> Sent: 27 November 2019 16:06
> To: Stephane Bortzmeyer <bortzmeyer@nic.fr>; dns-privacy@ietf.org
> Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
>
>
>
> On 11/27/19, 9:29 AM, "dns-privacy on behalf of Stephane Bortzmeyer" <dns-privacy-bounces@ietf.org
> on behalf of bortzmeyer@nic.fr> 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
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

-- 
Kenji BAHEUX
Product Manager - Chrome
Google Japan