2
2
read 9 min
Dec 2020
1 / 20
Dec 2020
Feb 2021
jamesg2254
Dec 2020

Hi everyone,

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).

Expected Behaviour:

Local DNS always resolves on iOS devices to internal ip addresses.

Actual Behaviour:

Local DNS resolves first time and then fails and the query is forwarded.

Any help would be greatly appreciated.

2
2
read 9 min
Bucking_HornModerator
Dec 2020

DNS will return DNS records, but never any web page.
Are you saying that Cloudflare's DNS servers are answering DNS requests with your router's IP?

I guess you are using mydomainX.com as a placeholder for some other domain names, but would those be publically registered domains?

Can you show some log output from /var/log/pihole.log for both some lookups answered locally as well as some of those unexpectedly forwarded to Cloudflare?

jamesg2254
Dec 2020

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[2352]: query[type=65] freepbx.mydomain.org.uk from 192.168.30.251
Dec 6 16:48:04 dnsmasq[2352]: forwarded freepbx.mydomain.org.uk to 1.0.0.3
Dec 6 16:48:04 dnsmasq[2352]: query[A] freepbx.mydomain.org.uk from 192.168.30.251
Dec 6 16:48:04 dnsmasq[2352]: /etc/pihole/custom.list freepbx.mydomain.org.uk is 192.168.40.2
19 days later
jamesg2254
Dec 2020

Ahh I see, thank you for your response. Do you know if pihole local resolution support will be coming with time when the DNS record type is more standardised?

Dandymon
Dec 2020

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
Dan

image
image1792×820 161 KB

jfbModerator
Dec 2020
Dandymon
Dec 2020

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?

jfbModerator
Dec 2020

The OTHER query cannot be resolved, so it isn't in a cache, thus it is forwarded to an upstream resolver, where it is again not resolved. The A query was resolved and has a TTL and is in cache.

Dandymon
Dec 2020

Right, I see!
I’ve found a similar problem in

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 :confused:)

Thanks
Dan

DL6ERDeveloper
Dec 2020

Yes!

Pi-hole supports query-type dependent regex blocking.

A regex like

.;querytype=OTHER

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.

Dandymon
Dec 2020

image
image1435×663 133 KB

Bloody excellent!!
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]

Dandymon
Dec 2020

Forgot to add; in general, thanks to all of you for your time developing the platform

jfbModerator
Dec 2020

I don't think IOS is using secure DNS. If it were, you would not see any queries from the IOS device - they would go directly to the secure DNS server and bypass Pi-hole.

Dandymon
Dec 2020

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.

Dandymon
Dec 2020

https://chromestatus.com/feature/5948056459542528
I’ve done some more reading and I think I understand now what’s going on. I’m writing this for anyone else confused as I was.

Normal DNS:
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 12.34.56.78, user connects to 12.34.56.78 with GET request asking for www.msn.com, the server at 12.34.56.78 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 12.34.56.78, 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.

Happy to be corrected.
Dan

DL6ERDeveloper
Dec 2020

Yes, add the following to a file /etc/dnsmasq.d/99-record.conf:

dumpfile=/etc/pihole/dump.pcap

(or any other location you prefer), in addition to

dumpmask=<mask>

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

dumpfile=/etc/pihole/dump.pcap
dumpmask=0x00ff
jamesg2254
Dec 2020

This is great! Whilst I know this is only a temporary solution until the type is assigned in Pi-hole but I'm more than happy to use this in the meantime and then update when needed. Thanks everyone.

20 days later
jamesg2254
Jan 2021

In the latest release I updated the regex to:

.;querytype=HTTPS

to continue to block these queries from iOS devices. Just thought this may help anyone in the future.

21 days later

Closed on Feb 10, 2021

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.


Want to read more? Browse other topics in Help or view latest topics.