Unable to access admin UI via CNAME

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.

Since you observe issues with Pi-hole's web UI rather than its DNS portion, I've split your post into a separate topic.

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:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

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.

What is missing for me: How do you do this? Using http://pi.hole/admin or are you using a custom hostname for accessing Pi-hole?

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.

Assuming that you've defined those CNAMEs using Pi-hole, could you share the configuration?

Sorry if this isn't what you mean.

The newest update causes the admin panel to toss nxdomain instantly after upgrade rather than after a few minutes.

Thanks, that's exactly what we needed and confirms that the issue is

The behavior before v5.9 (and its beta) was:

Screenshot from 2021-07-10 10-27-07

resulting in

$ dig not.pi.hole
;not.pi.hole.                   IN      A

not.pi.hole.            2       IN      CNAME   pi.hole.
pi.hole.                2       IN      A

where was the IP address stored in setupVars.conf.

The new behavior is

$ dig not.pi.hole
;not.pi.hole.                   IN      A

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 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.

Or add pi.hole as a local DNS record via Web GUI

chrko@ThinkPad-X230:~$ dig not.pihole

; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> not.pihole
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26087
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;not.pihole.			IN	A

not.pihole.		2	IN	CNAME	pi.hole.
pi.hole.		2	IN	A

;; Query time: 5 msec
;; WHEN: Sat Jul 10 12:54:46 CEST 2021
;; MSG SIZE  rcvd: 76

1 Like

I was able to add pi.hole as a dns entry before updating Core to the beta and everything is working as it should now. Thanks for the help.