no in-addr.arpa loops (counting 5424 requests in less than 12h)
Actual Behaviour:
Hi all,
First of all I currently use a temporary setup since me firewall appliance died and I now was going back to my older Apple router Hardware (which is still great and very reliable) but there is one particular behaviour I wasn’t able to manage.
Ive read through all the posts where I could find issues in regards to pi-hole and those Stoneage-like-apple-routers (Airport extreme and Time Capsules of the most recent generation) but they didnt solve my problem.
So what’s my issues? In general pi-hole and Airport works - it blocks what my lists tell to. The only issue I have is regarding internal domain resolution. It seems it cannot be properly set on the AirPort Extreme or Time Capsule (I tested with both). How can I manage to get those in-addr.arpa request loops to shut up?
I tried different setups in pi.hole with conditional forwarding and without.
My current settings:
Bridged Modem from ISP connected to Time Capsule on the WAN receiving the public IP, managing NAT and facilitate internal Network using its DHCP pointing to pi.hole as DNS.
Pi.hole on DietPi on a Raspberry Pi 4 with NextDNS CLI installed on the same machine. Upstream DNS pointing to 127.0.0.1#53350 (as This is matched with the NextDNS client config)
I have setup static IPs for around 35 devices in the same net and also filled the /etc/hosts file on the pi.hole. I can see the correct domain names of the devices in pi.hole but those nasty in-addr.arpa requests don’t stop in the query logs. In the Dashboard I see devices using different upstream servers:
Blocked
Cached
Localhost#53350
Airport_TC#53 (most of the in-addr.arpa happen here, all of them receive N/A as answer)
Other (some in-addr.arpa happen here but also external request, all of them receive N/A as answer)
This „other“ also bothers me since I really did what I can to point everything to the localhost#53350 and local resolution should be done with the Airport_TC#53 as far as I would expect.
May I ask if it can be managed that those internal in-addr.arpa requests or significantly reduce with a specific config? I have seen some users here like @jfb who seems to have no issue with this, I wonder how he did manage?
Let me know if you need more infos! Thanks for you help, much appreciated
Reverse lookups are not uncommon, and they are not limited to private range addresses. It would be expected that reverse lookups for public IPs would be forwarded upstream.
However, I'd guess that your question is more about the 'other' category next to the dashboard's Upstream servers donut graph in general, rather than reverse lookups specifically?
'other' would subsume all requests that were not forwarded to one of the other upstream categories.
If you click on 'other' and take a look at the Status column, I'd expect that to mostly indicate that a request already has been forwarded, so Pi-hole would wait for the respective reply instead of forwarding it again.
If that doesn't quite tackle your question, please consider sharing a sample set of those 'other's.
Thanks for your reply! Since I didn’t had this strange behaviour while I was using the Opnsense firewall I believe it must be the capabilities of the Airport router. I will wait until someone also using it can say something about it. Maybe they found a solution, to reduce or eliminate it.
What you are seeing are mDNS queries, typically associated with the Apple Bonjour protocol. It has nothing to do with your router (as you noted, I run a few of the Apple routers, and they are quite good, by the way).
Your top two clients match the mDNS query volume, and both clients are Apple devices.
I note that you have conditional forwarding enabled, which can cause some circular DNS traffic.
This is not a query that your router can answer - it gets answered by other clients on the network.
Disable conditional forwarding and see if the traffic volume decreases.
Just for comparison, I have many Apple devices on my network (on different Pi-holes). Here is one example of a Mac Mini that makes some mDNS requests.
Thanks! Seems like Disabling Conditional Forward relaxes the # of those entries by a big chunk. Made the change 30 min. Ago - Still monitoring but it seems that’s the way to go here.
Hmm seems it just started good but during today I again got lots of those noise stuff... I really dont understand why. Cond.Forwarding is already turned off.
I don't see anything out of the ordinary in your debug log.
Pi-hole is receiving the queries from the client(s) and forwarding them. Since these are mDNS queries, the upstream resolver (in your case NextDNS) can't resolve them. In the snippet of your pihole.log included with the debug log, I don't see any replies after the mDNS queries.
ok, I let the topic rest. Seems there is nothing I can do about it now. As soon as I get my hw firewall back, the devices will be back to "unconfused mode".
You may find that temporarily turning off AirPlay on the Mac Mini significantly reduces the number of these queries. I think it's in Control Center on newer macOS (mine's an older Mac)
Mine, in System Preferences > Displays > Display, has an option for "Show mirroring options in the menu bar when available". I think this could be a culprit for the excessive local service queries – it's polling for AirPlay comaptible displays available via your temporary router. If you uncheck that box, worth seeing if that reduces the queries. There's also similar polling for AirPrint, AirDrop and AirTodayGoneTomorrow (might have made that last one up), which you may be able to turn off in other sys preferences sections.
there is some stuff I use regularly, like copy / paste on different devices. So Airdrop I will leave on. the rest can go. I will report tomorrow if those settings had any impact. Thanks again @chrislph !
I really dont understand why. Cond.Forwarding is already turned off.
