How to prevent in-addr.arpa queries from being forwarded to upstream DNS?

[aru]

I noticed that some devices are sending upstream in-addr.arpa queries, including certain IoT devices and AiMesh nodes. Since these queries consume my NextDNS query quota, I’d like to know if this behavior is considered normal. Also, is there a way to configure the system so that in-addr.arpa queries are resolved locally instead of being forwarded to the upstream DNS?

I blocked the .arpa top-level domain (TLD) in my NextDNS settings, which made these query issues more apparent.

 

[dave14305]

You can add a line to /jffs/configs/dnsmasq.conf.add:

local=/168.192.in-addr.arpa/

 

[dave14305]

Do you still have “Forward local domain queries to upstream DNS” disabled on the WAN page? It should be disabled.

 

[kuchkovsky]

Check "Forward local domain queries to upstream DNS," as @dave14305 already suggested. If that doesn't help, you can configure NextDNS with nextdns-cli - it doesn't have this issue and offers better integration with NextDNS (such as per-device logging) than the stock DoT implementation from Asus. It also blends your DNS traffic seamlessly with the other HTTPS traffic, thanks to DoH.

 

[aru]

Do you still have “Forward local domain queries to upstream DNS” disabled on the WAN page? It should be disabled.

Yes, it is disabled on my WAN DNS Setting.

As per your suggestion, I added local=/168.192.in-addr.arpa/ to /jffs/configs/dnsmasq.conf.add and restarted the service with service restart_dnsmasq. After monitoring for a day, I noticed that the query volume remained unchanged. if it’s possible that some IoT devices or AiMesh nodes are bypassing dnsmasq rules and sending queries directly to the upstream DNS?

Check "Forward local domain queries to upstream DNS," as @dave14305 already suggested. If that doesn't help, you can configure NextDNS with nextdns-cli - it doesn't have this issue and offers better integration with NextDNS (such as per-device logging) than the stock DoT implementation from Asus. It also blends your DNS traffic seamlessly with the other HTTPS traffic, thanks to DoH.

To be honest, I’m a bit reluctant to install nextdns-cli. Some users have reported that the NextDNS client, when running permanently on the router, consumes a considerable amount of virtual memory — e.g., one reported about 782 MB (ref). Others have even decided to stop using it altogether (ref). Since my main goal is just to reduce the in-addr.arpa query volume, I’m hesitant to introduce such a heavy service just for that.

 

[dave14305]

As per your suggestion, I added local=/168.192.in-addr.arpa/ to /jffs/configs/dnsmasq.conf.add and restarted the service with service restart_dnsmasq. After monitoring for a day, I noticed that the query volume remained unchanged. if it’s possible that some IoT devices or AiMesh nodes are bypassing dnsmasq rules and sending queries directly to the upstream DNS?

You would need to enable DNS Director in Router mode to prevent bypass. The only other possible sources are the router itself, or any SDN networks you have defined in Guest Network Pro. What else is running on the main router?

If you continue to block .arpa you won’t be able to reverse lookup any public IPs to hostnames. What does the NextDNS logging show about all these arpa queries? Are they all PTR type queries?

 

[aru]

You would need to enable DNS Director in Router mode to prevent bypass. The only other possible sources are the router itself, or any SDN networks you have defined in Guest Network Pro. What else is running on the main router?

By default, DNS Director is enabled and the router is set to Router mode, so internal devices should theoretically be unable to bypass the router—but in practice, it seems they can.

Since SDN and Guest Network Pro are not used, .arpa queries will not originate from SDN or Guest Network Pro.

If you continue to block .arpa you won’t be able to reverse lookup any public IPs to hostnames.

For private IPs (192.168.x.x), public DNS cannot resolve them; forwarding these queries upstream appears pointless, only increasing query volume and generating unnecessary load.

I’m thinking maybe the settings you suggested are already working, but NextDNS stats might just be a bit delayed. I’ll keep an eye on it for a few more days to see how it goes.

What does the NextDNS logging show about all these arpa queries? Are they all PTR type queries?

There are still other normal queries, but .arpa accounts for almost 90% of them.

 

[kuchkovsky]

consumes a considerable amount of virtual memory — e.g., one reported about 782 MB (ref)

It consumes around 528 MB of virtual memory on my router as well, but that doesn't really matter - the actual memory usage is just around 19 MB:

kuchkovsky@rt:/tmp/home/root# ps | grep nextdns
  338 kuchkovsky  3120 S    grep nextdns
 6245 kuchkovsky  528m S    /jffs/nextdns/nextdns run
kuchkovsky@rt:/tmp/home/root# grep -E 'VmSize|VmRSS|VmData|VmSwap' /proc/6245/status
VmSize:      540952 kB
VmRSS:       19288 kB
VmData:       51764 kB
VmSwap:           0 kB

I've been running nextdns-cli on my routers for a few years, handling around 1 million DNS queries per month, and I've had no issues - it's really lightweight. I also run it on a VPS with just 1 GB of RAM.

If you don't want to use the app, you can check whether your current dnsmasq configuration includes bogus-priv:

kuchkovsky@rt:/tmp/home/root# cat /etc/dnsmasq.conf | grep bogus
bogus-priv

If it's missing, just add it to your /jffs/configs/dnsmasq.conf.add.

 

[dave14305]

For private IPs (192.168.x.x), public DNS cannot resolve them; forwarding these queries upstream appears pointless, only increasing query volume and generating unnecessary load.

The arpa domain is used for more than private IP addresses. But do what you want.

I would speculate the queries are coming from the router itself. Based on the limited screenshots from NextDNS console, I'm guessing you're running Skynet and it might be doing a lot of DNS lookups directly. Looking at the Logs tab in NextDNS would be easier than looking at the Analytics only.

I'm not sure I understand why only 2 queries have been blocked by OISD, unless you're also running an adblocker on the router. There must be some unusual aspect to your configuration that you're not telling us about.

 

[aru]

The arpa domain is used for more than private IP addresses. But do what you want.

You're right, .arpa isn’t only for private IPs, and it’s possible some of the lookups are generated by the router itself.

I would speculate the queries are coming from the router itself. Based on the limited screenshots from NextDNS console, I'm guessing you're running Skynet and it might be doing a lot of DNS lookups directly. Looking at the Logs tab in NextDNS would be easier than looking at the Analytics only.

I checked the NextDNS Logs, and there actually aren’t that many .arpa queries — most of them are old (around mid-September). No new ones have appeared recently.

However, the Analytics dashboard still shows that about 90% of daily queries are .arpa, which is confusing. It feels like the Analytics data might be cumulative or delayed, or maybe something internal local reverse lookups that don’t show up in the NextDNS logs.

I'm not sure I understand why only 2 queries have been blocked by OISD, unless you're also running an adblocker on the router. There must be some unusual aspect to your configuration that you're not telling us about.

You can refer to my signature for the detailed hardware and software setup — I do have the packages you mentioned installed.

If those packages are indeed responsible for the behavior I’m seeing, then I’ll just leave it as is. It doesn’t really affect normal home use anyway; I was mainly just trying to prevent in-addr.arpa queries from being forwarded to upstream DNS.

 

[dave14305]

So with Diversion, uiDivStats, and Unbound installed locally, you choose to use NextDNS? If Unbound is working, the only thing sending to NextDNS is the router for minimal queries, as you see in the stats and logs. Could be from uiDivStats, trying to generate stats.

 

[aru]

So with Diversion, uiDivStats, and Unbound installed locally, you choose to use NextDNS? If Unbound is working, the only thing sending to NextDNS is the router for minimal queries, as you see in the stats and logs. Could be from uiDivStats, trying to generate stats.

Ah, I see — thank you so much for taking the time to analyze and explain this. I really appreciate it!

 

[GWTechTalk]

I recently explored this topic and while I don't have any experience with the apps suggested above such as Unbound I do have an Ad Guard Home server instance. What I found is that sometimes blocking these calls can have the opposite effect if the device making the calls doesn't have good back down logic or was not setup properly with group policy. One device outright blocking it made the device increase the amount of calls it made to 9000 times in two hours. I only noticed it because it was momentary causing the router wifi to spike latency on all traffic.

Best solution I have found with Ad Guard is routing it to a black hole. I had to remove some information in the lines for public posting.