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

[Petr Špaček <[e-mail]>]

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 <[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]

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 
connections.

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 
costs.

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] - 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