Long time reader but first time posting. I'm having a strange issue with my pihole, and DNS resolutions. I'm using the latest version and have some local DNS entries defined in the web gui (e.g. x.mydomain.com and x.mydomain2.com)
The local DNS resolution for any subdomain of mydomain.com works first time after the cache has been reset. Anytime after that and the query is forwarded onto cloudflare which returnns my routers web page. The strange thing is that this only affects iOS devices. Windows and Andorid devices are fine and not experiencing the issue. I'm not sure if this is a pihole problem or ios issue but as I said the pihole is forwarding the 2nd query.
For the domains that belong to mydomain2.com, the issue is not present and they all resolve ok. The DNS is given out by the router via DHCP and then pihole forwards to cloudflare. Conditional forwarding is enabled so local hostnames without mydomain.com resolve (although i tried disabling this and the isssue still persists).
Local DNS always resolves on iOS devices to internal ip addresses.
Local DNS resolves first time and then fails and the query is forwarded.
Sorry my mistake. The DNS record being returned points to the router because it is also an external fqdn. I am using those domains as placeholders, they need to be internally resolvable and they do resolve externally as well (hence being pointed to the router when the query is forwarded onto cloudflare).
Example from logs:
Dec 6 16:48:04 dnsmasq: query[type=65] freepbx.mydomain.org.uk from 192.168.30.251
Dec 6 16:48:04 dnsmasq: forwarded freepbx.mydomain.org.uk to 220.127.116.11
Dec 6 16:48:04 dnsmasq: query[A] freepbx.mydomain.org.uk from 192.168.30.251
Dec 6 16:48:04 dnsmasq: /etc/pihole/custom.list freepbx.mydomain.org.uk is 192.168.40.2
Mine does this also, exactly this, it’s a real pain. For me I have internal webcams which have a FQDN running on different ports. The addresses resolve fine when I open the app up, but when I close it and open it again, it doesn’t connect anymore. Looking at the network traffic, it seems my phone wants to connect to the 192.168.x.x address when requested, but then re-caches a new external ip after a few seconds.
It definitely is my phone being odd, it doesn’t happen on my Windows laptop. iOS seems to make an additional request that is not an A record to the DNS server after correctly resolving it first time. Because it’s not an A record, pihole seems to forward it to google DNS (in my case).
Whilst this is an iOS facet (sending these additional obscure DNSrequests), I think it’s also a pihole bug. The OTHER flag is new, is it implementing the lookup correctly to serve the local DNS correctly for ALL protocols/request types?
Or can I setup pihole to catch these OTHER requests and serve them from the local DNS lookup as per the A records?
Thanks jfb, very speedy reply, but it doesn’t really solve the problem (not sure you were implying it would or not).
If you look at my image I’ve attached in the post, you’ll see that the DNS lookup is replying with the cached address for the A lookup (the local 192.168.x.x address), and is also sending the OTHER request through to dns.google#53.
What you’re seeing in the image is where I’ve accessed the website twice, 5 minutes apart, with each request being two name resolutions, A and OTHER. The bits I’ve blotted out are all the same sub.domain.com and my network IP.
Pihole for some reason isn’t serving the cached local address when the request type is OTHER.
It’s nothing to do with the iphone obfuscating the MAC address or anything.
Any ideas anyone?
So it seems that because iOS is using a secure DNS request in addition to its usual DNS, it is basically receiving two replies.
One which is the standard A type DNS request-response from pihole, and because pihole can’t decipher the secure DNS, a second secure DNS request-reply passed upstream to google.
So my question is thus changed:
Is there a function in pihole to block secure DNS, or do a local lookup? (Because I can’t stop it in iOS )
should block all queries with type OTHER. As this query type is becoming more and more frequent now, we're discussing internally how to go forward. We'll likely just add this new iOS query type as an additional record in the next release of Pi-hole. Note that this regex above will then need to be updated as the type 65 will not be covered by OTHER any longer if it gets its own assigned type.
Thank you very much sir, added and the secondary dns lookup is indeed blocked. THE APP WORKS!
This is very helpful, and puts to bed an issue I’ve been having for the last year. I know it’s a bit of a temp hack but I can’t wait till you guys come up with some secure dns solution, this nearly stopped me using pihole and it wasn’t even a pihole fault.
[Bloody Apple making things safer... grumble grumble]
Ahh, I may have been barking up the wrong tree with the secure dns thing then. It’s just that I’m not running any Betas or anything, plain old stock, so I supposed that it was doing this name resolution in the background as an additive thing to usual DNS.
Whatever is happening, it is somehow getting lookup information in that second OTHER packet because it definitely changes its dns cache when that returns.
I can’t run wireshark on my iPhone so can’t explore there, can pihole capture the packet for me so I can investigate/share?
The fix provided by DL6ER works and when I disable it, the problem comes back, something shifty going on in iOS for sure.
User types www.msn.com, computer makes a DNS request to DNS server asking who “www.msn.com” is, DNS server responds to user it is IP 18.104.22.168, user connects to 22.214.171.124 with GET request asking for www.msn.com, the server at 126.96.36.199 responds with either a web page, 403 error, redirect to another server, push to SSL etc etc.
The OTHER packet I’m seeing is a HTTPSSVC DNS request which is sent in addition to the Normal DNS, this is a new thing that some devices/browsers are doing. Rather than getting pushed around by an HTTP response once you connect to 188.8.131.52, the HTTPSSVC reply contains information about the domain, including other servers you can connect to for secure sites/load balancing/tailored web services from you ip.. all before you actually make that proper connection. I suppose it’s to help alleviate a bit of traffic, help the user’s browser avoid any dns spoofing, basically just stop a Schrödinger’s cat situation.. meaning it has a peek before opening the box.
Yes, add the following to a file /etc/dnsmasq.d/99-record.conf:
(or any other location you prefer), in addition to
where mask specifies which types of packets should be added to the dumpfile. defined above The argument should be the OR of the bitmasks for each type of packet to be dumped: it can be specified in hex by preceding the number with 0x in the normal way.
Each time a packet is written to the dumpfile, we log the packet sequence and the mask representing its type. The current types are:
0x0001 - DNS queries from clients
0x0002 DNS replies to clients
0x0004 - DNS queries to upstream
0x0008 - DNS replies from upstream
0x0010 - queries send upstream for DNSSEC validation
0x0020 - replies to queries for DNSSEC validation
0x0040 - replies to client queries which fail DNSSEC validation
0x0080 replies to queries for DNSSEC validation which fail validation.
If you just want to record everything and later filter this in Wireshark (I typically recommend this) you can just add the two lines