IETF Logo Mail Archive

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

Vittorio Bertola <vittorio.bertola@open-xchange.com> Mon, 02 December 2019 12:03 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036DD120255 for <dns-privacy@ietfa.amsl.com>; Mon, 2 Dec 2019 04:03:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwDviMYvfkoF for <dns-privacy@ietfa.amsl.com>; Mon, 2 Dec 2019 04:03:52 -0800 (PST)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08476120043 for <dns-privacy@ietf.org>; Mon, 2 Dec 2019 04:03:52 -0800 (PST)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 4CA476A241; Mon, 2 Dec 2019 13:03:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1575288229; bh=8LvQE/VaBgKTD5/Gp/xRoDuk/L9mKNuy+yaOB2nx+iM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=Jc4+DU24hoHRI63lFZfNgbr2KzQIeTV/1Ngy6HxFpmlaJK+r7te9dZIJTlkq0tvi9 jWLu2sS3DHe/XkPXx2FnRifkMLxVXR4Ba25Vg99XZ6tzleaff/Z1jzkLuuOtIIIwff xZtE5N3OP0mU2v8TDbhNehqWtGR0jdnojrKthbtgaarJUloAnMKMWh1xx1CZkOEQlf KRDPF+BbUWZeJT+K8rE7EexSpNUDLmHBCc6QIbNbx4cGpmeLENzcisDZMRlRxNtd+P avCmAn0mmJb6cB+QT64L54+NSy070pkXUVwDvi9f+DuMbfJ0ZZbpoLGJaqPTukYwAN WuZmefh9jvy+A==
Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 3F7FE3C00AB; Mon, 2 Dec 2019 13:03:49 +0100 (CET)
Date: Mon, 02 Dec 2019 13:03:49 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
Reply-To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Kenji Baheux <kenjibaheux=40google.com@dmarc.ietf.org>, "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Message-ID: <480149195.32229.1575288229166@appsuite-gw1.open-xchange.com>
In-Reply-To: <CADWWn7WavXNU0jN_dKTjHGyhGoe+UDPxVF0NACJHRitCdvM=2A@mail.gmail.com>
References: <CAMm+Lwig+90Riqav6BT6D-0n4pZJFgAr3p996Q+qXJSPt0kqBQ@mail.gmail.com> <20191126180441.GA4452@sources.org> <CY4PR1601MB125470ADE243F60FB710E8C7EA440@CY4PR1601MB1254.namprd16.prod.outlook.com> <20191127142842.GA18601@nic.fr> <716ED073-F71D-412C-A54B-D060DDC6F469@cable.comcast.com> <LO2P265MB05736FAB2D38226EB21D9C72C2440@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <CY4PR1601MB1254A759EC4EA55D3B11603EEA470@CY4PR1601MB1254.namprd16.prod.outlook.com> <CADWWn7WavXNU0jN_dKTjHGyhGoe+UDPxVF0NACJHRitCdvM=2A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.2-Rev17
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/QmQ9x-JMzIPwCZ-dtp-HlSLQ4Qw>
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2019 12:03:54 -0000


Il 29 novembre 2019 01:40 Kenji Baheux <kenjibaheux=40google.com@dmarc.ietf.org> ha scritto:




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" rel="noopener nofollow"> 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.
I was the one that asked for the addition to the draft of a specific error code for "filtered per user request", because I wholeheartedly share the view that the UX of current DNS filtering platforms, especially when applied to HTTPS destinations, is terrible and lacks the transparency, security and information necessary to reassure the user that this is indeed what was intended to happen and explain why. It would be great if we could find reliable ways to redirect the user to an explanation/configuration page without the need to circumvent or forge the HTTPS connection, while authenticating the origin of the DNS modification and of the message, and as a DNS vendor we would be happy to cooperate on that.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

v2.23.0 | Report a Bug | By Email