Benno Overeinder <[email protected]> wrote: > > All solutions above are stable performant DNS-over-TLS implementations.
I think what Ian is referring to is support for concurrent queries and out-of-order responses. I briefly tested a few resolvers starting from an empty cache, making 2000 queries with a max concurrency of 100 outstanding queries. I'm using `adns` which pipelines queries down one persistent TCP connection. With BIND 9.11 (concurrent TCP queries) it took 42s over UDP and 42s over TCP. With BIND 9.10 (serialized TCP queries) it took 72s over UDP and over TCP it took 427s - plus I had to reduce the TCP concurrency to 10 to stop the client timing out, and even with this limited concurrency, a couple of slow queries can cause several following queries to time out even if they would otherwise have succeeded. With Unbound over UDP this test completed in 110 seconds, but over TCP it took 870 seconds, and again I had to restrict the concurrency to reduce timeouts. There's a lot of variation in the times because most of the delay is due to broken authoritative servers (the 2000 queries come from a very crappy dataset) and Unbound and BIND have different strategies for handling brokenness. Unlike my test, for DNS-over-TLS the delay we usually care about is the stub/resolver latency (because much of the use case involves talking to resolvers that are further away). It's important that the stub doesn't have artificial concurrency limitations so it can compensate for this latency without having to work around head-of-line blocking. It's also important that the stub can use a persistent connection so it isn't paying for the multi-round-trip setup cost on every query. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Trafalgar: Cyclonic gale 7 to severe gale 9, occasionally storm 10 for a time in northwest, becoming northwesterly 5 to 7 later. Very rough or high, occasionally very high for a time in west, becoming rough or very rough later. Rain or showers. Good, occasionally poor. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
