Pihole -up uses a hard coded DNS

Help
1

Today I updated Raspberry Pi OS (Raspbian 10) using the command "sudo apt update" followed by "sudo apt full-upgrade" and then I ran raspi-config and updated that as well. After those completed I ran "pihole -up" and it successfully updated the web interface, but failed to update FTL.

After that I verified the PiHole is able to resolve ns1.pi-hole.net using dig and nslookup, both resolved it as 185.136.96.96.

The updater script still failed to resolve ns1.pi-hole.net. I'm wondering if the compatibility list is working correct as my network configuration appears to be okay.

Here is my console output for reference.

pi@raspberrypi:~ $ sudo dig ns1.pi-hole.net

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> ns1.pi-hole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37484
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ns1.pi-hole.net.               IN      A

;; ANSWER SECTION:
ns1.pi-hole.net.        632     IN      A       185.136.96.96

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Feb 17 09:47:31 EST 2021
;; MSG SIZE  rcvd: 60

pi@raspberrypi:~ $ dig ns1.pi-hole.net

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> ns1.pi-hole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7842
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ns1.pi-hole.net.               IN      A

;; ANSWER SECTION:
ns1.pi-hole.net.        614     IN      A       185.136.96.96

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Feb 17 09:47:49 EST 2021
;; MSG SIZE  rcvd: 60

pi@raspberrypi:~ $ nslookup ns1.pi-hole.net
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   ns1.pi-hole.net
Address: 185.136.96.96
Name:   ns1.pi-hole.net
Address: 2a06:fb00:1::1:96

pi@raspberrypi:~ $ pihole -up
  [i] Checking for updates...
  [i] Pi-hole Core:     up to date
  [i] Web Interface:    up to date
  [i] FTL:              update available

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

  [✓] Root user check

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

  [✓] Update local cache of available packages
  [i] Existing PHP installation detected : PHP version 7.3.19-1~deb10u1
  [i] Performing unattended setup, no whiptail dialogs will be displayed

  [✓] Checking apt-get for upgraded packages... up to date!

  [i] Installer Dependency checks...
  [✓] Checking for dhcpcd5
  [✓] Checking for git
  [✓] Checking for iproute2
  [✓] Checking for whiptail
  [✓] Checking for dnsutils

  [✗] Retrieval of supported OS list failed. dig failed with return code 9.
      Unable to determine if the detected OS (Raspbian 10) is supported
      Possible causes for this include:
        - Firewall blocking certain DNS lookups from Pi-hole device
        - ns1.pi-hole.net being blocked (required to obtain TXT record from versions.pi-hole.net containing supported operating systems)
        - Other internet connectivity issues

      https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems

      If you wish to attempt to continue anyway, you can try one of the following commands to skip this check:

      e.g: If you are seeing this message on a fresh install, you can run:
             curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash

           If you are seeing this message after having run pihole -up:
             PIHOLE_SKIP_OS_CHECK=true sudo -E pihole -r
           (In this case, your previous run of pihole -up will have already updated the local repository)

      It is possible that the installation will still fail at this stage due to an unsupported configuration.
      If that is the case, you can feel free to ask the community on Discourse with the Community Help category:
      https://discourse.pi-hole.net/c/bugs-problems-issues/community-help/


  Unable to complete update, please contact Pi-hole Support
pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

fyi: the Raspberry pi is using my gateway (192.168.1.1) for its own upstream DNS to avoid filtering, while still providing filtering for all other devices on the lan.

2

I found the problem. The pihole -up script uses a hard coded DNS.
I know this because my gateway is blocking all outbound port 53 in order to block any sneaky hard coded DNS (pihole is currently using DNS over HTTPS via cloudflared and it doesn't get blocked by the gateway when looking up DNS for clients on LAN). The only port 53 traffic the gateway allows is if the destination IP is the gateway itself (DNS request placed to the gateway is answered but DNS requests placed directly to other upstream DNS servers get denied). I removed this rule and then the pihole -up script completed successfully.

This means that the dns lookup for ns1.pi-hole.net in the FTL portion of the pihole -up script is using a specific upstream DNS, which I do no permit. Please update future versions of the script to not function in this way, instead have future versions of the pihole -up script use the DNS specified either by network lease or by dhcpcd.conf.

3

You were provided with the exact instructions on how to update if the supported OS check is unable to complete.

 [✗] Retrieval of supported OS list failed. dig failed with return code 9.
      Unable to determine if the detected OS (Raspbian 10) is supported
      Possible causes for this include:
        - Firewall blocking certain DNS lookups from Pi-hole device
        - ns1.pi-hole.net being blocked (required to obtain TXT record from versions.pi-hole.net containing supported operating systems)
        - Other internet connectivity issues

      https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems

      If you wish to attempt to continue anyway, you can try one of the following commands to skip this check:

      e.g: If you are seeing this message on a fresh install, you can run:
             curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash

           If you are seeing this message after having run pihole -up:
             PIHOLE_SKIP_OS_CHECK=true sudo -E pihole -r
           (In this case, your previous run of pihole -up will have already updated the local repository)

      It is possible that the installation will still fail at this stage due to an unsupported configuration.
      If that is the case, you can feel free to ask the community on Discourse with the Community Help category:
      https://discourse.pi-hole.net/c/bugs-problems-issues/community-help/
1 Like
4

That is correct, but that is not a solution.

  1. What if the OS is not supported? I would not ever want to bypass this check under any circumstances.
  2. The updater is using a hard coded DNS which goes against the principle of this project.
5

It is the solution. Sorry you don't like it.

Edit: Please don't DM me for this, I don't respond to DMs.

6

May I suggest a change request or enhancement request?
It seems like a bad idea to promote using hard coded DNS on a project targeted specifically to managing DNS.

By ITIL4 definitions this is at best this a work-around to a bug, not a solution.

7

You can suggest anything. If you search this forum you'll see our responses to why this was done and the exact reasoning why it was done.

You've been told by a developer exactly how to address this. That's what you need to do.

1 Like
8

Your best option is to make an exception in your firewall rules to allow outgoing DNS on port 53 from the Pi-hole host device. In the debug log we use hard coded DNS (google.dns in this case) to test DNS connectivity. If you block outgoing port 53 on the Pi-hole host, you interfere with debug operation.

11

For the time being I've allowed only the pihole to communicate outbound on 53 to only 185.136.96.96.

A better solution for DNS verification would be preferred but we cant have everything we want sometimes. Cheers folks, love the project.

22

What's the meaning of DM?

23

I wanted to come back to this thread to say what I ended up learning and what I ended up doing.

What turned out to be happening is there is a resolve check built into the updater to make sure it is getting updates from the correct location. That check is done over port 53 by the host os pihole is running on, so it will depend on the os's dns settings, not the pihole.

To allow this rogue DNS reqeust out, I have created a rule on my firewall that only allows outbound 53 from the PiHole and only if the requests destination matches the correct ip for it.

Thanks Dan and anyone else who contributed to this project. Donate! <3

25

Direct message.

26

Thanks for your reply ... without sending a DM :wink:

27

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