I'm using Pi-hole as an internal DNS server for my clients and I'm running resources on another server that are internally and externally available on the same domain name (split-brain DNS). I've created a /etc/dnsmasq.d/domain.tld.conf file containing my internal DNS records like:
address=/server.domain.tld/192.168.100.100
server.domain.tld is also externally available with my internet IP. Half of the time, Pi-hole answers to the client with the internal 192.168.100.100 IP for server.domain.tld, but the other half requests are forwarded to the forwarder DNS servers and my internet IP is returned. Since my router by default doesn't accept hairpin routes, this obviously doesn't work alright.
I've tried to add server.domain.tld and domain.tld to 'Local DNS --> DNS Records' which kind of makes it better, but not completely. I've also limited Pi-hole to 127.0.0.1 as it's DNS server. Is there a way to somehow make Pi-hole/DNSmasq authoritative for the domain to that it doesn't passes requests for that particular domain to the forwarder DNS servers?
Could you show sample lines for resolution of your local IP as well as your public IP each from /var/log/pihole.log ?
Also, please upload a debug log and post just the token that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
I see.
I should have been more specific with my question.
The more precise question would have been:
I suppose all forwarded DNS requests for your local*.domain.tlddomains are query[type=65] , whereas query[A] requests would return the local IP?
And still important:
This is happening because you have not defined AAAA records for your *.domain.tld. If there is indeed no IPv6 address for your domains, neither private nor public, you could leave it as is. Otherwise, create the respective IPv6 address entries.
I suppose all forwarded DNS requests for your local*.domain.tlddomains are query[type=65] , whereas query[A] requests would return the local IP?
It looks like the local IP is correctly returned for those records, yes.
Also, would any of those forwarded DNS requests ever return a public IP ?
Only for home.domain.tld, as it's the only record that is also available in the public domain as the CNAME domain.mooo.com.
Sep 19 19:14:27 dnsmasq[1078]: query[A] nas.domain.tld from 192.168.50.200
Sep 19 19:14:27 dnsmasq[1078]: config nas.domain.tld is 192.168.50.200
Sep 19 19:14:27 dnsmasq[1078]: query[AAAA] nas.domain.tld from 192.168.50.200
Sep 19 19:14:27 dnsmasq[1078]: forwarded nas.domain.tld to 1.1.1.1
Sep 19 19:14:27 dnsmasq[1078]: reply nas.domain.tld is NODATA-IPv6
Sep 19 19:14:27 dnsmasq[1078]: query[PTR] 200.50.168.192.in-addr.arpa from 192.168.50.200
Sep 19 19:14:27 dnsmasq[1078]: config 200.50.168.192.in-addr.arpa is
The Pi-hole container used to work as expected in a previous install of Ubuntu 18 LTS as a hosts, but since a server crash now is running in Ubuntu 20 LTS. I'm not sure if I ever disabled IPv6 on Ubuntu 18, is that maybe relevant here?
When I check the notes for the local DNS settings:
The order of locally defined DNS records is:
1. The device's host name and `pi.hole`
2. Configured in a config file in `/etc/dnsmasq.d/`
3. Read from `/etc/hosts`
4. Read from the "Local (custom) DNS" list (stored in `/etc/pihole/custom.list` )
Only the first record will trigger an address-to-name association.
That doesn't seem to be the case. Even though there is an existing /etc/dnsmasq.d/ config with a match for the record, Pi-Hole still forwards the request (sometimes). And when that record also exists in /etc/pihole/custom.list, then the number of forwards are reduced, but still some requests are forwarded. And when a record for it is present in the external DNS, that record is cached and causes issues in my internal LAN.
Unfortunately I cannot blacklist domain.tld or home.domain.tld, as that will break resolving entirely.
Those lines do not contain any query[type=65] with its reply, so there is no way to tell whether the answer ultimately would be a pubic IP.
Local DNS records are types A (for IPv4) , AAAA (for IPv6) or CNAME, so your observation would be expected if those forwarded requests are type=65 (HTTPS Binding).
Ok, after doing some research what type=65 actually means I understand that by this way, iOS/macOS devices are able to do a secure (https) query to Pi-hole, thus bypassing any local A/AAA/CNAME records, thus having mixes replies in my case?
Looking at pihole.log, indeed only type=65 requests are being forwarded. I also read that this can be resolved by blocking using a RegEx filter:
.;querytype=HTTPS
Is this the correct way? Or should I limit to only home.domain.tld? domain.tld;querytype=HTTPS
As of now, I've added domain.tld;querytype=HTTPS as a RegEx filter to the blocking list, and that seems to have solved my issue for the last couple of days. Also changing from Cloudflare to OpenDNS already seemed to have made it better (OpenDNS doesn't reply to type=65/HTTPS DNS requests?) Not entirely sure about that last bit though.
Thanks!