Re: [dns-privacy] some DNS privacy implementation benchmark

[Carsten Strotmann <[e-mail]>]

Hello Christian,

Christian Huitema writes:


> These are interesting measurements, but they mix three variables: the
> transport protocol, the RTT between stub and resolver, and the amount of
> caching at the resolver.

Yes, I know. The goal for this measurements were not to judge the
different protocols, but to give an indication of performance on
implementations available today (this work is part of an magazine
article about implementing DNS-Privacy on Linux/BSD).

>
> In my simulations, the key variable is the Round Trip Time between stub
> and resolver. The various transports differ in how they handle
> connections, retransmission, and head of queue blocking,

There is a gap between the theoretical abilities of the transports and
the available implementations. I was interested in the user experience
today using the tools that are available in mainstream Linux
distributions (except "dnsfwd", which is only available as
[experimental] source but which I added to not hurt the reputation of
DNS-over-TLS).

> but these
> effects are always expressed in terms of "number of additional RTT times
> some probability", the probability generally being at most a few percents.
>
> The other variable in a "stub to recursive" scenario is the amount of
> caching done by the resolver. In standard stub to recursive scenarios,
> the queries appear to be served from the cache 30% to 40% of the time --
> with a better service at big resolvers such as large ISP or Google DNS.
> This is because the cache is populated from requests of multiple
> clients, plus probably some pre-fetching. Small resolvers typically have
> lower cache rate. This matters, because the "recursive to authoritative"
> part of the resolution is typically larger than the "stub to resolver" part.
>

I will re-do the test with a replay of some real-world DNS queries that
will make use of caching. The test I've done now is somewhat artificial,
as it asked 1000 different questions on a cold cache. But that was the
best way to measure the DNS resolution performance trough the different
transports. Getting an answer from a local cache is always 0 ms in a
local LAN.

> In the unbound scenarios, were you using unbound as a local recursive
> server?

Yes. The cache was cold at the beginning of each test.

>
>> "Stubby" is missing, I having issues getting it to work, I will update
>> this list once I've got "Stubby" working.
>>
>> As I have this setup now, is there an working implementation that is
>> missing and should also be in the list?
>>
>> DNS-over-QUIC?
>> DNS-over-HTTP(S)?
> You probably need to wait until at least October for realistic
> implementations of DNS over QUIC.

I'm excited about DNS-over-QUIC from the technical point of view, it has
potential. From the point of DNS Privacy, I'm not so thrilled, as I fear
that the one major implementation will be between Chrome Browser and
Google-DNS, which is a Zero-sum game for DNS privacy.

Anyway, I will test drive DNS-over-QUIC once it is available in some
useable form.

Best regards

Carsten Strotmann