AW: DoT resolvers - Slow results

Talkabout talk.about at gmx.de
Fri Mar 20 20:29:20 UTC 2020


Hi Joe,

thanks for your answer!

I am Aware that the „delay“ is only noticable when a host is actually not cached, but I was wondering why DoT (DNS over TLS) is bringing such a performance decrease.

I have tested both the configurations based on a few static Domains where I can clearly see, that using DoT is much slower.The strange Thing is that querying one particular resolver for one Domain with and without TLS (without unbound inbetween) give very similar Timings. So there must be something on Unbound side making the difference. My Question was whether this is a configuration issue or a given fact when using Unbound with TLS.

Bye

Gesendet von Mail für Windows 10

Von: Joe Abley
Gesendet: Freitag, 20. März 2020 14:57
An: Talkabout
Cc: unbound-users at nlnetlabs.nl
Betreff: Re: DoT resolvers - Slow results

Hey,

On Fri, 20 Mar 2020 at 09:45, Talkabout via Unbound-users <unbound-users at lists.nlnetlabs.nl> wrote:

But the Problem arises when it Comes to Resolution times. With my initial configuration I have an average resolution time of < 100ms. [...]
 
With the TLS way the Resolution time increases to > 200ms. When I query one of those TLS DNS Servers directly via kdig, I get results in approx. 30-60ms.
 
Is this something that one has to live with when using TLS or do I have a configuration Problem on my end?

This is very much a meta-answer (I have no suggestions for your unbound question) but it may be worth remembering that the performance that the clients of your resolver see generally has far more to do with the cache hit rate than the time taken to process a cache miss.

A difference of 100ms in resolution time looks like a 100% increase in processing time and I appreciate why that looks worrying.

However, if a particular upstream server sends responses with a TTL of 3600 seconds and your client traffic needs those responses once a second, though, then it's only 1/3600 of your queries that see the extra latency. This looks far less worrying.

A better test of resolver performance is to find some standard, repeatable tests that emulate what end-users are doing and run them regularly. Tests like "load the front page of amazon.com" or "Load the front page of youtube.com" still involve a lot of DNS traffic and are more reflective of what users actually do than "retrieve a particular RRSet from a particular server".


Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20200320/7a94a4bb/attachment-0001.htm>


More information about the Unbound-users mailing list