My Pi Hole is installed in a Docker container. The docker-compose.yml file is the following:
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
ports:
- "7553:53/tcp"
- "7553:53/udp"
- "7567:67/udp"
- "7580:80/tcp"
- "7443:443/tcp"
dns:
- 127.0.0.1
- 1.1.1.1
environment:
TZ: 'Europe/Madrid'
DNS1: 1.1.1.1
# 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/'
# Recommended but not required (DHCP needs NET_ADMIN)
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
cap_add:
- NET_ADMIN
restart: unless-stopped
What I tried so far
From my other devices ping to my Pi Hole server (192.168.1.75) - it works.
From my Pi Hole console: nslookup google.es - it works
That's not going to work.
You are publishing Pi-hole's ports on different host ports.
While you could still connect to Pi-hole's UI by supplying your custom host port in the URL (e.g. via http://pi.hole:7580), DNS and DHCP protocols require your clients to use ports 53 and 67, respectively.
So your clients are sending DNS requests to your Docker host's port 53, but your Docker host is listening on port 7553.
You must publish the mandatory ports for DNS and DHCP protocols (e.g. "53:53/udp").
Provided you correctly changed all port mappings and did restart your Pi-hole container, what's the ouput of the following commands, run from a client:
Restarted Pi Hole container twice, running: docker-compose stop & docker-compose up --detach
Tried both commands from a Windows 10 PC, and both DNS requests times out.
nslookup flurry.com
DNS request timed out.
timeout was 2 seconds.
Servidor: UnKnown
Address: 192.168.1.75
DNS request timed out.
timeout was 2 seconds.
My Current 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
ports:
- "53:53/tcp"
- "53:53/udp"
- "67:67/udp"
- "80:80/tcp"
- "443:443/tcp"
dns:
- 127.0.0.1
- 1.1.1.1
environment:
TZ: 'Europe/Madrid'
DNS1: 1.1.1.1
DNS2: 1.0.0.1
# 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/'
# Recommended but not required (DHCP needs NET_ADMIN)
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
cap_add:
- NET_ADMIN
restart: unless-stopped
Verify that your Docker host system isn't firewalling ports required by Pi-hole.
Since you initially tried to run Pi-hole on different ports, are there perhaps any other DNS servers claiming Pi-hole's ports on the Docker host system?
Though you may be having problems with the fact that you're not using host mode networking, so you need to know if your clients and the docker host are on the same bridge. Networking | Docker Docs
I really have no idea. I just modified the docker-compose.yml file. Everything else has its default values.
According to the Docker & IPTABLES documentation:
By default, all external source IPs are allowed to connect to the Docker host.
Moreover, I haven't specified any networking mode. So the Pi Hole container is attached to docker0 default bridge. Hence I assume that both clients and docker host are on the same bridge.
As pi.hole is known by Pi-hole (and only Pi-hole), nslookup pi.hole should have provided pi.hole as server name (Servidor), along with its IP address as answer.
As it didn't, it seems your DNS requests directed at Pi-hole's host system at 192.168.1.75 are not reaching Pi-hole.
Since you've adjusted your docker-compose and ruled out closed ports in your Docker host system, another process claiming port 53 on the Docker host or your router redirecting DNS traffic are the only remaining causes I can think of.
The latter is less likely, as flurry.com would have been answered with an IP address if your router would indeed redirect to a public DNS server.
I think Ubuntu is employing a systemd-resolve stub resolver by default that could be hogging port 53.
What's the output of the following commands, run from your Ubuntu Docker host:
systemd-resolve --status
resolvectl status
sudo ss -tulpn '( sport = :53 )'
Just a side note: A router could still redirect DNS traffic passing through it to itself or a public DNS server. We've seen a rare few routers misbehaving that way here on the forum.
I consider this unlikely in your case, as you'd seen an IP address for flurry.com in that case, and Pi-hole would have answered 0.0.0.0 (since that domain is blocked).
You observed neither, but a timeout instead.
This is the entire output from the first command - systemd-resolve --status:
Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 2 (eth0)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 1.1.1.1
1.0.0.1
Link 3 (wlan0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 4 (docker0)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 5 (br-953e5b0d1b73)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 16 (br-c8a85562de13)
Current Scopes: none
DefaultRoute setting: no
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
The second one outputs the same
and for the third and last command it outputs nothing, just the table header: Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
And by the way, my 50-cloud-init.yaml file is the following one:
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
eth0:
dhcp4: no
addresses:
- 192.168.1.75/24
gateway4: 192.168.1.1
match:
driver: bcmgenet smsc95xx lan78xx
optional: true
set-name: eth0
nameservers:
addresses: [1.1.1.1, 1.0.0.1]
version: 2
You could check if your RPi is receiving these requests at all.
We need `tcpdump` on your host machine running Pi-hole Docker for this (click for details)
If tcpdump isn't already installed, do so by executing the following commands:
sudo apt-get update
sudo apt-get install tcpdump
From your Pi-hole host, execute the following:
sudo tcpdump -c 14 -n udp port 53
Then, from your Windows client PC, issue the following:
nslookup www.google.com 192.168.1.75
Once issued, you should see some lines appearing on your RPi.
tcpdump will finish executing as soon as having received 14 packets (as per -c 14 ).
Alternatively, you can always press CtrlC to cancel execution of tcpdump.
Does tcpdump register any activities for your nslookup ?
It looks like your requests arrive at the Pi-hole, however, the Pi-hole isn't replying. What is also missing is any requests of your Pi-hole to any upstream servers so my first assumption would be that you still have something (firewall?) blocking outgoing requests on port 53.
Do you see queries on the Pi-hole Query Log at all?
