[dnsdist] [EXT] Re: First alpha release of dnsdist 1.6.0

[Remi Gacogne]

On 2/3/21 10:23 AM, Stephane Bortzmeyer wrote:
>> Did you also enable out-of-order between dnsdist and the backend, using
>> maxInFlight on the newServer() directive?
> 
> Yes:
> 
> newServer({address="127.0.0.1:53", name="Local-Unbound", useClientSubnet=false, maxInFlight=256})		-
> 
> The backend is an Unbound, used over UDP.

I might need to clarify one thing that is not obvious to many dnsdist 
users, because it's not very intuitive and is a legacy of the original 
dnsdist design.

dnsdist will pass queries it received over UDP or DoH to the backend 
using UDP, and queries it received over TCP or DoT using TCP. It 
initially made sense to do it that way to avoid dealing with UDP payload 
size and truncation ourselves.
Then DoH was implemented in a different way, for performance reasons, 
and it's now harder to follow.

I plan to rework that from scratch in 1.7. Queries will always be sent 
to the backend over UDP (or likely DoQ in the future) and we will only 
retry over TCP/DoT in case of truncation.

>> Do you know if the backend does indeed support out-of-order?
> 
> Is it relevant when you talk to the backend over UDP?

Yes, because we don't actually talk to the backend over UDP for queries 
received over DoT.

>> However in your case I'm guessing the monitoring scripts do not really do
>> pipelining,
> 
> Correct. One request, on one connection.

Alright, so it does not seem directly related. I'll do some tests to try 
to reproduce the issue. Do you see the timeouts with both Remoh and the 
getdns-based program?

>> Note that client-side DoH in dnsdist has always supported
>> out-of-order, as the underlying design of HTTP/2 made that quite
>> easy, so nothing should change for DoH in 1.6.0.
> 
> Indeed, DoH has no issue, it is purely a DoT problem.
> 
> I'm currently testing with maxInFlight=0 on everything (addTLSLocal
> and newServer). Should I also test with maxInFlight=256 on addTLSLocal
> but maxInFlight=0 on newServer?

It might be interesting to know if that makes the issue go away, yes. 
But please don't break your service for that, I'll try reproducing the 
issue locally anyway!

Thanks again,
-- 
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/