DNS over TLS performance and query randomisation across multiple forwarders

DNS over TLS performance and query randomisation across multiple forwarders

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

Hello *,

while DNS over TLS is operational in upcoming Core Update 140/141, we
already discovered some performance issues due to missing TLS connection
reuse and similar optimisations.

Further, Unbound performs some measurements to determine response times
of given forwarders and submits all queries to the fastest one - which
obviously is a bad thing with a view to DNS privacy.

Stubby (https://dnsprivacy.org/wiki/display/DP/About+Stubby), which is
also written by NLnet Labs, aims to fix both issues.

Personally, I do not like the idea of putting another software before
Unbound in case the user decides to enable DNS over TLS. However, to discuss
this matter and further steps, mentioning it did sound reasonable to me. :-)

Thoughts/comments/opinions?

Thanks, and best regards,
Peter Müller

Re: DNS over TLS performance and query randomisation across multiple forwarders

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]

Hi,

> On 19 Feb 2020, at 21:17, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello *,
> 
> while DNS over TLS is operational in upcoming Core Update 140/141, we
> already discovered some performance issues due to missing TLS connection
> reuse and similar optimisations.
> 
> Further, Unbound performs some measurements to determine response times
> of given forwarders and submits all queries to the fastest one - which
> obviously is a bad thing with a view to DNS privacy.
> 
> Stubby (https://dnsprivacy.org/wiki/display/DP/About+Stubby), which is
> also written by NLnet Labs, aims to fix both issues.
> 
> Personally, I do not like the idea of putting another software before
> Unbound in case the user decides to enable DNS over TLS. However, to discuss
> this matter and further steps, mentioning it did sound reasonable to me. :-)
> 
> Thoughts/comments/opinions?

No. No. No. No. No.

Thanks for bringing this up on the list.

I think that this would be the worst implementation that someone could come up with.

We already have daisy-chained the stub resolvers in our clients to the resolver inside IPFire, which then connects to other resolvers which then connect to the authoritative DNS servers. If something goes wrong in that chain, it is a lot of hassle to figure out where the problem is.

Adding another proxy just to have a re-usable TCP connection is madness.

Unbound clearly seems to be mis-designed if this is not easy to add into the implementation. Dnsmasq used to be the same when it had to fork() another process to open a TCP connection. Responses coming through that connection therefore could not be cached. A nightmare when we enabled DNSSEC.

DNS has always been specified for TCP - as well as UDP obviously. If your implementation cannot handle TCP, you have not implemented DNS. You have implemented a subset of it.

I guess that is beyond obvious that performance matters for people who write DNS software. And this isn’t rocket science.

Unbound seems to have some trouble here. A forward-proxy is not a solution that I would support. I would rather move to another DNS proxy.

-Michael

> Thanks, and best regards,
> Peter Müller