Near constant PTR lookups in DNS logs

[Timmy]

On my current install of OpnSense I have near constant lookups for PTR records for all my internal IPs (ones reserved in DHCP, and any standard leases. There are blocks of lookups only a few seconds apart - example attached.

Screenshot of lookups https://i.imgur.com/NlNkDR3.png

As an example of how many requests are being made:
https://i.imgur.com/vXTvlvi.png
https://i.imgur.com/aBtM6eN.png

Much searching lead me to a possible patch Unbound.inc for how it was handling aliases for 23.7 -> https://github.com/opnsense/core/pull/5925

However I think unbound.inc has been patched in my deployment already.

When I first installed the system it was using Unbound for DNS, but I moved to AdGuard. Moving back to Unbound for DNS didn't change anything. Unbound is not currently running as a service.

I was reading somewhere that it was a reporting component creating all the requests, but I have turned off most of the reporting I could find that I thought could be generating the request.


Report config:
https://i.imgur.com/be36sP4.png

Collected reports:
 ipsec-packets
 ipsec-traffic
 lan-packets
 lan-traffic
 opt1-packets
 opt1-traffic
 opt2-packets
 opt2-traffic
 opt3-packets
 opt3-traffic
 opt4-packets
 opt4-traffic
 system-cputemp
 system-mbuf
 system-memory
 system-processor
 system-states
 wan-packets
 wan-traffic


Installation:
Version: 23.7.3   
Architecture: amd64   
Commit: 273c5bf46

Any ideas?

Thanks.

[Timmy]

Did the update to 23.7.4 and then spent some time stopping a lot of services one at a time on the router to see if the lookups stopped, but they continue.

Spent some time going over logs and the only thing I could find these log entries:

configd/latest.log:<13>1 2023-09-24T18:57:10+10:00 gateway.home.256.network configd.py 242 - [meta sequenceId="157"] [1e7976fe-725b-4acc-afb5-c0e6d58acb83] request arp table
configd/latest.log:<13>1 2023-09-24T18:57:22+10:00 gateway.home.256.network configd.py 242 - [meta sequenceId="158"] [e75cbea3-3b67-43c9-8a52-24b5cc0583e8] request arp table
configd/latest.log:<13>1 2023-09-24T18:57:34+10:00 gateway.home.256.network configd.py 242 - [meta sequenceId="159"] [3400cc11-905c-4799-8e3b-cb0694395fda] request arp table
configd/latest.log:<13>1 2023-09-24T18:57:46+10:00 gateway.home.256.network configd.py 242 - [meta sequenceId="160"] [99345e14-81f6-4ab7-a1da-bc6f357e37b3] request arp table
configd/latest.log:<13>1 2023-09-24T18:57:58+10:00 gateway.home.256.network configd.py 242 - [meta sequenceId="161"] [10054ff0-ed8c-427b-aa3c-a12950a196ff] request arp table

But I still can't workout what is creating the requests.

Any ideas?

Thanks.

[awptechnologies]

Same issue didnt notice it untl now no idea when it started happening but it sucks

[cookiemonster]

This is usually not to do with the firewall/DNS resolver. It is doing what is asked of it, to give the domain for an internal ip address.
Usually it is some device in the internal network asking "around" for a reverse name resolution. You're going to have to track it. A packet caputre would quickly help.
Also when AdG/Pi-hole is in the mix, there can be a ping-pong loop.
AdG for instance has the setting section:
Private reverse DNS servers
The DNS servers that AdGuard Home uses for local PTR queries. These servers are used to resolve PTR requests for addresses in private IP ranges, for example "192.168.12.34", using reverse DNS. If not set, AdGuard Home uses the addresses of the default DNS resolvers of your OS except for the addresses of AdGuard Home itself.
AdGuard Home could not determine suitable private reverse DNS resolvers for this system.
check how that your settings there are what you expect.

[Timmy]

Thanks so much for the reply!

I had looked at a packet capture, but the source was always 127.0.0.1 - so something on the device was creating the requests.

But, it was that config in AdGuard!

Not my first or only Ad Guard service running, so not sure why those options were on / enabled by default.

But fixed now

Thanks again.

[cookiemonster]

Glad is fixed.