DNS Response is Slow

Help
1

Please follow the below template, it will help us to help you!

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

Expected Behaviour:

_Actually working, just unusually slow DNS response:
-Raspbian 11

  • first-generation Raspberry Pi Model B]_

Actual Behaviour:

slow DNS response

Debug Token:

(https://tricorder.pi-hole.net/LVG8yQSA/)

I'm guessing it may be time to update the hardware? Existing set-up has been working fine for the last couple of years, so just interested in your thoughts?

Thanks

Mark

2

What evidence do you have of slow DNS response?

3

Slow response navigating to or refreshing web pages somtimes resulting in timeouts.

Updated pihole to latest via command line.

Message generated by pihole after update....
Along the lines of average load over 15mins 1.2 number of processors 1 may result in slow dns response.

4

This can be due to a number of factors other than slow DNS. There are a lot of steps involved to load an entire web page.

Let's take a look at your DNS process right now.

From the Pi terminal, what is the output of the following command:

time dig grainger.com @127.0.0.1

time dig grainger.com @1.1.1.1

This is fairly typical for a short period after an update, which is a processor intensive process. Example of a Pi 3B+ just running Pi-hole and essentially idle:

pi@Pi-3B-DEV:~ $ uptime
 15:28:00 up 393 days, 16:06,  1 user,  load average: 0.00, 0.02, 0.00
pi@Pi-3B-DEV:~ $ pihole -up
  [✓] Update local cache of available packages
  [i] Existing PHP installation detected : PHP version 7.4.33
  [✓] Checking for git
  [✓] Checking for iproute2
  [✓] Checking for dialog
  [✓] Checking for ca-certificates

  [i] Checking for updates...
  [i] Pi-hole Core:	update available
  [i] Web Interface:	up to date
  [i] FTL:		update available

  [i] Pi-hole core files out of date, updating local repo.
  [✓] Check for existing repository in /etc/.pihole
  [✓] Update repo in /etc/.pihole

  [i] If you had made any changes in '/etc/.pihole/', they have been stashed using 'git stash'

  [i] FTL out of date, it will be updated by the installer.

  [✓] Root user check

        .;;,.
        .ccccc:,.
         :cccclll:.      ..,,
          :ccccclll.   ;ooodc
           'ccll:;ll .oooodc
             .;cll.;;looo:.
                 .. ','.
                .',,,,,,'.
              .',,,,,,,,,,.
            .',,,,,,,,,,,,....
          ....''',,,,,,,'.......
        .........  ....  .........
        ..........      ..........
        ..........      ..........
        .........  ....  .........
          ........,,,,,,,'......
            ....',,,,,,,,,,,,.
               .',,,,,,,,,'.
                .',,,,,,'.
                  ..'''.

  [i] SELinux not detected
  [✓] Update local cache of available packages
  [i] Existing PHP installation detected : PHP version 7.4.33

  [✗] Checking apt-get for upgraded packages
      Kernel update detected. If the install fails, please reboot and try again
  [i] Checking for / installing Required dependencies for OS Check...
  [✓] Checking for grep
  [✓] Checking for dnsutils

  [✓] Supported OS detected
  [i] Checking for / installing Required dependencies for this install script...
  [✓] Checking for git
  [✓] Checking for iproute2
  [✓] Checking for dialog
  [✓] Checking for ca-certificates

  [i] Performing unattended setup, no dialogs will be displayed
  [i] Performing reconfiguration, skipping download of local repos
  [✓] Resetting repository within /etc/.pihole...
  [✓] Resetting repository within /var/www/html/admin...
  [i] Checking for / installing Required dependencies for Pi-hole software...
  [✓] Checking for cron
  [✓] Checking for curl
  [✓] Checking for iputils-ping
  [✓] Checking for psmisc
  [✓] Checking for sudo
  [✓] Checking for unzip
  [✓] Checking for idn2
  [✓] Checking for libcap2-bin
  [✓] Checking for dns-root-data
  [✓] Checking for libcap2
  [✓] Checking for netcat-openbsd
  [✓] Checking for procps
  [✓] Checking for jq
  [✓] Checking for lighttpd
  [✓] Checking for php7.4-common
  [✓] Checking for php7.4-cgi
  [✓] Checking for php7.4-sqlite3
  [✓] Checking for php7.4-xml
  [✓] Checking for php7.4-intl
  [✓] Checking for php7.4-json

  [✓] Enabling lighttpd service to start on reboot...
  [✓] Checking for user 'pihole'

  [i] FTL Checks...

  [✓] Detected ARMv7 processor (with hard-float support)
  [i] Checking for existing FTL binary...
  [i] Checksums do not match, downloading from ftl.pi-hole.net.
  [✓] Downloading and Installing FTL
  [✓] Installing scripts from /etc/.pihole

  [i] Installing configs from /etc/.pihole...
  [i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
  [✓] Installed /etc/dnsmasq.d/01-pihole.conf
  [✓] Installed /etc/dnsmasq.d/06-rfc6761.conf

  [✓] Installing sudoer file

  [✓] Installing latest Cron script

  [i] Installing latest logrotate script...
	[i] Existing logrotate file found. No changes made.
  [i] Backing up /etc/dnsmasq.conf to /etc/dnsmasq.conf.old
  [✓] man pages installed and database updated
  [i] Testing if systemd-resolved is enabled
  [i] Systemd-resolved is not enabled
  [✓] Restarting lighttpd service...
  [✓] Enabling lighttpd service to start on reboot...
  [i] Restarting services...
  [✓] Enabling pihole-FTL service to start on reboot...
  [✓] Restarting pihole-FTL service...
  [✓] Deleting existing list cache
  [✗] DNS resolution is currently unavailable
  [✓] DNS resolution is now available

  [i] Neutrino emissions detected...
  [✓] Pulling blocklist source list into range

  [✓] Preparing new gravity database
  [✓] Creating new gravity databases
  [i] Using libz compression

  [i] Target: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
  [✓] Status: Retrieval successful
  [✓] Parsed 154587 exact domains and 0 ABP-style domains (ignored 1 non-domain entries)
      Sample of non-domain entries:
        - "0.0.0.0"


  [i] Target: https://www.github.developerdan.com/hosts/lists/ads-and-tracking-extended.txt
  [✓] Status: Retrieval successful
  [✓] Parsed 429286 exact domains and 0 ABP-style domains (ignored 0 non-domain entries)

  [✓] Building tree
  [✓] Swapping databases
  [✓] The old database remains available
  [i] Number of gravity domains: 583873 (575369 unique domains)
  [i] Number of exact blacklisted domains: 1
  [i] Number of regex blacklist filters: 23
  [i] Number of exact whitelisted domains: 28
  [i] Number of regex whitelist filters: 3
  [✓] Flushing DNS cache
  [✓] Cleaning up stray matter

  [✓] FTL is listening on port 53
     [✓] UDP (IPv4)
     [✓] TCP (IPv4)
     [✓] UDP (IPv6)
     [✓] TCP (IPv6)

  [✓] Pi-hole blocking is enabled

  [i] The install log is located at: /etc/pihole/install.log
  [✓] Update complete! 

  Current Pi-hole version is development v5.17.3-77-g25755844
  Current web version is devel v5.21-21-g5f7be302
  Current FTL version is development vDev-8543015
pi@Pi-3B-DEV:~ $ uptime
 15:29:53 up 393 days, 16:08,  1 user,  load average: 1.41, 0.59, 0.21

Here is some reading on Linux load averages.

5

Thanks for the response and insight. Things were running slow and that is what prompted a reboot and update. Things seem better this evening. Output from the query given below:

image
image825×521 18.9 KB

image
image825×521 14.5 KB

Nothing to lose sleep over, so unless there is something that comes out of the above, I'll take it that it was just one of those things.
Again thanks for your help.

Forgot to say, like the avatar. My furry family member is asleep along side me.

6

Comparing the two, the first DNS query (going through Pi-hole) is markedly slower than direct to an upstream DNS server. For comparison, here is the output of the same two commands from one of my Pi-holes running unbound as the upstream DNS server:

nanopi-neo:~:# time dig grainger.com @127.0.0.1

; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> grainger.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47953
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;grainger.com.			IN	A

;; ANSWER SECTION:
grainger.com.		300	IN	A	23.12.6.203

;; Query time: 95 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Feb 16 15:23:05 CST 2024
;; MSG SIZE  rcvd: 57

dig grainger.com @127.0.0.1  0.06s user 0.03s system 26% cpu 0.354 total

nanopi-neo:~:# time dig grainger.com @1.1.1.1

; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> grainger.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54198
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;grainger.com.			IN	A

;; ANSWER SECTION:
grainger.com.		20	IN	A	23.12.6.203

;; Query time: 163 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Fri Feb 16 15:23:17 CST 2024
;; MSG SIZE  rcvd: 57

dig grainger.com @1.1.1.1  0.06s user 0.03s system 31% cpu 0.254 total

They are roughly the same.

This could indicate a configuration or performance problem with your local unbound install, which is what Pi-hole is using for the upstream DNS server.

Shift your upstream DNS server in Pi-hole to something other than unbound and see if the problem resolves.

9

I took a look at the configuration of Unbound and followed the guidance to disable resolvconf.conf & 'resolvconf_resolvers.conf' as the Pi OS was built on Debian Bullseye.

Repeating the same test gives a significant improvement in the time to resolve the DNS query.

Thanks for your help.

10

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.