The issue I am facing:
iPhone is requesting DNS-SD PTR record every 4-6 seconds despite NXDOMAIN return for every attempt
Details about my system:
Ubuntu 20.04.4 Hyper-V VM
Using DNSCrypt-Proxy local with forwarded PiHole lookups going through to Cloudflare DNS
No conditional forwarding configured
DNSCrypt is forwarding for internal DNS TLDs serviced by MS DNS
What I have changed since installing Pi-hole:
This is specific to one of two iPhones in the house. I realize this may be related to the device, but I can't find an answer why. I've uninstalled a large number of apps from the phone, turned off background app refresh, reset the network configuration, but nothing comes of it. When the phone is in use, there are no queries, but within 10 seconds of being locked, the queries start and continue without end every 4-6 seconds resulting in thousands of queries per day.
I've tried explicitly blacklisting the query with an NXDOMAIN return, but the phone continues. I've read that it's possible to set the dnsmasq config with a local TTL, which I tried, but that doesn't help. I've tried to add a ptr-record entry in dnsmasq, but that doesn't help.
I have replaced the forwarding configuration to bypass DNSCrypt in the event that was causing the issue, but even with a direct forward to 1.1.1.1, it continues to query every 4-6 seconds.
I continued to troubleshoot, and some articles from Apple talk about Bonjour used for AirPlay and other purposes. Since I already had AirPlay turned off, I looked at Bluetooth. I didn't have anything connected, so I just turned it off. Locked my iPhone and set it aside.
Nothing.
For over 5 minutes, it was finally quiet. I specifically tailed the pihole.log file and grep'd for in-addr.arpa, and there were no requests for the duration of my test. As soon as I brought up the phone to unlock, it sent out one attempt, but I've read that's normal; and I'm okay with a single attempt every once in a while. I turned on Bluetooth, locked the phone, set it aside... back to crazytown. Every 4-6 seconds.
I tried to connect some Bluetooth devices to see if it would make the phone happy, and despite a promising quiet period after the connection, it went back to yelling at the ocean every 4-6 seconds.
It's been 10 minutes since I turned off Bluetooth to write this post, and it's been quiet. I would've never thought Bluetooth for a DNS issue, but I suppose it does rely on some of the same stacks as the network. Anyone want to venture a guess on this? Is this something that would warrant a bug report to Apple, or is this behavior expected?
Continued troubleshooting this issue. Bluetooth still remains the culprit, but I wanted to review DHCP server settings and change some DNS configurations to abide by the DNS-SD "standard" per this site:
I'm using Microsoft DHCP and DNS. The DHCP scope did not have a DNS name configured, as it's intended to service vendor IOT devices and my home wifi to prevent talking back to my internal networks. I configured DHCP option 15 with a domain name for which I'm authoritative both internally and publicly. DNS resolution for this internal domain is handled successfully by my internal DNS resolvers.
I went to DNS and configured the DNS-SD records being searched by my phone. I pointed all of the records to a black hole record resolving to 0.0.0.0. Subsequent PTR record lookups from my management PC showed the records being requested of the PiHole were resolving as expected. However, turning Bluetooth back on resulted in the consistent 4-6 second query of those records, but despite an endpoint being provided (no NXDOMAIN), the phone continued to squawk.
Interesting observation: my wife's phone, also an iPhone, does request similar records, but it seems to be every 5-6 minutes, and the addresses are not the same.
Also, the queries are for seemingly random addresses in the 100.64.0.0/10 range which is apparently a shared address space per IANA RFC 6598. I suspect that's something Apple's programmed in their network stack.
Well, this stinks, but if keeping Bluetooth off fixes the issue, then so be it. Again, if anyone has any points to discuss, please do.
Here's a snippet from just now. 10.100.137.142 is the phone IP. 100.64.0.0/10 is an unallocated range (BOGON?) according to the IANA, so it never resolves to anything. 10.100.137.128/25 is the network range for the external wifi.
Apr 25 16:11:58 dnsmasq[9744]: query[PTR] lb._dns-sd._udp.149.192.66.100.in-addr.arpa from 10.100.137.142
Apr 25 16:11:58 dnsmasq[9744]: forwarded lb._dns-sd._udp.149.192.66.100.in-addr.arpa to 127.0.0.1#5300
Apr 25 16:11:58 dnsmasq[9744]: reply lb._dns-sd._udp.149.192.66.100.in-addr.arpa is NXDOMAIN
Apr 25 16:11:58 dnsmasq[9744]: query[PTR] lb._dns-sd._udp.6.0.0.192.in-addr.arpa from 10.100.137.142
Apr 25 16:11:58 dnsmasq[9744]: forwarded lb._dns-sd._udp.6.0.0.192.in-addr.arpa to 127.0.0.1#5300
Apr 25 16:11:58 dnsmasq[9744]: query[PTR] lb._dns-sd._udp.128.137.100.10.in-addr.arpa from 10.100.137.142
Apr 25 16:11:58 dnsmasq[9744]: forwarded lb._dns-sd._udp.128.137.100.10.in-addr.arpa to 127.0.0.1#5300
127.0.0.1#5300 is the local DNSCrypt proxy which is performing external lookups against 1.1.1.1. It's just returning NXDOMAIN for those request.
And before anyone asks, yes I've reconfigured PiHole to use Cloudflare directly, but the behavior doesn't change. This is not related to the DNSCrypt configuration.
Those are wide area service discovery requests for the legacy browsing domain.
Usually, I would expect clients to have picked that up via your DHCP server's domain name option already.
From your debug log, it would seem that your DHCP server wouldn't offer a respective option.
Can you check whether your router would define (or allow you to define) a local domain name?
If that's missing, that could be an explanation why certain (Apple?/iOS?/mDNS?) clients would try to request that via a DNS-SD record from your DNS server.
However, NXDOMAIN is a valid answer.
It would have told the requesting client that there is indeed no local domain, and I'd have expected that client to stop its wide-area DNS-SD requests.
This seems more like an issue that should be addressed on the client side.
DHCP option 15 was not previously offered, you are correct. I did change that during my troubleshooting as something to address since I can control the records in that domain, and I figured I'd stop seeing PTR lookups. The PTR lookups continue, but there's an additional lookup for my internal domain which points to a 0.0.0.0 record. That doesn't change the errant behavior, unfortunately. I agree that NXDOMAIN is a valid answer and should be accepted, but the phone doesn't want to cooperate.
I have a case open with Apple and have it escalated to their engineers for further troubleshooting. I agree with you that this is likely client related, but as I've seen this same issue across numerous boards, I hoped my efforts as well as a possible resolution could find a home here for future troubleshooters with the same issue.
The issue was my VPN app. Once I uninstalled the VPN app and reset my network settings, the SD lookups stopped.
Apple support confirmed that VPN apps can cause similar behavior. They also provided documentation on recommended network configurations, which I'll review.
Ultimately, look at what's hooked into your network stack. Hopefully this is the end of this issue.
We've also received several similar reports here, but were never able to pinpoint the issue to a specific piece of client software (maybe apart from those observations that were related to OpenThread service discovery queries, which may have been addressed by updates for Apple's OSs).
After several go-arounds with Apple's T3 engineering support, we're still troubleshooting this issue. They're saying it's from the kernel itself. They had me factory reset my phone, and the symptoms went away for 4 days. Then suddenly, seemingly without any warning or event, it started up again. I didn't install any new apps or updates, it just starting going again.
We did notice, however, that during those 4 days, none of our streaming devices buffered, and my phone's battery lasted for over a day. I guess 14K PTR lookups per hour is enough to cause problems. Who'da guessed?
Apple has assigned me a dedicated support engineer, and we're continued to work on this. Word is that iOS 15.5 may have the fix, but I remain skeptical. We've agreed that 1 week without a recurrence is sufficient to call it resolved. I'll let the group know if this works out in the near term.
