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.