Hello guys. First and foremost I haven’t been on the Discourse site for a while so I apologize in advance if this has been touched on already, but a quick search didn’t yield any results. Lately, I’ve noticed a very large amount of queries classified as “OTHER”. Most of these queries were once classified as “A” or “AAAA”. Even “discourse.pi-hole.net” is classified as a “OTHER” query. I’m sure this isn’t affecting blocking in any way, I’m just curious as to what changes took place as I’ve never had this category populated before, and now it’s roughly 25-30% of my query type. Thanks in advance for any clarification.
Edit: Wanted to add a piece of pertinent info. All of these “OTHER” queries are generated by Apple Products. Ex. iPhone and Apple TV. Don’t know if that has any relevancy.
Hello @altstadt. It may very well be some kind of change in iOS 14. I didn’t update my phone till yesterday, but my AppleTV was updated on launch day. Apps running on iOS 14 now have to request permission for access to network devices. These changes under the hood on iOS/TVOS most likely are affecting the way PiHole sees/handles these request. Good catch!
This is a change in IOS and MacOS 14. In your dnsmasq log at /var/log/pihole.log, it is likely shown as type=65. A typical query of this type shows as:
Sep 19 12:49:13 dnsmasq[1109]: query[type=65] guzzoni-apple-com.v.aaplimg.com from 192.168.0.134
This document specifies the "SVCB" and "HTTPS" DNS resource record
(RR) types to facilitate the lookup of information needed to make
connections for origin resources, such as for HTTPS URLs. SVCB
records allow an origin to be served from multiple network locations,
each with associated parameters (such as transport protocol
configuration and keys for encrypting the TLS ClientHello). They
also enable aliasing of apex domains, which is not possible with
CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP
origins. By providing more information to the client before it
attempts to establish a connection, these records offer potential
benefits to both performance and privacy.
In particular, the HTTPS RR (RR type 65) provides special handling for the case of "https" origins as described in Section 7.
Thanks for the clarification @jfb. I also noticed that iOS 14 added a security setting under the Wifi settings that’s enabled by default and caused me some headaches. There’s an option now to hide your Wifi address. This was causing PiHole to not recognize my phone despite the wifi address being added to the hosts file. What this option does it basically spoofs your private address and issues it’s own address. Supposedly it helps with Ad tracking. I figured that I would add this spoofed address in the hosts file as well, but it’s dynamic. It changes every time you join your wifi network. This may have been causing me issues with OpenVPN as well since the update. Testing now if connectivity is affected now that I’ve disabled this setting.
I should have been a bit more clearer. The MAC address of the iPhone doesn’t change unless I disable and re-enable the Private WiFi address option. A completely different spoof address is generated in each every time that is done. It does not change every time you join the network. What DOES change each and every time is the IP Address. This was causing my iPhone to get assigned an IP that’s not on my allowed list as far as my VPN goes. Also, I have DHCP reservations on my router, so with this option enabled, PiHole was basically seeing this as a completely new device with a different IP. I added the Apple spoof address to my router and my IP hasn’t changed. But, if I disable and re-enable that option for whatever reason, I will get a new Wifi address and would have to make changes to the router again. I haven’t had VPN connectivity issues with the option disabled or when adding the spoofed address to my router’s DHCP settings. I also haven’t been able to test this outside of my network. Will test tomorrow at work. Hopefully it generates a different address for each known/connected network.
Edit: I also don’t know if Apple frequently changes that address on their own. If that’s the case, then it presents another problem. I hope that isn’t the case and it just assigns a static address for each network and doesn’t frequently change them.
(This is drifting a bit from your original question about the OTHER category, which I think jfb has provided an answer for.)
From a network perspective, a different MAC address constitutes a different network interface. Your observations are hence to be expected.
Your iPhone's (or any other device's) behaviour for MAC address randomisation can only be controlled on the device itself, to the extent allowed by that device.
EDIT: This is causing issues for other iPhone uisers as well, see
It even constitutes an entirely different device. In case you are doing such shady things, it is absolutely expected that your router/VPN/Pi-hole may not handle the device as they did before. They simply cannot know if it is the same device as before.
These "features" are not making the administration of networks any easier. It is easy to see why this may be a tiny bit of privacy improvement in some special scenarios (like airport Wi-Fi with ad/tracking access points), but, in most other cases (like static address assignments at home), it has an adverse effect. Managing your network becomes (a lot) harder and this may very well give rise to other security/privacy issues.
No, a MAC address is bound to a NIC.
A device may have mutiple NICs, hence multiple MACs may be associated with the same device.
Also over time, the same MAC might be associated with different devices connecting to your network, e.g. if you were to use the very same USB Ethernet dongle plugged into different RPis or laptops (obviously, not at the same time), or if you'd slot a NIC from one computer into another.
That's part of the reason for the emergence of DUIDs.
For the less experienced, the term "NIC" simply means nothing. Even when my way of saying this (NIC <=> device) may be less accurate when you look more closely, it is still fully applicable in this situation: With only one Wi-Fi NIC in this iPhone.