Re: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative
Paul Ebersman <list-dns-privacy@dragon.net> Sat, 08 August 2020 22:09 UTC
Return-Path: <list-dns-privacy@dragon.net>
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 1CBCD3A08E6 for <dns-privacy@ietfa.amsl.com>; Sat, 8 Aug 2020 15:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 dl3FRV1FFhRT for <dns-privacy@ietfa.amsl.com>; Sat, 8 Aug 2020 15:09:39 -0700 (PDT)
Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:1:2000::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC083A0826 for <dns-privacy@ietf.org>; Sat, 8 Aug 2020 15:09:39 -0700 (PDT)
Received: from fafnir.remote.dragon.net (ip6-localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 8FD6A7A11A1 for <dns-privacy@ietf.org>; Sat, 8 Aug 2020 15:09:39 -0700 (PDT)
Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 5D78891DC2E; Sat, 8 Aug 2020 16:09:39 -0600 (MDT)
Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 5A63A91DC2D for <dns-privacy@ietf.org>; Sat, 8 Aug 2020 16:09:39 -0600 (MDT)
From: Paul Ebersman <list-dns-privacy@dragon.net>
To: dns-privacy@ietf.org
In-reply-to: <9856A472-1148-429A-844E-D561A1C808EB@develooper.com>
References: <3BA75997-3DE4-4DF5-B1F5-C57DBC423288@icann.org> <17f6e4fd-e545-267f-f29e-01d5fb57d017@innovationslab.net> <9856A472-1148-429A-844E-D561A1C808EB@develooper.com>
Comments: In-reply-to Ask Bjørn Hansen <ask@develooper.com> message dated "Sat, 08 Aug 2020 14:54:29 -0700."
X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10692.1596924579.1@fafnir.local>
Date: Sat, 08 Aug 2020 16:09:39 -0600
Message-Id: <20200808220939.5D78891DC2E@fafnir.remote.dragon.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/KQNxm3PsYzbg-CRl-JPBp3aDIgE>
Subject: Re: [dns-privacy] Possible use case: Opportunistic encryption for recursive to authoritative
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: Sat, 08 Aug 2020 22:09:41 -0000
ask> I don't have data (and haven't looked into it recently), but I think ask> it's a very safe assumption that ask> - most of the authoritative servers don't use anycast ask> - most authoritative queries (for an average resolver) go to ask> servers that use anycast I'd disagree. There's been huge consolidation in the DNS operator business and the vast majority of domain names are served by a fairly small number of really large operators' auth servers. Anycast for auth makes sense for robustness and resilience while not inflating the number of listed NSs (keeping packet size small). Combine that with most of the world using a smaller number of recursive operators who also widely distibute via anycast and you wind up with auth and recursive operators being in most of the same cities and data centers and close to each other. This means cache misses aren't that much slower than cache hits. Clients get fast answers, zones are robustly and quickly served, everyone wins. Whether centralization as a trend is good has already been argued on this list and others plenty of times. ;) There is definitely a choice or tradeoff between speed/robustness and privacy.
- [dns-privacy] Possible use case: Opportunistic en… Paul Hoffman
- Re: [dns-privacy] Possible use case: Opportunisti… Ben Schwartz
- Re: [dns-privacy] [Ext] Possible use case: Opport… Paul Hoffman
- Re: [dns-privacy] Possible use case: Opportunisti… John R. Levine
- Re: [dns-privacy] Possible use case: Opportunisti… Tim Wicinski
- Re: [dns-privacy] Possible use case: Opportunisti… Puneet Sood
- Re: [dns-privacy] Possible use case: Opportunisti… Rob Sayre
- Re: [dns-privacy] Possible use case: Opportunisti… Puneet Sood
- Re: [dns-privacy] Possible use case: Opportunisti… Rob Sayre
- Re: [dns-privacy] Possible use case: Opportunisti… Manu Bretelle
- Re: [dns-privacy] Possible use case: Opportunisti… John Levine
- Re: [dns-privacy] Possible use case: Opportunisti… Rob Sayre
- Re: [dns-privacy] Possible use case: Opportunisti… Paul Wouters
- Re: [dns-privacy] Possible use case: Opportunisti… Brian Haberman
- Re: [dns-privacy] Possible use case: Opportunisti… Ask Bjørn Hansen
- Re: [dns-privacy] Possible use case: Opportunisti… Paul Ebersman
- Re: [dns-privacy] [Ext] Possible use case: Opport… Paul Hoffman
- Re: [dns-privacy] Possible use case: Opportunisti… Peter van Dijk
- Re: [dns-privacy] Possible use case: Opportunisti… Peter van Dijk
- Re: [dns-privacy] [Ext] Possible use case: Opport… Brian Haberman
- Re: [dns-privacy] Possible use case: Opportunisti… Tony Finch
- Re: [dns-privacy] Possible use case: Opportunisti… Paul Wouters
- [dns-privacy] TLSA for secure resolver-auth trans… Peter van Dijk
- Re: [dns-privacy] Possible use case: Opportunisti… Vladimír Čunát
- Re: [dns-privacy] [Ext] Possible use case: Opport… Paul Hoffman
- Re: [dns-privacy] TLSA for secure resolver-auth t… Ilari Liusvaara
- Re: [dns-privacy] TLSA for secure resolver-auth t… Paul Wouters
- Re: [dns-privacy] [Ext] TLSA for secure resolver-… Paul Hoffman
- Re: [dns-privacy] TLSA for secure resolver-auth t… Vladimír Čunát
- Re: [dns-privacy] TLSA for secure resolver-auth t… Paul Wouters
- Re: [dns-privacy] Possible use case: Opportunisti… Viktor Dukhovni
- Re: [dns-privacy] TLSA for secure resolver-auth t… Peter van Dijk