Re: [DNSOP] reservations on reservations, was Barry Leiba's Abstain
Mark Andrews <marka@isc.org> Tue, 01 September 2015 22:28 UTC
Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866711B4BAB for <dnsop@ietfa.amsl.com>; Tue, 1 Sep 2015 15:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 NvTPaKrLK3hz for <dnsop@ietfa.amsl.com>; Tue, 1 Sep 2015 15:28:21 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1584B1B478B for <dnsop@ietf.org>; Tue, 1 Sep 2015 15:28:20 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.ams1.isc.org (Postfix) with ESMTPS id 95FB21FCC3C; Tue, 1 Sep 2015 22:28:16 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7FD6E16003D; Tue, 1 Sep 2015 22:29:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 55CD81600AE; Tue, 1 Sep 2015 22:29:36 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id d70UpPN5BC5G; Tue, 1 Sep 2015 22:29:36 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id E0A7416003D; Tue, 1 Sep 2015 22:29:35 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7AA1D36A0F75; Wed, 2 Sep 2015 08:28:10 +1000 (EST)
To: Joe Abley <jabley@hopcount.ca>
From: Mark Andrews <marka@isc.org>
References: <20150901143500.63585.qmail@ary.lan> <7A6FBF85-A86B-46F1-B4EC-C015AEE598C9@difference.com.au> <alpine.OSX.2.11.1509011137110.13159@ary.lan> <CAFggDF2wrCK6ANLKTGuuK4M4VcyO9X+YEd4fgv15pf_jkP+JvA@mail.gmail.com> <CA40D404-C43B-4BF4-8F66-E6DD755286EE@hopcount.ca>
In-reply-to: Your message of "Tue, 01 Sep 2015 13:27:19 -0400." <CA40D404-C43B-4BF4-8F66-E6DD755286EE@hopcount.ca>
Date: Wed, 02 Sep 2015 08:28:10 +1000
Message-Id: <20150901222810.7AA1D36A0F75@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/E8Pp0eev-v7-3Pz_ukmBVIQFUMA>
Cc: John R Levine <johnl@taugh.com>, dnsop@ietf.org, David Cake <dave@difference.com.au>, Jacob Appelbaum <jacob@appelbaum.net>
Subject: Re: [DNSOP] reservations on reservations, was Barry Leiba's Abstain
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2015 22:28:22 -0000
In message <CA40D404-C43B-4BF4-8F66-E6DD755286EE@hopcount.ca>, "Joe Abley" writ es: > > > On 1 Sep 2015, at 11:45, Jacob Appelbaum wrote: > > > In my view and the DNS has a critical flaw: it does not provide query > > privacy. > > You're on the wrong list. The people working on DNS privacy are over at > DPRIVE. For the problem statement, see RFC 7626, recently published. DPRIVE are looking at stub to recursive resolver privacy. This is recursive resolver to root server privacy which is off charter for DPRIVE. Now there are two ways to solve this as the root is signed. 1. Recommend *every* recursive server holds a copy of the root zone. This has implications for ICANN and how many TLD's they can sell as the root zone would need to remain relatively small. This also helps with other leakage to the root zone. 2. Insecurely delegate .onion and recommend that every resolver synthesis a NXDOMAIN response. This also has implication for ICANN as they don't have procedures to do this sort of delegation. 3. Hope that QNAME minimisation gets deployed to all stub resolvers. 2 and 3 both leak that a onion name is being looked up but not what that name is. > Joe > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- [DNSOP] Barry Leiba's Abstain on draft-ietf-dnsop… Barry Leiba
- Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-d… Stephen Farrell
- Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-d… Barry Leiba
- Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-d… joel jaeggli
- Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-d… Barry Leiba
- Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-d… Patrik Fältström
- Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-d… joel jaeggli
- Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-d… Andrew Sullivan
- Re: [DNSOP] reservations on reservations, was Bar… John Levine
- Re: [DNSOP] reservations on reservations, was Bar… David Cake
- Re: [DNSOP] reservations on reservations, was Bar… John R Levine
- Re: [DNSOP] reservations on reservations, was Bar… David Cake
- Re: [DNSOP] reservations on reservations, was Bar… John Levine
- Re: [DNSOP] reservations on reservations, was Bar… David Cake
- Re: [DNSOP] reservations on reservations, was Bar… John R Levine
- Re: [DNSOP] reservations on reservations, was Bar… Jacob Appelbaum
- Re: [DNSOP] reservations on reservations, was Bar… Joe Abley
- Re: [DNSOP] a long way from reservations on reser… John R Levine
- Re: [DNSOP] a long way from reservations on reser… Jacob Appelbaum
- Re: [DNSOP] a long way from reservations on reser… John R Levine
- Re: [DNSOP] a long way from reservations on reser… John R Levine
- Re: [DNSOP] reservations on reservations, was Bar… Mark Andrews
- Re: [DNSOP] a long way from reservations on reser… Jacob Appelbaum
- Re: [DNSOP] a long way from reservations on reser… Ted Lemon
- Re: [DNSOP] a long way from reservations on reser… hellekin
- Re: [DNSOP] reservations on reservations, was Bar… Joe Abley
- [DNSOP] DNS privacy, recursive-to-authoritative (… Stephane Bortzmeyer
- Re: [DNSOP] DNS privacy, recursive-to-authoritati… John R Levine
- Re: [DNSOP] DNS privacy, recursive-to-authoritati… Paul Vixie
- Re: [DNSOP] DNS privacy, recursive-to-authoritati… Wessels, Duane
- Re: [DNSOP] DNS privacy, recursive-to-authoritati… Paul Vixie
- Re: [DNSOP] DNS privacy, recursive-to-authoritati… Ian Maddison