Just started getting v6 installed, got the dashboard working and serving requests.
However, all requests show as coming from localhost ( pi.hole ) instead of the client from where they originated. This doesn't help w/ logging, tracing, etc.
My compose file is barely different than the plain vanilla one from docs.
# 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:
# DNS Ports
- "53:53/tcp"
- "53:53/udp"
# Default HTTP Port
- "8080:80/tcp"
# Default HTTPs Port. FTL will generate a self-signed certificate
- "8443:443/tcp"
# Uncomment the below if using Pi-hole as your DHCP Server
#- "67:67/udp"
# Uncomment the line below if you are using Pi-hole as your NTP server
#- "123:123/udp"
environment:
# Set the appropriate timezone for your location from
# https://en.wikipedia.org/wiki/List_of_tz_database_time_zones, e.g:
TZ: 'America/Los_Angeles'
# Set a password to access the web interface. Not setting one will result in a random password being assigned
FTLCONF_webserver_api_password: ""
# If using Docker's default `bridge` network setting the dns listening mode should be set to 'all'
FTLCONF_dns_listeningMode: 'all'
DNSMASQ_USER: 'root'
FTLCONF_dns_upstreams: '1.1.1.3;1.0.0.3'
FTLCONF_dns_reply_host_IPv4: '192.168.1.250'
# Volumes store your data between container upgrades
volumes:
# For persisting Pi-hole's databases and common configuration file
- './etc-pihole:/etc/pihole'
# Uncomment the below if you have custom dnsmasq config files that you want to persist. Not needed for most starting fresh with Pi-hole v6. If you're upgrading from v5 you and have used this directory before, you should keep it enabled for the first v6 container start to allow for a complete migration. It can be removed afterwards. Needs environment variable FTLCONF_misc_etc_dnsmasq_d: 'true'
#- './etc-dnsmasq.d:/etc/dnsmasq.d'
# cap_add:
# See https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
# Required if you are using Pi-hole as your DHCP server, else not needed
# - NET_ADMIN
# Required if you are using Pi-hole as your NTP client to be able to set the host's system time
# - SYS_TIME
# Optional, if Pi-hole should get some more processing time
# - SYS_NICE
restart: unless-stopped
Changes I made
- Enable root user (per warning/error I got when this wasn't there)
- Set upstreams to CloudFlare's family servers (this is serving all machines on my family's home network)
- Set reply host to previous value of
ServerIP from v5.
PiHole creates its default bridge network (this is where I believe the problem is) and everything works just fine.
I've tried setting up macvlan and host and have yet to be successful or find a working v6 config anywhere.
What's a guy gotta do to host pihole in docker and get LAN name resolution to work in the logs & clients view of the dashboard?
Can you send a picture of some sample queries? Specifically looking for the IP addresses of the clients.
Pi-hole doesn't create any networks - your Docker daemon does, as per your container's configuration.
Are you running Docker on Windows or Mac?
In that case, host or macvlan may not be available, and Docker Desktop may indeed NAT traffic to bridge mode containers.
Yes I meant the YAML used to create the container.
This setup is on a Synology NAS that previously had no problem with v5...
Have the pihole exposed now and fielding requests. Turns out my Synology has both eth0 and ovs_eth0 interfaces; the first one isn't bound to an IP, the second one is. Had to use that interface name.
Now, back to getting resolution working for local IPs...
What I'm after is to get that 192.168.1.152 to actually resolve to the device name.
You'll need to enable conditional forwarding in the pi-hole's DNS settings and point it to your DHCP server. Without conditional forwarding, pi-hole has no idea what hosts map to which IP.
That's what I thought as well; added this conditional fwding value: true,192.168.1.0/24,192.168.1.1, no change - disabled "never forward reverse lookups for private IPs", no change.
1.1 is my router and DHCP server
Can you confirm that the pi-hole is asking your router for PTR records? You should be able to find them in the query log.
Let's ask your router at 192.168.1.1 if it knows a name for that IP.
Please share the output of:
nslookup 192.168.1.152 192.168.1.1
seems like we're honing in on something....
$ nslookup 192.168.1.152 192.168.1.1
** server can't find 152.1.168.192.in-addr.arpa: NXDOMAIN
My router is a Netgear Orbi 850 - I'll start researching if there's a way to enable this. Seems like might be in the same boat as others where the Router doesn't actually serve DNS requests for the local network. To me this is odd, since I can use named hosts to get to places on the network.... 
Let's verify that.
For such a named host, what's the output of:
nslookup namedhost 192.168.1.1
where you substitute namedhost with a name you expect your router to know.
>nslookup snas 192.168.1.1
Server: UnKnown
Address: 192.168.1.1
Name: snas
Address: 192.168.1.144
and the reverse
>nslookup 192.168.1.144 192.168.1.1
Server: UnKnown
Address: 192.168.1.1
Name: snas
Address: 192.168.1.144
checking if pi.hole can do the same
>nslookup 192.168.1.144 192.168.1.250
Server: pi.hole
Address: 192.168.1.250
Name: snas
Address: 192.168.1.144
appears it can but
when i use .152 (address of this PC), it gets
>nslookup 192.168.1.152 192.168.1.250
Server: pi.hole
Address: 192.168.1.250
*** pi.hole can't find 192.168.1.152: Non-existent domain
So in general, your router is capable of providing local name resolution for local hostnames as well as for reverse lookups, but fails to do so for specific IP addresses.
That would be normal for devices that have been assigned a static IP on the device itself, as those wouldn't register with your router.
The easiest way to allow them to resolve would be to create the respective Local DNS records within Pi-hole.
Well shoot that stinks - I have 90 devices on my network so really was hoping for something more automatic.
Related question
I set my router ( 192.168.1.1 ) to have its DNS records as 192.168.1.250 (my pi.hole instance) and 1.1.1.3 (cloudflare in case the pi.hole is down/lagging).
When I look at my ph query logs, I see 99% of requests coming from my router and not the individual clients. My expectation was that by setting the DNS records in my router, it would "tell" clients that connect to the router that they should be using those values as their DNS. But it seems that the clients are simply asking the router for DNS and the router is asking pi.hole.
Is there a way to avoid having to manually set pi.hole as the DNS server on every single device on my network but have them directly hit the pi.hole so the logs show the real client making the request?
This will at least help me to start building those local DNS records by doing so right from the logs.
If your devices are on static IPs, no. This is what DHCP is meant to do. I would ask myself if I truly need static IPs for these 90+ devices, if not, consider switching them to DHCP and all of these problems will resolve themselves.
As a rule of thumb, you generally only set servers to static IPs. All client devices get DHCP, with an optional static lease to prevent the IP from changing.
And you really have manually configured static IPs on each of the devices, apart from your snas/192.168.1.144?
Did you configure that 192.168.1.250 IP manually on the device that carries that IP? What kind of device is it?
That would indicate that you have configured your router to use Pi-hole as its upstream DNS server (commonly, a WAN/Internet kind of setting), as opposed to configuring it to distribute your Pi-hole's IPv4 to its clients vai DHCP (commonly, a LAN/DHCP kind of setting).
In either configuration, DNS requests will be filtered by Pi-hole, but you only would be able to attribute DNS requests to individual clients with the latter configuration.
