Description
As previous issues have noted (#646, #1314), for any single TCP connection, DNS queries are handled serially. This is generally not a big problem, as
- DNS over TCP is not all that common, and
- typically the overhead of establishing the TCP connection after having received a truncated UDP packet means the latency is already high, the serial processing of queries doesn't significantly worsen it.
However, in the specific case of a DNS proxy, the serial processing becomes a significant contributing factor: a proxy has to forward the queries as part of the handler, synchronously. (The current handler interface doesn't seem to allow doing so asynchronously - the ResponseWriter is alive while the handler function is running, but not longer.) Since clients often send two (or more) queries approximately simultaneously, the second query incurs a delay of a full RTT to the upstream server, just waiting for the first query to be handled. Similarly so, any further simultaneous queries incur more RTTs waiting for exchanges with the upstream, which isn't great.
Now, as previous issues have established, changing the existing TCP server to be pipelined is not an option (and probably a breaking change), since the handler would have to deal with the fact that it is being called concurrently and the response writer would to be made thread-safe without losing performance.
Long story short, I'm opening this issue to inquire whether the library would accept a contribution of an alternative TCP server which does do pipelining or whether that would be considered out of scope.