So after installing Pi Hole, I realized that my home network had gotten slower than before. At first, I thought it may be because of RPi(which is a slow piece of hardware and is no . match to actual DNS servers). But after digging a bit, I found out that Pi Hole was resolving to servers with high ping time.
For example, using just 8.8.8.8/8.8.4.4 as my DNS server, google.com is resolved to:
~
❯ ping google.com
PING google.com (216.58.196.206): 56 data bytes
64 bytes from 216.58.196.206: icmp_seq=0 ttl=56 time=7.708 ms
64 bytes from 216.58.196.206: icmp_seq=1 ttl=56 time=6.879 ms
64 bytes from 216.58.196.206: icmp_seq=2 ttl=56 time=7.101 ms
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 6.879/7.229/7.708/0.350 ms
But with Pi Hole and 8.8.8.8/8.8.4.4 as my upstream DNS servers, google.com is resolved to:
~
❯ ping google.com
PING google.com (172.217.194.139): 56 data bytes
64 bytes from 172.217.194.139: icmp_seq=0 ttl=45 time=93.338 ms
64 bytes from 172.217.194.139: icmp_seq=1 ttl=45 time=92.548 ms
64 bytes from 172.217.194.139: icmp_seq=2 ttl=45 time=94.111 ms
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 92.548/93.332/94.111/0.638 ms
As you can see, the average ping time is ~13.5x times higher with the server that Pi Hole has resolved to. But what I am not able to digest is the fact that I am using none other than the Google DNS servers in both cases. Why is this disparity arising?
What do you mean by load balancing? Look at the following example:
~
❯ host -t a google.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
google.com has address 216.58.196.206
~
❯ ping 216.58.196.206
PING 216.58.196.206 (216.58.196.206): 56 data bytes
64 bytes from 216.58.196.206: icmp_seq=0 ttl=56 time=7.824 ms
64 bytes from 216.58.196.206: icmp_seq=1 ttl=56 time=7.532 ms
64 bytes from 216.58.196.206: icmp_seq=2 ttl=56 time=9.919 ms
^C
--- 216.58.196.206 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.532/8.425/9.919/1.063 ms
~
❯ host -t a google.com 10.0.0.53
Using domain server:
Name: 10.0.0.53
Address: 10.0.0.53#53
Aliases:
google.com has address 74.125.68.139
google.com has address 74.125.68.138
google.com has address 74.125.68.101
google.com has address 74.125.68.102
google.com has address 74.125.68.100
google.com has address 74.125.68.113
~
❯ ping 74.125.68.139
PING 74.125.68.139 (74.125.68.139): 56 data bytes
64 bytes from 74.125.68.139: icmp_seq=0 ttl=45 time=84.267 ms
64 bytes from 74.125.68.139: icmp_seq=1 ttl=45 time=84.126 ms
64 bytes from 74.125.68.139: icmp_seq=2 ttl=45 time=84.667 ms
^C
--- 74.125.68.139 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 84.126/84.353/84.667/0.229 ms
Look at the difference between servers returned by 8.8.8.8 and 10.0.0.53 (Pi Hole) and consequently their ping times. The servers returned by Pi Hole have high ping time from my geographical location. Why isn't Pi Hole returning servers that could have a low ping time from my geographical location?
When you directly query 8.8.8.8 as you do in host ... 8.8.8.8 you are sending Google (or whatever upstream) your local IP address. Google then uses that information to return to you the closest DNS server to your location. You expose your location to Google for the convenience of a nearer server to query.
When you query Pi-hole, it doesn't expose your private information, it just asks for the IP address of the FQDN that you are looking for. Since there is no information to geolocate you, you get a set of default servers.
Please generate a debug log and upload it, then post the token here. This will let us see your configuration so we can try to duplicate what you are seeing.
Also, run these commands below and post the output:
I am also using unbound for DNS over TLS. Can this be the root of the problem? If so, is there any other way to set up DNS over TLS on Pi Hole? DNS over TLS is important for me because my ISP intercepts normal DNS requests and block websites using it. Is there a way to send only some requests (those being blocked) to unbound?
This may not resolve your problem of getting different IP addresses back when you look for the IP of google.com. From your previous posts, you have received back from your upstream servers the following IP's, all of which are valid IP's for google.com but not all of which may be geographically near you or fast responding. If this is the domain that causes you the most delay, then mapping google.com to the fastest responder (in /etc/hosts on the Pi) would resolve this problem.
172.217.194.138
74.125.68.139
216.58.196.206
For example, when I ping those IP's from where I live in the US, ping averages are 213, 217 and 309 respectively. When I ping the IP that resolves on a local dig for google.com, the ping average is 22.
Cloudflare DNS has really bad ping time at my location. Let alone the ping time of servers returned by it.
~
❯ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=54 time=106.924 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=54 time=86.177 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=54 time=87.584 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=54 time=85.591 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=54 time=85.503 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=54 time=87.293 ms
^C
--- 1.1.1.1 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 85.503/89.845/106.924/7.678 ms
~ 6s
❯ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=122 time=9.079 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=122 time=7.041 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=122 time=7.299 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=122 time=6.778 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=122 time=7.778 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=122 time=24.961 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 6.778/10.489/24.961/6.514 ms
Google has a good ping time but what I have now started to think is that at present not every Google server supports TLS. Therefore, unbound gets connected to a Google server that is far away. And also maybe because of this, the servers returned by it are far away too and so suck in ping time. What do you think about this theory?