Re: [dns-privacy] Root Server Operators Statement on DNS Encryption

Christian Huitema <> Thu, 01 April 2021 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F1103A1A22 for <>; Thu, 1 Apr 2021 09:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SsGwxZ3INJUD for <>; Thu, 1 Apr 2021 09:10:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 248143A1A20 for <>; Thu, 1 Apr 2021 09:10:17 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1lRztT-000cIJ-Th for; Thu, 01 Apr 2021 18:10:12 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4FB7Pn3LT5zDV7 for <>; Thu, 1 Apr 2021 09:07:57 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1lRzrR-0003st-B5 for; Thu, 01 Apr 2021 09:07:57 -0700
Received: (qmail 24065 invoked from network); 1 Apr 2021 16:07:56 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 1 Apr 2021 16:07:55 -0000
Content-Type: multipart/alternative; boundary=Apple-Mail-49391A99-1C27-454E-A1D9-59866591D272
Content-Transfer-Encoding: 7bit
From: Christian Huitema <>
Mime-Version: 1.0 (1.0)
Date: Thu, 1 Apr 2021 09:07:53 -0700
Message-Id: <>
References: <>
Cc: Bill Woodcock <>,
In-Reply-To: <>
To: Rob Sayre <>
X-Mailer: iPhone Mail (18D70)
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.09)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8+1OEXxmP1pMeCwIZMuaO6PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wwIbsUgx3VwKj5vUcMDcmx42UuDhyzVYcwl2RB+0AaehOd 0aosil+oBHyM8/iyExwh55uqY3MhMgFAHq5BxPxPXn36fLqvhISQ5ykyqUZqUd1jhnM/Mbva2XLV /LIEzaL2KoAZhJekBPedneT7f69902tJZdbQQpVL7A8ejel8VYPAgTtUp75uqlx0KezvZHWhWQ59 Qnb1f8O4K9KHPb6BWQaaSSaRcFTFxaRvADgOuME95bF8tPKjnaWlQ6fjTEeg4CZvTGBeutAohO1y UnDCBSl7YrgCdzbaCwJPCCSougyg4uMaxHP8xQTpohmgJxQ1dHhpUbi1UdTVmV3LL7N9ueszlpij Q8vuNSxljixs9l2PHznFCr1UPjZRtNG50GjfX8TdqEXkwxwMjsp2mNAp23iZ8TJTdK5H0dgUOB1h 85nckpWaLvahyBjmQxBKOzuhP7r/qeCcLfNPkwm2lNnsvr3LBR8rUYXJ4jh62pfHaKqsknzQ1WVE SSlbgJ6e928BIkUL/j1Y48GvmeURQjjEUQSKZxezeBn5RwWu6r/w45PeIpKhJOzX4iNThkv5lg2W XS7qQg+rIP0bVlbPHosLHF29j8cA+VxmrdV21v79MGf6J5LiDZAgJQy4WAGaMLIqM56VVlcswDb0 N8Su4voNiwQzKw+6v3CaIMG6s7LqJBCaMRDkZnsRHpLqxJJvOSqp0srCGhqQVLm3YuZYsovT1rXi QzPaQyrOeMWsLnuUEzffEfy09CPckxnwlSeLj9H5d9Mpny2MqlrXcMQyNtV/Quxl82/BqKlV/DIv /0xiQcOpyKA69LF1Ge2GaGfxmfrJyhoTyYjBAsgJ9fPu1C1rkwISTdKXHHyl1YNiB/Uix7CYwtBS QxO5224/0gCm1v3y3deP8vNnmz84mDUvZqxnoc7bV0+nE+EwV843xuls19yArgxzoa+KPg4iBZtv Ir6fmwij1JB2C+QdO3OG/whb
Archived-At: <>
Subject: Re: [dns-privacy] Root Server Operators Statement on DNS Encryption
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Apr 2021 16:10:23 -0000

> On Mar 31, 2021, at 10:51 PM, Rob Sayre <> wrote:
> On Wed, Mar 31, 2021 at 10:43 PM Christian Huitema <> wrote:
>> I think that's the big motivation behind DoQ. Because QUIC runs over UDP, it makes some things easier than TCP. In particular, I have seen (and done) demos of supporting 50,000 QUIC connections over a single UDP socket, which is definitely easier on the system than trying to support parallel wait on 50,000 TCP sockets. But this is a motivation to do work on the subject, not a recommendation to change the way root servers operate. I personally agree with the statement that root servers should not rush to implement, but rather wait and see until the technology matures.
> I don't know... shouldn't they start work now?
> I wonder if root server capex costs have gone down 41% since this post:

I am aware of that. In fact, I jokingly tried to attract attention on this Chrome issue in the pechakucha session during IETF meeting in Singapore in 2019. 

This issue is one of many faced by the root. I am happy to see it solved, but there are many more like that. For example, if resolvers did adopt aggressive NSEC caching, their traffic would drop by an order of magnitude. But then, even if they did that, there would still be lot of demand on the root from other sources, such as resolvers running old software or operations that generate traffic as part of a variety of scans or spider processes. So yes, the root is special.

-- Christian Huitema