Pihole updatePihole uses hard coded DNS server instead of systemd-resolvd or resolv.conf for updates

postgen56 · November 17, 2022, 7:03pm

I've noticed this issue for quite a while and never bothered to try and find a solution, but I think its time to track it down.

When I go to upgrade pihole using this command: /usr/local/bin/pihole updatePihole , it will do an unencrypted DNS lookup to some random DNS server (this time it was 205.251.193.151) for versions.pi-hole.net.

It completely ignored the local systemd-resolvd server I had running, and also ignored /etc/resolv.conf.
Not sure why the update script has this hard coded in, but it seems like a problem to me.

I hope this will be fixed eventually, but for the meantime, anyone know how to force the update process to use the local system resolver?

I am using Debian 11.

Bucking_Horn · November 17, 2022, 7:38pm

It is not a random DNS server, but rather the DNS server at ns1.pi-hole.net.
Using it shouldn't be an issue, as Pi-hole is expected to communicate with various arbitrary upstreams DNS resolvers, as per its variable upstream configuration.
In a tightly controlled environment, you could consider to allow port 53 UDP/TCP connections to ns1.pi-hole.net for Pi-hole's host.

Note that usage of ns1.pi-hole.net is done on purpose to avoid the local resolver.
With an incorrectly configured local resolver, retrieval of Pi-hole's supported versions would fail. This would then result in the installation script incorrectly reporting an unsupported OS.

postgen56 · November 17, 2022, 7:56pm

Understandable. Are you saying that an incorrect local resolver could cause the wrong version list to return, or that the local resolver would be non-functional?

I would like to change this functionality for myself, as my local resolver (systemd-resolvd) does DoT to cloudflare instead of unencrypted. But I am having a hard time finding where the ns1.pi-hole.net is declared in the update scripts.
So far I have found it referenced in the install and debug scripts (unless the update script calls the debug script):

/etc/.pihole/automated install/basic-install.sh:        cmdResult="$(dig +short -t txt "${remote_os_domain}" @ns1.pi-hole.net 2>&1; echo $?)"
/etc/.pihole/automated install/basic-install.sh:                printf "        - ns1.pi-hole.net being blocked (required to obtain TXT record from versions.pi-hole.net containing supported operating systems)\\n"
/etc/.pihole/advanced/Scripts/piholeDebug.sh:    cmdResult="$(dig +short -t txt "${remote_os_domain}" @ns1.pi-hole.net 2>&1; echo $?)"

Bucking_Horn · November 17, 2022, 8:05pm

Neither - an incorrect local resolver may simply not be able to retrieve the list of Pi-hole's supported versions (which is done by something as innocent looking as dig TXT versions.pi-hole.net).

I'd strongly advise against changing the script.

What is it that you want to achieve?

postgen56 · November 17, 2022, 8:15pm

Why would a DNS resolver not be able to retrieve the list? Does the versions.pi-hole.net not get replicated to public DNS servers? My current local resolver just goes to 1.1.1.1.

As a general rule, unencrypted DNS queries are not allowed to leave my network. Using my local resolver could make the pihole update go through DNS over TLS.

If its not possible through a script, I suppose an iptables nat rule back to the local resolver would work (assuming 1.1.1.1 can find the versions domain name ip).

Bucking_Horn · November 17, 2022, 8:39pm

It wouldn't if its incorrectly configured.
See through #3596 for technical details.

If disallowing plain DNS is your goal, I'd halfway expect a firewall rule to redirect requests to public DNS resolvers to be in place already?

If it isn't, I'd consider adding it the superior approach to altering Pi-hole's script.
Such a rule could redirect all stray DNS requests reaching out for unwanted resolvers to your preferred local resolver, not just Pi-hole's (and it would not be potentially overwritten on Pi-hole updates ).

EDIT: Alternatively, you may try to just skip the OS checks via PIHOLE_SKIP_OS_CHECK, avoiding the request altogether, at the potential cost of losing that warning if your OS changes or drops out of support at some time in the future.

postgen56 · November 17, 2022, 8:55pm

I do have a firewall rule just blocking plain DNS queries to the internet, mostly since my DHCP server is supposed to hand out the pi-hole as the only DNS server. (NAT to intercept the queries is a better approach though)

I just tested out a dig to 1.1.1.1 to see if the A record is propagated to it, and unfortunately it is not. The query to 1.1.1.1 only returns the start of authority record for ns1.pi-hole.net. I assume pi-holes own DNS server doesn't offer DNS over TLS.

So, at the end of the day it looks like a plain DNS query to pi-holes own servers is required no matter what.

yubiuser · November 17, 2022, 8:59pm

The update script calls the install script with special flags if an update is available.
You would need to change the script after each update, as it replaces itself during the update (which allows us to make changes to the script).

postgen56 · November 17, 2022, 9:02pm

Is PIHOLE_SKIP_OS_CHECK=true supposed to bypass the version check?

Because I had tried to use that skip but the DNS queries still occurred.

yubiuser · November 17, 2022, 9:05pm

Yes. There should be no DNS lookups, because we dig after the check.

github.com/pi-hole/pi-hole

automated%20install/basic-install.sh

21026d941


      
          if [ "$PIHOLE_SKIP_OS_CHECK" != true ]; then
              # This function gets a list of supported OS versions from a TXT record at versions.pi-hole.net
              # and determines whether or not the script is running on one of those systems
              local remote_os_domain valid_os valid_version valid_response detected_os detected_version display_warning cmdResult digReturnCode response
              remote_os_domain=${OS_CHECK_DOMAIN_NAME:-"versions.pi-hole.net"}
          
              detected_os=$(grep '^ID=' /etc/os-release | cut -d '=' -f2 | tr -d '"')
              detected_version=$(grep VERSION_ID /etc/os-release | cut -d '=' -f2 | tr -d '"')
          
              cmdResult="$(dig +short -t txt "${remote_os_domain}" @ns1.pi-hole.net 2>&1; echo $?)"

postgen56 · November 17, 2022, 9:12pm

Hm, that doesn't seem to be what I'm seeing. Unless updatePihole is incorrect?

Running a background tcpdump for port 53 and then running /usr/local/bin/pihole updatePihole PIHOLE_SKIP_OS_CHECK=true

  [i] Checking for / installing Required dependencies for OS Check...
  [✓] Checking for grep
  [✓] Checking for dnsutils

16:09:39.066909 IP (tos 0x0, ttl 64, id 50426, offset 0, flags [none], proto UDP (17), length 89)
    x.47134 > 205.251.193.151.53: [bad udp cksum 0x4100 -> 0x656b!] 40680+ [1au] TXT? versions.pi-hole.net. ar: . OPT UDPsize=4096 [COOKIE cd9590a1b9a448c5] (61)
16:09:44.067779 IP (tos 0x0, ttl 64, id 53851, offset 0, flags [none], proto UDP (17), length 89)
    x.47134 > 205.251.193.151.53: [bad udp cksum 0x4100 -> 0x656b!] 40680+ [1au] TXT? versions.pi-hole.net. ar: . OPT UDPsize=4096 [COOKIE cd9590a1b9a448c5] (61)
16:09:49.068754 IP (tos 0x0, ttl 64, id 55099, offset 0, flags [none], proto UDP (17), length 89)
    x.47134 > 205.251.193.151.53: [bad udp cksum 0x4100 -> 0x656b!] 40680+ [1au] TXT? versions.pi-hole.net. ar: . OPT UDPsize=4096 [COOKIE cd9590a1b9a448c5] (61)
  [✗] Retrieval of supported OS list failed. dig failed with return code 9. 
      Unable to determine if the detected OS (Debian 11) is supported

Current Versions:
Pi-hole v5.13
FTL v5.18.2
Web Interface v5.16

yubiuser · November 17, 2022, 9:15pm

Try

sudo PIHOLE_SKIP_OS_CHECK=true pihole -up

postgen56 · November 17, 2022, 9:24pm

sudo PIHOLE_SKIP_OS_CHECK=true pihole -up works just fine, only it reinstalls lighttpd (I use nginx). Is there a skip for apt packages?

Also, just out of curiosity, what is the difference between -up and piholeUpdate?

yubiuser · November 17, 2022, 9:29pm

No. It ensures all packages that are needed and supported are installed.

It's faster to type -up on mobile

github.com/pi-hole/pi-hole

pihole

21026d941


      
          # Handle redirecting to specific functions based on arguments
          case "${1}" in
            "-w" | "whitelist"            ) listFunc "$@";;
            "-b" | "blacklist"            ) listFunc "$@";;
            "--wild" | "wildcard"         ) listFunc "$@";;
            "--regex" | "regex"           ) listFunc "$@";;
            "--white-regex" | "white-regex" ) listFunc "$@";;
            "--white-wild" | "white-wild"   ) listFunc "$@";;
            "-d" | "debug"                ) debugFunc "$@";;
            "-f" | "flush"                ) flushFunc "$@";;
            "-up" | "updatePihole"        ) updatePiholeFunc "$@";;
            "-r"  | "reconfigure"         ) reconfigurePiholeFunc;;
            "-g" | "updateGravity"        ) updateGravityFunc "$@";;
            "-l" | "logging"              ) piholeLogging "$@";;
            "uninstall"                   ) uninstallFunc;;
            "enable"                      ) piholeEnable 1;;
            "disable"                     ) piholeEnable 0 "$2";;
            "restartdns"                  ) restartDNS "$2";;
            "-a" | "admin"                ) webpageFunc "$@";;
            "checkout"                    ) piholeCheckoutFunc "$@";;
            "updatechecker"               ) updateCheckFunc "$@";;

postgen56 · November 17, 2022, 9:55pm

Thanks for your help.

I don't want to use lighttpd personally, so in case anyone wants to stop lighttpd, I'll leave this here:

apt-mark hold lighttpd*

/etc/apt/preferences.d/00denypackage

Package: lighttpd
Pin: release *
Pin-Priority: -1

Bucking_Horn · November 17, 2022, 10:40pm

As far as Pi-hole is concerned, I don't think that would be necessary:
Installing lighttpd is optional - you'd have had to confirm its use during Pi-hole's initial installation.

If you'd wanted to revise your decision on having or not having lighttpd, running pihole -r with Reconfigure should have allowed you to do so.

postgen56 · November 17, 2022, 11:02pm

Dang, that reconfigured might have just revealed an issue.

After reconfiguring, now I cant change any settings under Settings->DNS
I click save and it just reverts....
It does pop up with the The DNS settings have been updated at the top.
And if I refresh the settings page firefox asks me if I want to resend the data.

nothing in /var/log/pihole-FTL.log

Not a browser issue, just switched and same issue.
Rebooted the pihole server and still the same issue. I fear the pihole -r may have borked something.

Manually changed setupVars.conf DNSMASQ_LISTENING=bind. Hotfix for now

yubiuser · November 18, 2022, 5:46am

I would check the nginx logs.

postgen56 · November 20, 2022, 7:07pm

Unselecting web interface in pihole -r seems to have disabled the update functionality for pihole's AdminLTE.

In the web interface:

    Pi-hole v5.14.1 FTL v5.19.2 Web Interface v5.16 · Update available! 
    To install updates, run pihole -up.

When I run the update script:

  [✓] 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:     up to date
  [i] FTL:              up to date

  [✓] Everything is up to date!

I just wanted to opt out of lighttpd, not updates for AdminLTE.

Bucking_Horn · November 21, 2022, 4:50pm

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log