Pihole seems very show with collapsed / recursive queries–even when cached. For example, www.ucla.edu resolves to (4) cnames . Querying' pihole is avg MS = 115ms , whereas my router's DNS is ~ 1.8ms (see results below). hostnames with fewer CNAME entries have less delta between pihole & router DNS server (e.g. www.facebook.com = AVG 4ms pihole vs 1.5ms router dns)
Questions
Is this poor performance expected?
Config changes that can help here?
how to trace dnsmasq / pihole-FTL to find the issue?
What I've Tried to Fix
i've set local-TTL=360 to force caching.
Pihole Results for www.ucla.edu AVG=143ms [n=30, concurrent=2]
Lastly, that 353.3µs is the standard deviation, not the actual query time. The Minimum, Maximum and Mean are what you should be looking at, Mean being the most relevant.
I'm not installing a full go toolchain to get one binary, sorry.
What are you using for the upstream?
What I'm seeing is that results are from cache and fast from cache. Throwing more queries at the resolver isn't going to change that or cause the results to slow down. So we need to find where the slowdown actually is happening and why it's happening.
You're getting a lot of noise and very little signal.
Change the upstream to something besides the router and check the actual results to see if you're getting back IP addresses and results instead of timing out. And remove any changes you've made to TTL values in the configurations.
the test above (router) shows response time at router / 192.168.1.1 is very low 1.8 ms. that makes me confident that I'm getting high latency signal from testing pihole . can you clarify?
dan@nanopineo:~$ dnsping -s 127.0.0.1 www.ucla.edu
dnsping DNS: 127.0.0.1:53, hostname: www.ucla.edu, rdatatype: A
212 bytes from 127.0.0.1: seq=0 time=148.009 ms
212 bytes from 127.0.0.1: seq=1 time=11.096 ms
212 bytes from 127.0.0.1: seq=2 time=10.740 ms
212 bytes from 127.0.0.1: seq=3 time=19.682 ms
212 bytes from 127.0.0.1: seq=4 time=19.038 ms
212 bytes from 127.0.0.1: seq=5 time=21.634 ms
212 bytes from 127.0.0.1: seq=6 time=10.756 ms
212 bytes from 127.0.0.1: seq=7 time=18.132 ms
212 bytes from 127.0.0.1: seq=8 time=19.273 ms
212 bytes from 127.0.0.1: seq=9 time=18.999 ms
--- 127.0.0.1 dnsping statistics ---
10 requests transmitted, 10 responses received, 0% lost
min=10.740 ms, avg=29.736 ms, max=148.009 ms, stddev=41.763 ms
dan@nanopineo:~$ dnsping -s 8.8.8.8 www.ucla.edu
dnsping DNS: 8.8.8.8:53, hostname: www.ucla.edu, rdatatype: A
212 bytes from 8.8.8.8: seq=0 time=16.569 ms
212 bytes from 8.8.8.8: seq=1 time=18.149 ms
212 bytes from 8.8.8.8: seq=2 time=14.132 ms
212 bytes from 8.8.8.8: seq=3 time=14.882 ms
212 bytes from 8.8.8.8: seq=4 time=14.152 ms
212 bytes from 8.8.8.8: seq=5 time=14.519 ms
212 bytes from 8.8.8.8: seq=6 time=13.936 ms
212 bytes from 8.8.8.8: seq=7 time=20.670 ms
212 bytes from 8.8.8.8: seq=8 time=13.472 ms
212 bytes from 8.8.8.8: seq=9 time=13.521 ms
--- 8.8.8.8 dnsping statistics ---
10 requests transmitted, 10 responses received, 0% lost
min=13.472 ms, avg=15.400 ms, max=20.670 ms, stddev=2.364 ms
On a fresh vm install i get similar results to you.
Is there tracing I can activate for FTL so i could see where the extra latency is coming from? my theory is that e.g. logging IO or recursive call is causing the difference between www.ucla.edu & www.facebook.com, and the reduced resources of the server are highlighting that issue well