Tried Google, Cloudflare and OpenDNS, unfortunately, still the same.
@MichaIng on the web UI of the router/modem it shows 192.168.1.1 for DNS which is the router’s IP, but again, showing the same error.
So you tried using that IP in /etc/resolv.conf? Does it work when you use something other than curl?
getent ahosts dietpi.com
how long actually following takes
time curl dietpi.com
@MichaIng I prefer not to use ISP’s DNS as it’s slower and people have problems opening some websites, so in various local tech forums, users suggesting switching to some public DNS like those mentioned above. Currently, with Quad9, I’m getting:
x@DietPi:~# getent ahosts dietpi.com
104.21.28.141 STREAM dietpi.com
104.21.28.141 DGRAM
104.21.28.141 RAW
172.67.170.219 STREAM
172.67.170.219 DGRAM
172.67.170.219 RAW
real 0m5.134s
user 0m0.046s
sys 0m0.017s
This is 5 sec, what would be extremely slow. For my systems I get 0.1 sec
root@DietPiProd:~# time curl dietpi.com
real 0m0.145s
user 0m0.025s
sys 0m0.022s
root@DietPiProd:~#
Have you measured the hops and packet loss to these resolvers? Install mtr if you don’t have it already and do a mtr -rwc 5 1.1.1.1 then mtr -rwc 5 8.8.8.8 etc.
Then install dnsutils and do a time dig @1.1.1.1 dietpi.com then time dig @8.8.8.8 dietpi.com
It is generally better to have multiple nameserver entries in the resolv.conf for high availability in case of failure.
If you can change the upstream DNS of your router, you could still benefit from its cache.
The 5s are due to it being the default timeout for DNS resolution. getent shows the result faster, isn’t it? So it’s probably just an issue with curl? wget, apt etc succeed?
Well, my plan is to use Adguard home on this device as a DNS blocker. I will use the upstream DNS in Adguard home, so wanted to solve this issue first.
Anyway, last night before the bed, I returned the initial DNS 9.9.9.11. I just ssh’d to RPi, and it loaded almost instantly without any error shown, so have no idea what fixed that?!
But even now, time curl dietpi.com still shows 5 secs. Also, around 5–6 secs passes before ping commands shows PING dietpi.com (172.67.170.219) 56(84) bytes of data. and then ping time.
@MichaIng I’m not sure is it just an issue with curl, since ping lags quite a bit as well. I tried ping on my VPS which is lower on specs, yet ping shows results instantly. You are correct for getent tho, it shows the results instantly.
What about wget?
time wget --spider dietpi.com
And does it work with normal speed when resolving the hostname locally?
time curl --resolve 'dietpi.com:80:172.67.170.219' dietpi.com
time ping -c1 172.67.170.219
wget returned pretty much the same result as curl in the previous posts
real 0m5.487s
user 0m0.112s
sys 0m0.035s
x@DietPi:~# time curl --resolve 'dietpi.com:80:172.67.170.219' dietpi.com
real 0m0.124s
user 0m0.019s
sys 0m0.032s
x@DietPi:~# time ping -c1 172.67.170.219
PING 172.67.170.219 (172.67.170.219) 56(84) bytes of data.
64 bytes from 172.67.170.219: icmp_seq=1 ttl=53 time=22.3 ms
--- 172.67.170.219 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 22.276/22.276/22.276/0.000 ms
real 0m0.033s
user 0m0.002s
sys 0m0.009s
So it is indeed the system resolver only. Mysterious. Did we actually check for kernel errors already?
dmesg -l 0,1,2,3
I’m getting:
x@DietPi:~# dmesg -l 0,1,2,3
[ 5.609317] sd 0:0:0:0: [sda] No Caching mode page found
[ 5.610013] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 6.655563] sd 1:0:0:0: [sdb] No Caching mode page found
[ 6.656236] sd 1:0:0:0: [sdb] Assuming drive cache: write through
[ 4616.571231] lan78xx 1-1.1.1:1.0 eth0: kevent 4 may have been dropped
[ 6242.140344] lan78xx 1-1.1.1:1.0 eth0: kevent 4 may have been dropped
[87337.376218] lan78xx 1-1.1.1:1.0 eth0: kevent 4 may have been dropped
[88196.198096] lan78xx 1-1.1.1:1.0 eth0: kevent 4 may have been dropped
Not sure if related but found a 5 years old issue at the RPI GitHub Pi3b+: "kevent 4 may have been dropped" with lan78xx · Issue #2447 · raspberrypi/linux · GitHub
I’ve read it, but to be honest, I’m not sure what am I supposed to do. DietPi is on the latest version, RPi is connected over LAN and Wi-Fi is disabled.
edit:
After reboot, it shows first four rows now:
x@DietPi:~# dmesg -l 0,1,2,3
[ 5.588436] sd 0:0:0:0: [sda] No Caching mode page found
[ 5.589110] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 6.624248] sd 1:0:0:0: [sdb] No Caching mode page found
[ 6.624916] sd 1:0:0:0: [sdb] Assuming drive cache: write through
that’s fine and should not have any effect
Yeah, understandable, but I’m not sure how to solve the issue where the system lags on curl and wget. Both are a bit over 5s.
1 Like
I will add into this that I have now had this on both a RPi3B+ and a VM install of Dietpi.
I followed some of the guidance and changed the DNS settings on the network settings in dietpi-config and removed the DNS entry for Pihole and this resolved the issue.
Restoring Pihole restored the issue.
I’m also using Pihole with Unbound. In Pihole, I changed the DNS from Unbound to Cloudlfare and it resolved the issue. Could the issue reside in Unbound?
Current version of Unbound from NLnetLabs is 1.17.1.
Current version in Dietpi is:
Package: unbound
Version: 1.13.1-1