This is on a docker install of 6.0.4 on a p3B and on a proxmox lxc clean vanilla install.
I have a domain, mydomain.com. All the machines on the local network resolve fine now I have disabled IPv6. However I have a few machines on the internet with external IPs. Before upgrading to 6.0.4 if I try to go to, say, www2.mydomain.com my machine happily went there even though it has an external IP address.
So the DNS request appears to not be forwarded when the pihole cannot recognise it.
I see it fine on my phone when it is on data.
I can fix it by adding a local DNS record for those domains but that seems crazy. I have unticked both the "Never forward" options but it made no difference.
services:
pihole:
container_name: pihole
image: pihole/pihole:latest
# For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
network_mode: host
environment:
TZ: 'Europe/London'
volumes:
- './etc-pihole:/etc/pihole'
# I have one local.conf file in there which pushes out a second DNS to avoid the
# android sticking 8.8.8.8 in as a backup problem (see link below)
- './etc-dnsmasq.d:/etc/dnsmasq.d'
- './backups-tmp:/backup'
cap_add:
- NET_ADMIN # Required if you are using Pi-hole as your DHCP server, else not needed
restart: unless-stopped
Thanks. But I should also note that the exact same effect is achieved on a scripted vanilla install in a proxmox lxc in testing.
When configuring a local/search domain, Pi-hole v6 will enforce that it is only used locally, so DNS requests for associated names will not leak to public DNS servers, while at the same time reducing DNS traffic to public DNS servers that those servers won't be able to resolve anyway.
Usually, you'd use one of the domains reserved for private network usage, like .internal, .lan or .home.arpa.
In your case, you are using a public domain, mydomain.com.
Using a public domain as local domain may result in unexpected results when you then want local names to resolve to private range IPs.
As you shadow public DNS records, you have to be careful to define all relevant DNS records. If you don't, lookups for a local domain may return a private IPv4 along with a public IPv6.
By keeping lookups for domains configured as Pi-hole's domain local, Pi-hole v6 now prevents those unexpected and unwanted resolution results.
To deal with your requirement of your public exposed domains to still resolve publically, you could use a subdomain of your local domain as Pi-hole's domain, e.g. home.mydomain.com.
That way, domains like nas.home.mydomain.com would be strictly subject to local resolution, and www2.mydomain.com would resolve publically, while you still may opt to shadow that with Local DNS records held by Pi-hole if required.
I think I am making it work - I have made a CNAME for myserver.mydomain.com which targets myserver.internal and set up Caddy to respond to both myserver.mydomain.com and myserver.internal. Fingers crossed but it is working. Certainly no mysterious extra DNS has appeared in the last 30 minutes and it usually has by now.
A postscript to this. The pihole 6 failed again with the mysterious extra DNS so I went to a backup of my pihole5 install and that got everything working properly. In the process I learned a bit more about the way to set things up as I tried to get everything in to the dnsmasq.d files and nothing in the interface. So I ended up with a completely new but reliable setup. It was running in docker on a proxmox lxc because this was the easiest way to get pihole5 working.
In all the troubleshooting of my new pihole6 I learned quite a lot:
Firefox hangs on to cached DNS like a beast. about:networking#dns gives a handy "Clear DNS Cache" button. But that is not enough.
Windows hangs on to the DNS cache too - even harder - you need to open an administrator console and run ipconfig /flushdns with elevated privileges to get it clean
Firefox mobile is hopeless too - you need to Clear data and start again
Testing on different browsers is very helpful to find where the real problem is
Ping Tools on android is very helpful
CNAME records are very useful - but the pihole must know (own) the name if it is going to work. (Before I had specified a lot of IP addresses but now I only do that for my three fixed IPs - gateway, pihole and promox.)
changing to domain name ".internal" has helped with troubleshooting, but I actually don't think I needed to do it. I am not going back though. It took a long time to rootle out all the places it was hard coded. Although names happily add .internal when I "ping machine" or "nslookup machine" I get 'machine.internal', but some devices refuse to accept "machine" - all my tasmota sockets need mqtt.internal not mqtt for example.
I never got to the bottom of why I was getting a secondary DNS appearing on my phone. I have not seen it since I wiped Firefox and was too stupid to be testing with another browser at that time. So maybe it was that.
Anyhow...
I couldn't believe that pihole6 was the problem so set about trying it again. I installed on the same machine with docker and configured pihole.toml very carefully in an effort to keep all of the config in there (which worked apart from the whitelisted domains which I think go in to the database.
I switched over and have had no problems at all other than the pihole6 in a docker container reporting high processor use even though the VM has about 0.1% CPU utilisation and top in the pihole container says average utilisation is 0.3%. That is for another thread.