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

[Christian Huitema <[e-mail]>]

On 8/12/2017 1:49 PM, Carsten Strotmann wrote:
> Hi,
>
> I did a simple (and naive) benchmark of different DNS privacy
> implementations available.
...
>
> The DNSCrypt resolver was randomly chosen by the software.
>
>  Protocol/Software                      Time (Sec)  Privacy  DNSSEC 
> --------------------------------------------------------------------
>  Google DNS (UDP)                               64  --       +      
>  DNS-over-TLS (dnsfwd+stunnel)                  67  ++       -      
>  local Unbound w/o DNSSEC                      146  -        -      
>  local Unbound w. DNSSEC                       163  -        +      
>  DNS-over-DNSCrypt (ns0.dnscrypt.is)           243  ++       +      
>  DNS-over-Tor                                  254  ++       -      
>  DNS-over-TLS (Unbound+dnsfwd+stunnel)         258  ++       +      
>  DNS-over-TLS (Unbound+stunnel)                444  ++       +      
>  DNS-over-TLS (Unbound buildin TLS)            647  ++       +      

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.

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

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

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

-- 
Christian Huitema