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

[Michael Tremer <michael.tremer@ipfire.org>]

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