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.