From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: DNS over TLS performance and query randomisation across multiple forwarders Date: Thu, 20 Feb 2020 14:37:47 +0000 Message-ID: <15108BB5-2BC1-4B04-B5C9-FAA8D7E5B3D8@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6591384860243881793==" List-Id: --===============6591384860243881793== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 19 Feb 2020, at 21:17, Peter M=C3=BCller wr= ote: >=20 > Hello *, >=20 > 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. >=20 > 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. >=20 > Stubby (https://dnsprivacy.org/wiki/display/DP/About+Stubby), which is > also written by NLnet Labs, aims to fix both issues. >=20 > 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. :-) >=20 > 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 u= p with. We already have daisy-chained the stub resolvers in our clients to the resolv= er inside IPFire, which then connects to other resolvers which then connect t= o 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 pro= cess to open a TCP connection. Responses coming through that connection there= fore could not be cached. A nightmare when we enabled DNSSEC. DNS has always been specified for TCP - as well as UDP obviously. If your imp= lementation cannot handle TCP, you have not implemented DNS. You have impleme= nted a subset of it. I guess that is beyond obvious that performance matters for people who write = DNS software. And this isn=E2=80=99t rocket science. Unbound seems to have some trouble here. A forward-proxy is not a solution th= at I would support. I would rather move to another DNS proxy. -Michael > Thanks, and best regards, > Peter M=C3=BCller --===============6591384860243881793==--