I am running pihole in a docker container on a Synology NAS. The hostname of the Synology NAS is "server" and its IPv4 address for eth0 is 192.168.1.101 and eth1 is 192.168.1.103. If I "dig" from another machine on my local network using either IPv4 or IPv6 the reply for "server" should be 192.168.1.101.
Actual Behaviour:
If I "dig" via ipv4:
dig server @192.168.1.101
; <<>> DiG 9.18.1-1ubuntu1.3-Ubuntu <<>> server @192.168.1.101
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40007
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;server. IN A
;; ANSWER SECTION:
server. 0 IN A 192.168.1.101
;; Query time: 0 msec
;; SERVER: 192.168.1.101#53(192.168.1.101) (UDP)
;; WHEN: Wed Mar 01 20:44:07 PST 2023
;; MSG SIZE rcvd: 51
This is exactly what I want: I want "server" to resolve to 192.168.1.101.
However, if I "dig" using IPv6, I get a different answer:
dig server @pihole
; <<>> DiG 9.18.1-1ubuntu1.3-Ubuntu <<>> server @pihole
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56137
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;server. IN A
;; ANSWER SECTION:
server. 0 IN A 127.0.0.1
server. 0 IN A 192.168.1.101
;; Query time: 4 msec
;; SERVER: 2001:XXX:XXXX:XXXX:XXX:XXXX:XXXX:4ecb#53(pihole) (UDP)
;; WHEN: Wed Mar 01 20:43:46 PST 2023
;; MSG SIZE rcvd: 67
Machines on my network that are using IPv6 preferentially are getting 127.0.0.1 as an IP address for "server", which of course doesn't work.
"server" does not appear in the file /etc/hosts:
# Any manual change will be lost if the host name is changed or system upgrades.
127.0.0.1 localhost
::1 localhost
I am pretty new to docker and pihole so I'm not even sure how to get to pihole.log except through the web interface.
In the web interface when I tail pihole.log and do the above queries I see:
Mar 2 17:00:16: query[A] server from 192.168.1.102
Mar 2 17:00:16: /etc/pihole/custom.list server is 192.168.1.101
when I use IPv4 and I see:
Mar 2 17:00:50: query[A] server from 2001:XXX:XXXX:XXXX:XXXX:XXXX:XXXX:9fd2
Mar 2 17:00:50: /etc/hosts server is 127.0.0.1
Mar 2 17:00:50: /etc/pihole/custom.list server is 192.168.1.101
when I use IPv6.
Now, once upon a time server was in /etc/hosts but it isn't there now, and I have restarted the DNS resolver and flushed the network table several times, and even rebooted the whole docker image, and it still has this cached somewhere, but only when querying IPv6.
In case it is relevant, overnight these warnings have appeared in diagnostics:
no address range available for DHCP request via lo
not using configured address 192.168.1.103 because it is in use by the server or relay
not using configured address 192.168.1.101 because it is in use by the server or relay
no address range available for DHCP request via docker0
[Edit: Just checked the docs about the above warnings and it seems they are expected after doing a debug log, so probably not relevant.]
Indeed, that second log excerpt does look strange.
(EDIT: And as you've found out already, those warnings can be ignored if they don't appear elsewhere. )
So I finally figured out how to go "into" the container. That original /etc/hosts I posted was from the NAS running Docker. I naively thought that the container would get "live updates" for outside files like that but I guess that's not the case:
rts@server:~$ sudo docker exec -it 73676cb601ee cat /etc/hosts
# Any manual change will be lost if the host name is changed or system upgrades.
127.0.0.1 localhost
::1 localhost
127.0.0.1 server
::1 server
rts@server:~$ ls -l /etc/hosts
-rw-r--r-- 1 root root 116 Mar 1 19:39 /etc/hosts
rts@server:~$ sudo docker exec -it 73676cb601ee ls -l /etc/hosts
-rw-r--r-- 1 root root 145 Feb 25 22:46 /etc/hosts
So inside the container it was still looking at an "old" (or cached?) /etc/hosts... but only for IPv6?
Anyway, I went and shutdown/restarted the container (again!) and lo-and-behold:
rts@server:~$ sudo docker exec -it 73676cb601ee cat /etc/hosts
# Any manual change will be lost if the host name is changed or system upgrades.
127.0.0.1 localhost
::1 localhost
and finally
dig server @2001:xxxxxx
; <<>> DiG 9.18.1-1ubuntu1.3-Ubuntu <<>> server @2001:xxxxx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6731
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;server. IN A
;; ANSWER SECTION:
server. 0 IN A 192.168.1.101
;; Query time: 0 msec
;; SERVER: 2001:xxxx) (UDP)
;; WHEN: Thu Mar 02 10:51:44 PST 2023
;; MSG SIZE rcvd: 51
Success, and the machines on my network that are using IPv6 preferentially can find server again.
ALTHOUGH, one weird thing now that I'm not too worried about:
$ dig server @pihole
dig: couldn't get address for 'pihole': failure
This is, to some degree (more on that below), expected. When you make an IPv4 query, the query can be "localized" to the interface it arrived on. man dnsmasq says about this feature:
Return answers to DNS queries from /etc/hosts and --interface-name and --dynamic-host which depend on the interface over which the query was received. If a name has more than one address associated with it, and at least one of those addresses is on the same subnet as the interface to which the query was sent, then return only the address(es) on that subnet and return all the available addresses otherwise. This allows for a server to have multiple addresses in /etc/hosts corresponding to each of its interfaces, and hosts will get the correct address based on which network they are attached to. Currently this facility is limited to IPv4.
What this is unclear about is that this is a feature is not only limited to queries of type A query type but also to cases where a query arrives over IPv4. Hence, it is expected that no localization happens when the query arrives on IPv6. In this case, every IP that is available is returned, hoping for the client to be able to pick the right one.
I see you already found what I was going to suggest here:
In my original post and in my bash history I was using dig server @pihole, and that worked. Now neither pihole nor pi.hole work, but I'm not too fussed about that.
$ dig server @pihole
dig: couldn't get address for 'pihole': failure
$ dig server @pi.hole
dig: couldn't get address for 'pi.hole': not found
Replying to pi.hole is hard-coded into FTL and should always work when Pi-hole is able to determine the address of the interface a query is arriving on. This may be affected by your particular docker configuration.
As for your hosts file, I think what you've observe is specific to Docker's host network mode.
Normally, a container doesn't see the host's /etc/hosts at all.
But with host mode, Docker passes a copy of the local hosts file into the container at startup. I'm not sure under what circumstances Dcker would update that file within the container, or whether it could be expected to be updated at all.
You may want to consult Docker's documentation and support for more accurate details.
Huh. Not sure what to tell you, but after coming back to this PC in the evening and having changed nothing (except to wake the PC from suspend), both [at]pihole and [at]pi.hole now work as expected.
In case it still matters, here's the output of dig A @pi.hole
dig A @pi.hole
; <<>> DiG 9.18.1-1ubuntu1.3-Ubuntu <<>> A @pi.hole
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52076
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 57229 IN NS a.root-servers.net.
. 57229 IN NS b.root-servers.net.
. 57229 IN NS c.root-servers.net.
. 57229 IN NS d.root-servers.net.
. 57229 IN NS e.root-servers.net.
. 57229 IN NS f.root-servers.net.
. 57229 IN NS g.root-servers.net.
. 57229 IN NS h.root-servers.net.
. 57229 IN NS i.root-servers.net.
. 57229 IN NS j.root-servers.net.
. 57229 IN NS k.root-servers.net.
. 57229 IN NS l.root-servers.net.
. 57229 IN NS m.root-servers.net.
;; Query time: 8 msec
;; SERVER: 2001:xxxxxxx:4ecc#53(pi.hole) (UDP)
;; WHEN: Thu Mar 02 20:49:18 PST 2023
;; MSG SIZE rcvd: 239
This kind of makes me believe that your PC wasn't using Pi-hole before or (less obvious) wasn't using your Pi-hole as exclusive DNS server. So the query for pi.hole may simply have been sent elsewhere to some destination that wasn't aware who, where or what pi.hole is.
)