Pi-Hole Admin page only accessible through http://ip/admin

systemd-resolve --status

?

Here is the results of my docker-compose.yml

version: "3"

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    # For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
      - "80:80/tcp"
      - "443:443"
    environment:
      TZ: 'America/Chicago'
      # WEBPASSWORD: 'set a secure password here or it will be random'
    # Volumes store your data between container upgrades
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    restart: unless-stopped

Thats a weird search domain I've never seen before.

EDIT: Ow its seems normal if no search/suffix domain is supplied/configured:

pi@ph5b:~ $ man resolv.conf
[..]
       search Search list for host-name lookup.
              By  default,  the search list contains one entry, the local
              domain name.  It is determined from the local hostname  re‐
              turned by gethostname(2); the local domain name is taken to
              be everything after the first '.'.  Finally, if  the  host‐
              name  does not contain a '.', the root domain is assumed as
              the local domain name.

Wait...

You don't need to do this for private IP addresses (like 192.168.50.1).

Your debug log shows your Pi-hole is using 192.168.112.2.
It also shows 2 devices making queries to Pi-hole: 192.168.50.104 and 192.168.50.1.

Are you sure the Pi-hole IP is on the same subnet of your other machines?

Good point.

My LAN subnet is 50 so 192.168.50. The machine the Pi-hole docker container is running on is at 192.168.50.3.

I thought this would be expected since Pi-hole is running in docker? The docker container would have its own network that I forward ports to. My networking knowledge is still in the early stages though so I could possibly be misunderstanding something.

I also downloaded chrome and tried using that and got the same results. (I wanted to rule out my browser as the root cause)

Thanks again for all the help everyone.

Sorry, I missed this reply. I saw your other one but I'm still unpacking it. I'm wondering if the router is the cause now.

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Sun 2023-06-25 11:40:29 CDT; 7h ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 485 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18868)
     Memory: 7.0M
        CPU: 2.424s
     CGroup: /system.slice/systemd-resolved.service
             └─485 /lib/systemd/systemd-resolved

Jun 25 11:40:29 shraan systemd-resolved[485]: Using system hostname 'shraan'.
Jun 25 11:40:29 shraan systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Jun 25 11:40:33 shraan systemd-resolved[485]: wlp59s0: Bus client set default route setting: yes
Jun 25 11:40:33 shraan systemd-resolved[485]: wlp59s0: Bus client set DNS server list to: 192.168.50.3
Jun 25 11:40:33 shraan systemd-resolved[485]: wlp59s0: Bus client set search domain list to: XXXX.io
Jun 25 12:14:41 shraan systemd-resolved[485]: wlp59s0: Bus client reset search domain list.
Jun 25 12:24:33 shraan systemd-resolved[485]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.50.3.
Jun 25 12:29:01 shraan systemd-resolved[485]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.50.3.
Jun 25 12:51:37 shraan systemd-resolved[485]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.50.3.
Jun 25 15:23:58 shraan systemd-resolved[485]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server 192.168.50.3.

Note: This was ran on a client device that is expecting to use the Pi-hole as the DNS NOT the server running it.

I got this from the ASUS documentation. I am undoing it now. I'm still unpacking the rest of this message.

Is above 192.168.50.3 IP Pi-hole?

Yes that's the IP of the Ubuntu server running Pi-hole.

Edit: Added quote for posterity and readability.

Is it actually Pi-hole thats answering?

dig +short @192.168.50.3 chaos txt version.bind

Eg:

pi@ph5b:~ $ dig +short @10.0.0.4 chaos txt version.bind
"dnsmasq-pi-hole-v2.87rc1"

I ran that in the terminal and got:

"dnsmasq-pi-hole-v2.89-9461807"

When I have ran block test that I mentioned a few posts up I can see my client IP in the Pi-hole logs.

If you run that on that client that couldnt resolve pi.hole via nslookup, I guess this is somehow Docker settings related.
Am not that proficient yet with Docker.
Cant help you with that ... sorry.

EDIT: Ow ps, I should have queried my other Pi that is up to date :wink:

pi@ph5b:~ $ dig +short @10.0.0.2 chaos txt version.bind
"dnsmasq-pi-hole-v2.89-9461807"

I ran that on a machine that couldn't access http://pi.hole/admin

I dual boot so I swapped to windows so that I could rule out the machine.

Running this on a windows client expecting to have Pi-hole as its DNS.

>nslookup pi.hole
Server:  UnKnown
Address:  192.168.50.3

Name:    pi.hole
Address:  0.0.0.0

Depends on the docker network mode you are using.

Usually the default docker network uses 172.17.0.0/16 subnet range.
Using macvlan network, the subnet range should be the same as range used by the host.

I never saw a docker subnet using this range. I'm not saying this is wrong, but it looks unusual/unexpected.

Are you running Docker Desktop?

FYI, equivalent for Windows is (EDIT: ow you can leave out the IP if the client is configured correctly):

nslookup -class=chaos -type=txt version.bind 192.168.50.3

pi@ph5b:~ $ dig +short @10.0.0.2 chaos txt servers.bind
"127.0.0.1#5335 289931 209" "10.0.0.4#53 9086 0"
pi@ph5b:~ $ dig +short @10.0.0.2 chaos txt authors.bind
"Simon Kelley"

I shouldn't be, but that isn't to say I'm not. I have been wrong plenty of times before. The OS is ubuntu server 22.04 so I shouldn't have desktop version. I think I'm going to try wiping docker and reinstalling. I only changed one item in Pi-hole so I won't loose anything by wiping it.

Note: The only setting I changed in Pi-hole was adding a domain name for my router since Asus requires it for some reason. (After rereading my reply I expected future me to get asked that)

Is that the windows equivalent of the previous digg command?

Edit: The result is:

Server:  UnKnown
Address:  192.168.50.3

version.bind    text =

        "dnsmasq-pi-hole-v2.89-9461807"

Yes.
Looks good.
Also mind below:

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