Re: [dns-privacy] [EXTERNAL] Re: Trying to understand DNS resolver 'discovery'
Phillip Hallam-Baker <ietf@hallambaker.com> Tue, 03 December 2019 19:59 UTC
Return-Path: <hallam@gmail.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 80C0E12002F for <dns-privacy@ietfa.amsl.com>; Tue, 3 Dec 2019 11:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.471
X-Spam-Level:
X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.073, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 YmYNB1i3UAwK for <dns-privacy@ietfa.amsl.com>; Tue, 3 Dec 2019 11:59:17 -0800 (PST)
Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD8D12004C for <dns-privacy@ietf.org>; Tue, 3 Dec 2019 11:59:17 -0800 (PST)
Received: by mail-oi1-f182.google.com with SMTP id x195so4527803oix.4 for <dns-privacy@ietf.org>; Tue, 03 Dec 2019 11:59:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WMm3V/9alnnP3vGZU4HFb0lU3RswnSiQSNt/uVgjlAc=; b=pCCqZwpA9Feh6FwMAFYwzLjgfPVKzJLyQt4IbbmXKgR2zE0Ne5Hej9ApizoC2UrtRt TXdEO5ImF2gnrMzXnv8HHfcv+jnq7vvatxNRgPGHNaOn0mLjTIVVr2rTxMlpWPWvRISy koT9DPFBohaXVS9XetWKxEsZDDTuAKrA6CXRs1ODMkSTXIdw1A2pvOhOTvW5DFY+zsZl C9ToTpDYffnyIjgB1xINg9Iff/6EWVTBQrk3O85wk1Pz45ACIrIK2dx49SxVqCQr6zpY KRHjKCjmaI81vvkaE+uTVPhb5o8ugJPXKWq5NZ7QxaPF0h8pYuwH+AoIuuKrltwkq+VU 0xrg==
X-Gm-Message-State: APjAAAWVgdwA9cwP7dvuaENMwDDKVn6OqRH9fIVSbaP43RFhrrkdyhN2 1+T8CpmUQejwT4OqJW2eiHAK9S68laupfTmcD+JzXg==
X-Google-Smtp-Source: APXvYqw8WFuMSsH1SSEp2n0S6xp5DRpfpR3ywZ/hiyNDkO8/UPUkhqGF4v6gSRdvB8QXC5ZJ/iRxBfd///jasMFylWE=
X-Received: by 2002:aca:7583:: with SMTP id q125mr5476706oic.100.1575403156185; Tue, 03 Dec 2019 11:59:16 -0800 (PST)
MIME-Version: 1.0
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> <480149195.32229.1575288229166@appsuite-gw1.open-xchange.com> <D205CCCE-DF07-460F-B1EB-D8419E4C7AF5@sky.uk>
In-Reply-To: <D205CCCE-DF07-460F-B1EB-D8419E4C7AF5@sky.uk>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
Date: Tue, 03 Dec 2019 14:59:06 -0500
Message-ID: <CAMm+Lwh6SW2EPdMu44U8mzjNa+pkb075trYPgAx29uryTVQdOA@mail.gmail.com>
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000080a68b0598d2218a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/-Mdw5G3CRHD6QCjrKsVSUcR_4Rs>
Subject: Re: [dns-privacy] [EXTERNAL] Re: 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: Tue, 03 Dec 2019 19:59:19 -0000
This business of proxy chains. It seems like it is insoluble. We faced the same problem when we were trying to deal with spam. There is a huge amount of complexity there. I have been thinking about this problem for the past week and I think I have come up with the answer: None of it matters. To explain, if Alice decides to use DavesDNS.resolv as her resolution service, that is the end of the matter as far as Alice is concerned. There are two possible types of service Dave might provide: 1) Untrusted: Dave returns full DNSSEC paths for all his answers, Alice checks them. In this case, the source of the data Dave supplies is irrelevant as the source of trust is whatever DNSSEC apex is used for validation. 2) Trusted: Dave returns unsigned records and Alice must trust that Dave obtained the records, processed them etc. in accordance with the agreement between Alice and Dave. The point is that Alice ONLY has a relationship here with Dave. How Dave obtains the records is irrelevant. They can be sent by carrier pigeon for all it matters. The internals of how Alice obtains the information is 'black box'. Within any relay structure, there is always a controller who decides which will be the next relay in turn and unless there is a successful MITM attack (in which case we should want to force the connection to ABORT) the control is always with either the sender or the receiver As far as the Internet protocol is concerned, there is always exactly one hop, the point where the client side hands control over to the service side. And this is always the hop that crosses the narrow waist.
- [dns-privacy] Trying to understand DNS resolver '… Phillip Hallam-Baker
- Re: [dns-privacy] Trying to understand DNS resolv… Brian Dickson
- Re: [dns-privacy] Trying to understand DNS resolv… Stephane Bortzmeyer
- Re: [dns-privacy] Trying to understand DNS resolv… Stephane Bortzmeyer
- Re: [dns-privacy] Trying to understand DNS resolv… Brian Dickson
- Re: [dns-privacy] Trying to understand DNS resolv… Phillip Hallam-Baker
- Re: [dns-privacy] Trying to understand DNS resolv… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] Trying to understand DNS resolv… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] Trying to understand DNS resolv… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] Trying to understand DNS resolv… Neil Cook
- Re: [dns-privacy] Trying to understand DNS resolv… Neil Cook
- Re: [dns-privacy] Trying to understand DNS resolv… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] Trying to understand DNS resolv… Neil Cook
- Re: [dns-privacy] Trying to understand DNS resolv… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] Trying to understand DNS resolv… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] Trying to understand DNS resolv… Stephane Bortzmeyer
- Re: [dns-privacy] Trying to understand DNS resolv… Neil Cook
- Re: [dns-privacy] Trying to understand DNS resolv… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] Trying to understand DNS resolv… Stephane Bortzmeyer
- Re: [dns-privacy] Trying to understand DNS resolv… Neil Cook
- Re: [dns-privacy] Trying to understand DNS resolv… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] Trying to understand DNS resolv… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] [EXTERNAL] Re: Trying to unders… Winfield, Alister
- Re: [dns-privacy] Trying to understand DNS resolv… Livingood, Jason
- Re: [dns-privacy] Trying to understand DNS resolv… Livingood, Jason
- Re: [dns-privacy] Trying to understand DNS resolv… Andrew Campling
- Re: [dns-privacy] Trying to understand DNS resolv… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] Trying to understand DNS resolv… Kenji Baheux
- Re: [dns-privacy] Trying to understand DNS resolv… Livingood, Jason
- Re: [dns-privacy] Trying to understand DNS resolv… Vittorio Bertola
- Re: [dns-privacy] [EXTERNAL] Re: Trying to unders… Winfield, Alister
- Re: [dns-privacy] [EXTERNAL] Re: Trying to unders… Phillip Hallam-Baker