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

Tomas Krizek <tomas.krizek@nic.cz> Thu, 01 April 2021 09:59 UTC

Return-Path: <tomas.krizek@nic.cz>
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 BCD2C3A1337 for <dns-privacy@ietfa.amsl.com>; Thu, 1 Apr 2021 02:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OArzZs_Myldl for <dns-privacy@ietfa.amsl.com>; Thu, 1 Apr 2021 02:59:44 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32983A1335 for <dprive@ietf.org>; Thu, 1 Apr 2021 02:59:43 -0700 (PDT)
Received: from [192.168.42.125] (ip-89-176-146-75.net.upcbroadband.cz [89.176.146.75]) by mail.nic.cz (Postfix) with ESMTPSA id 1D4DB13FFA5; Thu, 1 Apr 2021 11:59:36 +0200 (CEST)
To: Rob Sayre <sayrer@gmail.com>, Bill Woodcock <woody@pch.net>
Cc: "dprive@ietf.org" <dprive@ietf.org>
References: <c925da9089fa4b1e991ec74fc9c11e7f@verisign.com> <CAChr6Sxwao=FAcoeHMuOf0L=JCZ+wvhsr9BNZW_dbt+1=HWQwg@mail.gmail.com> <20210331091238.GA10597@nic.fr> <CAChr6SxPNVAZMYfZqF+K6Xf8FPGa9ZgHkL-uUvtKMEiJSPmp8Q@mail.gmail.com> <2607D274-936F-4A31-9E4D-EEBCF45BE838@pch.net> <CAChr6Szg+EbFqSpFPco8Gyb9pzNNnrSoQJcXTDVeg40_EXiPDg@mail.gmail.com> <4B1CCB51-C777-4434-B28E-76C22C12E4DA@pch.net> <CAChr6Sym=tm-vj-3FB-GbOG6U=U4CFsRE6yyWJk14waZQLbRiQ@mail.gmail.com>
From: Tomas Krizek <tomas.krizek@nic.cz>
Message-ID: <62d91128-6ef7-1a92-1ac8-f67e6af90583@nic.cz>
Date: Thu, 1 Apr 2021 11:59:26 +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: <CAChr6Sym=tm-vj-3FB-GbOG6U=U4CFsRE6yyWJk14waZQLbRiQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lB6zL8IbUb073TqLFmJeBf32Pm6OixpXU"
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/Fyusyw7Z2IJPhLA7PeB2eYLKiZ8>
Subject: Re: [dns-privacy] Root Server Operators Statement on DNS Encryption
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: Thu, 01 Apr 2021 09:59:49 -0000

On 31/03/2021 23.28, Rob Sayre wrote:
> On Wed, Mar 31, 2021 at 2:16 PM Bill Woodcock <woody@pch.net> 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]

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] - https://indico.dns-oarc.net/event/34/contributions/782/
[2] -
https://dns-shotgun.readthedocs.io/en/stable/replaying-traffic/#emulating-link-latency
[3] - https://dns-shotgun.readthedocs.io/en/stable/latency-histogram/

-- 
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869