I'm not 100% sure this is related to my issue but it's a similar end result. I'm running on Ubuntu 21.04 (aware it's not listed as supported, didn't realize when I updated the system, but never ran into any issues till this)
When I update all three parts everything works for about 5 minutes then I'm unable to access the admin panel. As soon as I roll the core back to the current release (leaving FTL and Web on the dev branch) everything goes back to normal and I can access everything again.
Crucially though it does not stop functionality outside of the admin panel and the API. Ads are still blocked and dns resolution still functions but I'm unable to monitor or edit anything till I roll Core back to the non beta version.
If this should be separated please let me know and I'll repost as it's own.
Please upload a debug log and post just the token that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
The token I've been given is p3k5qfk4xw I did it through terminal. I went back to the beta version on Core just beforehand and I was able to refresh the admin panel a few times to see that it was updated in the footer but it was under 2 minutes before chrome started tossing nxdomain at me.
I also grabbed ro69i0bcjn if it helps after rolling Core back to master.
Sorry, missed mentioning that. I have it set up as a subdomain and have a cname record set for it. it's only the pihole subdomain that has issues when this is happening.
Okay, so you have a CNAME record that points to pi.hole ? Yes, this is not covered by our new automated interface-aware reply method.
Before, we added a static record with the IP address found in setupVars.conf to the DNS cache. From here, this wisdom can also be applied when a CNAME path is to be traversed.
The new behavior is to detect that a query for the domain pi.hole comes in and immediately reply with the most suitable IP address - circumventing the cache altogether.
I do not see how both worlds could be stitched together (interface-dependent reply vs. being available in the cache) without more fundamental changes to the cache.
What we could do is adding cache entries for all available addresses to the cache but this would shift the responsibility for picking the most suitable one to the client plus it may not be what most clients expect to receive (they do not expect to receive IPs they cannot reach).
My suggestion at this point is to change your CNAME to an ordinary A/AAAA record that points directly to the Pi-hole. Overall, this will be the better solution but I'm open for any discussions here. Any suggestions are welcomed.
So the cname I have set up goes pi.hole -> subdomain so I'm only ever truly accessing through the subdomain (if that makes sense) I'm not sure if that changes what you're looking at. I likely explained my setup poorly, sorry.
On my network with my setup the pi.hole domain never worked as I have nginx set up to serve multiple things so I never used it until the ability to set the cname was available when I set it up for ease of use when looking into scripts or apps that interface with pihole that way.
Thanks, that's exactly what we needed and confirms that the issue is
The behavior before v5.9 (and its beta) was:
resulting in
$ dig not.pi.hole
[...]
;; QUESTION SECTION:
;not.pi.hole. IN A
;; ANSWER SECTION:
not.pi.hole. 2 IN CNAME pi.hole.
pi.hole. 2 IN A 192.168.2.10
[...]
where 192.168.2.10 was the IP address stored in setupVars.conf.
The new behavior is
$ dig not.pi.hole
[...]
;; QUESTION SECTION:
;not.pi.hole. IN A
;; ANSWER SECTION:
not.pi.hole. 2 IN CNAME pi.hole.
[...]
because there is no pi.hole entry preloaded into the DNS cache (so we can dynamically reply with an interface-dependet address).
You can add
192.168.1.1 pi.hole
(insert the correct IP of your Pi-hole) to the file /etc/hosts of your Pi-hole. This will restore the pre-v5.9 behavior by hard-wiring an address for pi.hole into the cache. It will not be interface-dependent just as in pre-v5.9.
