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

[John Heidemann <[e-mail]>]

On Thu, 01 Apr 2021 11:59:26 +0200, Tomas Krizek wrote: 
>On 31/03/2021 23.28, Rob Sayre wrote:
>> On Wed, Mar 31, 2021 at 2:16 PM Bill Woodcock <[e-mail]> 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]

We've published results of server-side CPU and memory at

Liang Zhu and John Heidemann.
  LDplayer: DNS Experimentation at Scale.
  In _Proceedings of the ACM Internet Measurement Conference_, Boston, Massachusetts, USA, ACM.
  October, 2018.
  <https://doi.org/10.1145/3278532.3278544>, <https://www.isi.edu/%7ejohnh/PAPERS/Zhu18b.html>.
  
Including replay of root DNS traffic (DITL) with it's current mix of UDP
and TCP and all-TLS.

We found (DNS over) UDP and TLS took about the same CPU on our hardware,
and pure TCP (without TLS) was actually lower CPU than UDP.  See Figure
11 and section 5.2.3 in the paper.

(Our code and data is available if you want to reproduce our experiments
on your hardware.)

IMHO, a bigger operational concern than CPU is actually memory---it's
easy to burn through a lot of RAM with TCP and TLS state---see section
5.2.2 and figures 13 and 14 in the paper.  It depends a lot on the TCP
and TLS timeout you use.  Fortunately it's less than 24GB at steady
state, which is not a problem for today's hardware.  (Although the
server should be prepared to early-terminate connections if it's under
memory pressure.)

Our experiments assume well configured clients and servers.  Although
not so important for load, optimizations make a huge difference
difference for latency.  Options like TCP fast open and TLS connection
resumption get some of the improvements in QUIC, but over TCP (see
<http://dx.doi.org/10.1109/SP.2015.18>,
<https://www.isi.edu/%7ejohnh/PAPERS/Zhu15b.html> for the details).  I
hope people evaluating DNS over QUIC compare against best-configured TCP
and not just basic TCP without optimizations.

   -John Heidemann