Hi, I get a 403 error when trying to access the Pi-Hole admin pages through a local domain (http://pi.hole/admin).
I can access the admin fine when using my local ip http://192.168.1.20/admin
I am running pi-hole on a Raspberry pi 2b, using nginx webserver on dietpi.
Can you check the IP address pi.hole resolves to on this client?
Run from a client that fails to access Pi-hole's web UI, what's the output of:
nslookup pi.hole
nslookup pi.hole 192.168.1.20
Server: 192.168.1.20
Address: 192.168.1.20#53
Name: pi.hole
Address: 192.168.1.20
Name: pi.hole
Address: 2a00:23c5:f7a2:201:ba27:ebff:febc:9ced
Also pi.hole itself brings up the nginx holding page, just as it does when you use the IP address. it's just /admin that acts differently
That last one was nslookup pi.hole 192.168.1.20
Here is nslookup pi.hole:
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find pi.hole: NXDOMAIN
You enabled the optional public access block. It contained an info that this also blocks local access when done via GUA IPv6 addresses like in this case. So if you promote IPv6 addresses for your local network, and do not have ULA addresses enabled, then this is the result. Luckily this is all obsolete with Pi-hole v6 
.
Disable the lock like this:
sudo mv /etc/nginx/sites-dietpi/dietpi-pihole-block_public_admin.{on,off}
sudo systemctl restart nginx
Unfortunately that hasn't fixed the problem and I still can't access the pi admin.
I'm not sure that v6 will run on my ancient pi2b 
EDIT: Okay Bucking_Horn found the 2nd reason below, I missed that from your 2nd nslookup output. That explains it very well.
Was there any error when running above commands? And as you mention v6, you are still using v5, don't you?
Can you run the output of:
curl -IL pi.hole/admin/
curl -IL 192.168.1.20/admin/
on the client where access fails?
Pi-hole v6 runs very well on even older RPi models.
I dare to believe that your RPi 2B has still some years to go. 
The machine that ran the nslookup is not using Pi-hole as DNS server, but a local stub resolver at 127.0.0.53.
In general, using a stub resolver to cache DNS replies locally is fine, as long as that stub resolver is forwarding all its DNS traffic to Pi-hole.
Yours isn't using Pi-hole, or else it wouldn't have returned NXDOMAIN for pi.hole.
That would mean that your client can't access http://pi.hole, but http://192.168.1.20/admin/ should work.
You'd have to verify your stub resolver's DNS configuration.
Often, that stub resolver is systemd-resolved.
Run from the machine that failed with NXDOMAIN, what's the output of:
sudo resolvectl status
sudo resolvectl status:
Command not found
results of curl suggested by Michalng
dietpi@DietPi:/etc/nginx/sites-dietpi$ curl -IL pi.hole/admin/
HTTP/1.1 302 Found
Server: nginx
Date: Thu, 27 Feb 2025 13:43:23 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: PHPSESSID=go4dchcl990k50fl0qnk92reqi; path=/; HttpOnly; SameSite=Strict
Location: login.php
X-Pi-hole: The Pi-hole Web interface is working!
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 0
X-Robots-Tag: noindex, nofollow
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: same-origin
Content-Security-Policy: default-src 'self' 'unsafe-inline'
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 27 Feb 2025 13:43:23 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: PHPSESSID=s9jtkmg59i8crpaqkvkac8j7kn; path=/; HttpOnly; SameSite=Strict
X-Pi-hole: The Pi-hole Web interface is working!
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 0
X-Robots-Tag: noindex, nofollow
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: same-origin
Content-Security-Policy: default-src 'self' 'unsafe-inline'
dietpi@DietPi:/etc/nginx/sites-dietpi$ curl -IL 192.168.1.20/admin/
HTTP/1.1 302 Found
Server: nginx
Date: Thu, 27 Feb 2025 13:44:25 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: PHPSESSID=fqu0dfsnogfdfk3p52fp6tnc71; path=/; HttpOnly; SameSite=Strict
Location: login.php
X-Pi-hole: The Pi-hole Web interface is working!
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 0
X-Robots-Tag: noindex, nofollow
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: same-origin
Content-Security-Policy: default-src 'self' 'unsafe-inline'
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 27 Feb 2025 13:44:25 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: PHPSESSID=rbv3gihd2fm2025913v0qfama9; path=/; HttpOnly; SameSite=Strict
X-Pi-hole: The Pi-hole Web interface is working!
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 0
X-Robots-Tag: noindex, nofollow
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: same-origin
Content-Security-Policy: default-src 'self' 'unsafe-inline'
That's good to know. Might just shelve all this and upgrade the pi to save me working on something that just gets undone with that...
You are running these commands on Pi-hole host server it seems? To check why the client with the browser cannot access the Pi-hole web interface, all these commands, starting with nslookup, need to be run on that exact client system where accessing the UI fails from.
Ah, although this system does resolve pi.hole just well, so something does not add up 
. Please verify where you ran the commands.
What client did you run those NXDOMAIN nslookups from ?
You were supposed to run the commands from the problematic client (including mine).
It seems they were run from your Pi-hole machine instead?
Oops!
rob@Rob-Asus-Laptop:~$ curl -IL pi.hole/admin/
curl: (6) Could not resolve host: pi.hole
rob@Rob-Asus-Laptop:~$ curl -IL 192.168.1.20/admin
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Thu, 27 Feb 2025 14:00:58 GMT
Content-Type: text/html
Content-Length: 162
Location: http://192.168.1.20/admin/
Connection: keep-alive
X-Pi-hole: The Pi-hole Web interface is working!
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 0
X-Robots-Tag: noindex, nofollow
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: same-origin
Content-Security-Policy: default-src 'self' 'unsafe-inline'
HTTP/1.1 302 Found
Server: nginx
Date: Thu, 27 Feb 2025 14:00:58 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: PHPSESSID=a4pss7mq4c34bcp9o6v8safdo6; path=/; HttpOnly; SameSite=Strict
Location: login.php
X-Pi-hole: The Pi-hole Web interface is working!
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 0
X-Robots-Tag: noindex, nofollow
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: same-origin
Content-Security-Policy: default-src 'self' 'unsafe-inline'
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 27 Feb 2025 14:00:58 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: PHPSESSID=f0taecr6nttl3k8uol5vi6lsfj; path=/; HttpOnly; SameSite=Strict
X-Pi-hole: The Pi-hole Web interface is working!
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-XSS-Protection: 0
X-Robots-Tag: noindex, nofollow
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: same-origin
Content-Security-Policy: default-src 'self' 'unsafe-inline'
Okay that fits 
. And sudo resolvectl status from that system?
Sorry for the confusion.
the nslookups were from the problematic client:
nslookup pi.hole
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find pi.hole: NXDOMAIN
nslookup pi.hole 192.168.1.20
Server: 192.168.1.20
Address: 192.168.1.20#53
Name: pi.hole
Address: 192.168.1.20
Name: pi.hole
Address: 2a00:23c5:f7a2:201:ba27:ebff:febc:9ced
curl -IL pi.hole/admin/
curl -IL 192.168.1.20/admin/
As updated in previous post.
sudo resolvectl status
[sudo] password for rob:
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (enp3s0f2)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 3 (wlp2s0)
Current Scopes: DNS
Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fe80::<redacted>d6
DNS Servers: 192.168.1.20 fe80::<redacted>d6 fe80::<redacted>ed
DNS Domain: home
Link 4 (docker0)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 5 (br-d843fb2138b9)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 6 (veth58b078b)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Hmm, it is connected via WiFi, right? Pi-hole is in the list of DNS servers, but there are two local-link addresses as well. I guess at most one of them is from the Pi-hole host. Can you check its LLA? Run this one on the DietPi/Pi-hole system:
ip -6 a
fe80::redacted>d6 is probably from your router, who does not know pi.hole (cannot resolve it). In this case, you would need to assure that your router is not sending out router advertisements, or at least does not promote itself as local DNS server with those. Or you configure the upstream DNS of your router to be Pi-hole.
Your stub resolver is using your (Arcadyan?) router's IPv6 for DNS, by-passing Pi-hole.
This happens if your router is advertising its own IPv6 address as DNS server.
You'd have to find a way to configure your router to stop advertising its own IPv6 as DNS server, or to advertise your Pi-hole host machine's IPv6.
You'd have to consult your router's documentation sources on further details for its IPv6 configuration options.
If your router doesn't support configuring IPv6 DNS, you could consider disabling IPv6 altogether, provided you'd not depend on IPv6 for reasons.
If your router doesn't support that either, your IPv6-capable clients will always be able to bypass Pi-hole via IPv6.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a00:23c5:f7a2:201:ba27:ebff:febc:9ced/64 scope global dynamic mngtmpaddr
valid_lft 283sec preferred_lft 103sec
inet6 fe80::ba27:ebff:febc:9ced/64 scope link
valid_lft forever preferred_lft forever
I'll do some digging on the router. I can set a custom IPv6 DNS server, but I thought I had that set up ok...
That output also verifies that the Pi-hole system has the 2nd LLA, not the one used by the client. Giving the router the LLA of the Pi-hole system as IPv6 DNS would work as well, but cleaned is to prevent it from distributing itself as DNS server completely, if possible.