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

Petr Špaček <> Thu, 01 April 2021 12:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 867773A0CBD for <>; Thu, 1 Apr 2021 05:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=Yc4BLoSI; dkim=pass (1024-bit key) header.b=TO/54Xf9
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6CSZ4ni-Ibdx for <>; Thu, 1 Apr 2021 05:04:38 -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 5075F3A0CBA for <>; Thu, 1 Apr 2021 05:04:38 -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 6C4C13AB020; Thu, 1 Apr 2021 12:04:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=ostpay; t=1617278676; bh=MHQh7jpPw1ouqdrWdjFkaC00Kgc5i5cdfN1t3gzDCKw=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=Yc4BLoSI5dpHKnl/izp4JDKL3YmJ0egkK8kgEm0TyI1MTJskIUxLI32Mu/6H+/YZH GMgCD4eycli9dDxl//x+09Ckq94nlMe5wTU3Sb7o+fApyfhiYTrZFVfw7USMhClHbi BkyMgVsSAwfU/D/uwRUc2iWBVJqz8UutesMefS3o=
Received: from (localhost []) by (Postfix) with ESMTPS id 39929160047; Thu, 1 Apr 2021 12:04:36 +0000 (UTC)
Received: from localhost (localhost []) by (Postfix) with ESMTP id F15191600AA; Thu, 1 Apr 2021 12:04:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 F15191600AA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1617278676; bh=pAL4FH2G4+fWNamyg+ZhmKRu38rsp5nnvG7IAnufCdw=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=TO/54Xf9s6fn2fJwZM1MCjwLipTAWiROnALpxn0UqCG9I06Cd/VENcYluKVU+uDKL QOUdzqZnEFFg2iaxxrAnFzpvnzRFfffE182u0wK+G9QiG4J1J7L1rvbJmP4KyO1Utk +u6tX71Ry6attharekp8APmCKFgqSl+bBkJHN2NE=
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id CHQW6LABQKLD; Thu, 1 Apr 2021 12:04:35 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPSA id 7A079160047; Thu, 1 Apr 2021 12:04:34 +0000 (UTC)
To: Tomas Krizek <>, Rob Sayre <>, Bill Woodcock <>
Cc: "" <>
References: <> <> <> <> <> <> <> <> <>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <>
Message-ID: <>
Date: Thu, 1 Apr 2021 14:04:31 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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 12:04:44 -0000

On 01. 04. 21 11:59, Tomas Krizek wrote:
> On 31/03/2021 23.28, Rob Sayre wrote:
>> On Wed, Mar 31, 2021 at 2:16 PM Bill Woodcock <> wrote:
>>> …and it’s measuring latency rather than server-side load.  I just checked
>>> with our engineers, and it sounds like the server load per-query is more
>>> like 3x-5x higher for the encrypted queries.
>> Plenty of folks have evaluated the costs here. I'd prefer to discuss data
>> rather than "checking with engineers". It's not really reasonable to
>> measure "server load per-query" without a bunch of other data on how the
>> TLS sessions are being created and maintained.
>> So, if you have some data you'd like to share with the list, that would
> be
>> most welcome.
> We've done some measurements comparing the server-load overhead of DoT
> and DoH and while the exact results vary greatly with the client
> behaviour, connection management and other parameters, I think 3x-5x
> server-load overhead (compared to UDP) is a reasonable expectation. [1]

I will add couple more details about these measurements:

Data show that TLS algorithms in use *and* connection reuse parameters 
are crucial. Well-behaved clients over DoT with P256 certificate can be 
"only" ~ 2.9 x more expensive (on server) than plain UDP, thanks to the 
fact that TCP+TLS connection setup costs get amortized for longer 

For well-behaved clients who do not keep idle connections open the cost 
jumps up to 10x.

To generalize for the root server scenario, we need to consider that a 
particular well-behaved client should contact root servers rarely, which 
means that connection reuse is unlikely. For this reason, I believe that 
costs on the server side are likely to be closer to the 10x mark for CPU 

There are limitations to this measurement and generalization, however:
- Measured on stub<->recursive so the generalization might not apply, 
especially if recursive<->root has much better connection reuse 
conditions (seems extremely unlikely to me)
- No information about bandwidth
- No information about latency
- No information about memory consumption
- No information about DoS potential - we measured well-behaved clients

Petr Špaček  @  ISC

> Our measurements were for resolvers, but the same methodology and tool
> could also used for authoritative server measurements.
>  From latency point of view, it again depends on connection management
> etc., but inevitably, some queries will have the additional cost of
> establishing a TCP/TLS handshake. If anyone's interested in measuring
> the impact in various network conditions, it's possible to simulate
> latency with kernels' Network Emulator [2]. When we've tried that, the
> results looked as I've described [3], but the exact outcome depends on
> many variables.
> [1] -
> [2] -
> [3] -