Why "pi.hole" name takes +1 day to get resolved?

Help
1

Hi,

First time PiHole setup. PiHole version v5.16.2 on Debian 11 stable. /etc/resolv.conf is configured with 127.0.0.1 (replacing the IP address of the router). The router with DDWRT firmware from March 2023, configured with the PiHole host IP address as static DNS. All is working OK.

From various PiHole setup tutorials, I noticed that the pi.hole name seems to be resolved by the PiHole host itself. There is no host entry in the /etc/hosts related to pi.hole so I assume that this name should be resolved by PiHole itself.

At the time I setup PiHole, all attempts to resolve pi.hole had failed. Either on the PiHole host itself or at one of the clients. Typically http://pi.hole/admin/ was an invalid URL. So I just access the PiHole WebAdmin using the IP address of the PiHole host.

Now a week later, I was about to post a question how to fix the pi.hole name resolution. I made a last check on one of the home device. Surprisingly, now this name is resolved correctly. I didn't add any entry in /etc/hosts of the client nor PiHole server.

QUESTION: what is the mechanism to resolve pi.hole any reason for it to take sometimes to work? Also if I have two PiHole devices. Would there be any conflict in resolving the pi.hole name?

Running on client (Ubuntu 22.04.2)

dig +nocomments +answer pi.hole                                               

; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>> +nocomments +answer pi.hole
;; global options: +cmd
;pi.hole.                       IN      A
pi.hole.                0       IN      A       192.168.1.88
;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Apr 30 12:33:26 EDT 2023
;; MSG SIZE  rcvd: 52

Running on PiHole server (Debian 11)

dig +nocomments +answer pi.hole

; <<>> DiG 9.16.37-Debian <<>> +nocomments +answer pi.hole
;; global options: +cmd
;pi.hole.                       IN      A
pi.hole.                0       IN      A       127.0.0.1
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 30 12:33:49 EDT 2023
;; MSG SIZE  rcvd: 52

Debug Token:

pihole -d

# uploaded on 2023-04-30, valid until 2023-05-02
Your debug token is: https://tricorder.pi-hole.net/BYLabQqC/
2

If Pi-hole is queried for the domain pi.hole it will answer with the IP address by which is it reachable from the querying machine. This is built in to Pi-hole as standard.

If a non-Pi-hole server is queried for the domain pi.hole it will return a NXDOMAIN.

So querying the domain from your Ubuntu client returned the IP address 192.168.1.88 meaning that the Ubuntu client is ultimately using Pi-hole for DNS and that is the Pi-hole's IP address from the perspective of the Ubuntu client.

Querying the domain from your Pi-hole returned the IP address 127.0.0.1 which means Pi-hole is using itself for DNS. Note that it is better to use a different DNS for the Pi-hole itself (such as an external one) in order to avoid a problem if Pi-hole breaks and is then unable to reach external domains to fix itself or send debug logs, due to the very problem it is trying to fix.

At the time you were unable to resolve pi.hole it implies that your clients and the Pi-hole were using a different DNS server. I suspect this was given out by your router prior to your changing the router's upsteam DNS to be your Pi-hole.

So until it expired your clients and your Pi-hole were using the previous setting and hence unable to resolve pi.hole. As the leases were renewed the Pi-hole address was now being used as the DNS and so pi.hole could now be resolved.

How are you liking your Pi-hole now that it's working? Are you seeing queries appear in the Query Log? Hopefully all working great now.

2 Likes
3

Thanks @chrislph for the explanation. I can't remember exactly the sequence of events when I setup the PiHole a week ago. But your explanation about the timeout of the cached DNS response at the client side is plausible. Indeed I forgot to flush the DNS client cache when I switched upstream DNS.

Note that it is better to use a different DNS for the Pi-hole itself (such as an external one) in order to avoid a problem if Pi-hole breaks and is then unable to reach external domains to fix itself or send debug logs, due to the very problem it is trying to fix.

Can you please elaborate a bit more? My router is configured with the PiHole host 192.168.1.88 as the only static DNS address. For now I have only one PiHole server. If I configure the Pihole host (Debian 11 stable) /etc/resolv.conf to use an external DNS such as nameserver 8.8.8.8 instead of PiHole itself. When the router send a DNS requests to the PiHole host, would the host forward the request to 8.8.8.8 bypassing the PiHole service?

How are you liking your Pi-hole now that it's working? Are you seeing queries appear in the Query Log?

It is working great. Once I get familiarized, I will install PiHole for friends and relatives. I have reviewed the logs and add some regex rules. For example

(self|teams)\.events\.data\.microsoft\.com

and surprisingly, it looks like I can continue working as before. Not sure what those requests are for and there are thousands of them per day. I am preparing to add High Availability. Using 2 PiHoles. I hesitates between 2 approaches for DNS failover:

  • Either using a failover clustering service Keepalived as described in Pi-hole failover using Gravity Sync and Keepalived

  • or simply configuring my router (with DDWRT firmware) with two local IP addresses of Pihole1 and Pihole2. Didn't test yet but it appears that the router failover within 5 seconds when DNS resolution fails. So this seems simpler than the solution using the Keepalived service

If you have any advice, I'd greatly appreciate.

4

I think some others here have taken this approach and it works well. I'm sure someone will reply if they're doing this.

My own approach is more of a manual intervention – I have a single standard /24 subnet and have the Pi-hole DHCP configured to hand out the lower half (with some space for static IPs below that) and that's enough for the number of clients I need. The router DHCP is configured to hand out the upper half and is normally disabled. I've also got some firewall rules on the router which allows only the Pi-hole to talk DNS externally.

In the event of any problem or downtime needed for the Pi-hole, with the Pi-hole offline I enable the router's DHCP and enable some bypass rules in the firewall to allow the router to talk DNS externally. Any clients that need to be networking can renew their lease to get a working connection.

It's not exactly advanced or automatic but it does give a clean and quick way of arranging (or dealing with) Pi-hole downtime using just a single Pi-hole and without annoyances like IP clashes. If the number of clients needed was more than ~115 then I'd probably use a /23 for everything in order to keep things talking internally without drama.

If you get your approach working it's worth putting a post in Community Help if you can, that way someone in future will see it and can use it as a guide.

No, the Pi-hole will always send queries from clients, which are using it as their DNS resolver, to the upstream server or servers configured in Settings > DNS.

The Pi-hole OS itself is just another machine that can be configure to use any DNS service, eg as you say via /etc/resolv.conf. There's nothing to stop Pi-hole using itself for DNS, eg as 127.0.0.1 or via its 192.168 address.

However if Pi-hole breaks and stops resolving, the OS won't be able to reach external sites like github or pi-hole.net in order to download updates or post debug logs. Another problem might be that an adlist includes a site which Pi-hole's own OS needs, essentially blocking itself from getting updates.

Therefore it's best to not use Pi-hole as the DNS for it's own OS, and instead use something "out of band" that you trust such as 9.9.9.9 or your ISP's DNS.

I guess if you have two Pi-holes in a resilient setup you could use Pi-hole A as Pi-hole B's DNS, and vice versa. That might fix the issue where one breaks, but wouldn't fix the issue where an adlist blocks a key domain, so I'd be inclined to keep them both using a trusted third-party DNS

5

Hi @chrislph

Your setting looks really complex. Any reason you prefer to use PiHole for DHCP?

In my case, DHCP is done at the router see screenshot. The PiHole host got it static IP 192.168.1.88 from the router via DHCP reservation based on its MAC address. I could as well configure Debian to assign static IP. But it is simpler by DHCP reservation from the router.

For now I don't have redundant PiHole instances. So in case the PiHole is in trouble, I just need to change the Static DNS 1 value to a public DNS server. Then reboot the router.

Router_DHCP
Router_DHCP512×547 45.8 KB

6

In practice it just works and only takes a couple of minutes to switch if the Pi-hole is offline. I'm not running a large network here so that helps. For a larger network (eg a small company, lots of clients) it would be quite painful to use this approach for sure.

It's friendlier and more up to date than my router, and it's a simple way to let Pi-hole see hostnames. I'm not using Pi-hole as an upstream for the router. I'm using Pi-hole and Unbound instead of the router DNS.

1 Like
7

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