Seeing the same thing . Definitely a bug please look.into it. 109 is my hub.
Well good to know it's not just me!
I rolled back to 2.3.3.140 (along with a database backup from that release) and the issue appears to be gone. Seems like something with the latest update caused it.
I'm now seeing the normal requests from the hub and just a handful of PTR queries to local IPs over the course of an hour.
To summarize my posts:
- Significant uptick in PTR queries from the hub to my DNS server that occurred every other hour for around an hour at a time.
- DNS queries were to local IP devices attached to the hub
- Rebooting didn't work
- Rolling back to a prior release (2.3.3.140) and restoring a database backup solved the issue.
- No other changes were made to existing apps on the hub shortly prior to or at all after the update
- Appears to be similar to an older issue: Many DNS Queries from new Hub - #12 by storageanarchy
Hopefully this is something that can be looked into as I'd like to keep my hub up to date!
1 Like
i believe the issue is it should not be trying to lookup private ip addresses only public ips.. not sure how that would be implemented.. i imagine the continual lookups are because it fails as normally you dont lookup ptr records for private ips.
i am thinking of switching back my kasa to the public drivers as then i have control of limiting the lookups myself.
i have verified on my other hub still using the public not built in kasa drivers it is NOT doing this so assume that is the issue.
more info.. definately in my case was the built in kasa driver trying and failing to do ptr lookups of local ips.. switched back to the user version of the driver after much reconfiguring and the requests all dissappeared.
I have Kasa, but never moved to the built in integration, still on the community version. Also the way my network is setup a reverse lookup internally should get a result for all my local IPs anyway. Are the repeated requests failing or returning results back to the hub? Looks like for @kahn-hubitat the DNS server is not responding at all which might be why it keeps hammering the queries.
Some LAN integrations trigger arp calls to look up MAC address of a local device.
Before 2.3.4, hub would run arp -a 1.2.3.4 for each IP address and cache the result for an hour. Starting with 2.3.4, hub runs arp -a without IP address and effectively caches its entire output for an hour. We found that each arp call would cause a small memory leak, and bundling them minimizes the leaks. These extra DNS calls a are a side effect of doing arp. And yeah, there may be a small flurry of them right after a reboot while arp's own cache doesn't have all local devices.
If these extra DNS lookups are an issue (and it needs to be more than "but it didn't used to work like this"), I could make MAC cache TTL tunable so it can be increased at will. And I'm open to other suggestions, too 
1 Like
If someone's DNS server was to not respond to the ARP query would that then possibly result in the OPs observation, where it keeps hammering for an hour straight?
I think mine should respond properly to the requests and I am not seeing excessive numbers queries.
All of the Hubitat requests on my system for local IPs received an NXDOMAIN response. I wouldn't mind an initial increase in calls upon reboot but this was happening every other hour resulting in 6k to 7k requests every two hours.
So I'm assuming what @jtp10181 stated might be what's happening - since it's getting NXDOMAIN back, it keeps retrying.
I wouldn't say its improper .. it.shouldnt be doing requests for private ips ie 192.168 or 10.0 etc
Especially when going to a public non.local server.
If the only DNS server you give the hub is outside of your local network where else is it supposed to send the requests? My setup I have a local caching DNS server, my router hands out the DHCP info with only that DNS. I have that DNS server configured to forward any local requests to the router, all other requests go upstream to some DOT servers I have selected.
Without the extra DNS server, most configurations would point DNS to the router (which usually runs its own caching server). The router would respond to local requests and forward everything else to the configured upstream servers. If you point the clients directly to an upstream DNS there is no chance to do any local resolution.
If names are not needed for this, perhaps -n could be added to the arp command to avoid the DNS lookups?
2 Likes
Thats not the point . The point is it shouldnt be trying to lookup.local names..why is.it?
1 Like
True, I don't think it needs the names it is just trying to get the MACs, as tony said above there might be a way to get what is needed without the reverse DNS lookups.
at least with the non built in driver it is getting the macs without looking up the names..
unfort i saw transient delays going to web pages and other fxs when i used the router as my dns as opposed to going direct to my isp.. I think this is becuase i get much better performance as they cache a large number of common lookups so performance is better.
Yes, next build. This whole issues slipped off the radar for a few days.
6 Likes
Just wanted to check - was this fixed with an update? I didn't see something in the last few release notes but maybe I overlooked it.
Unfort i cannot tell as i switched back to the community integration.
Just wanted to drop in and confirm I updated to 2.3.4.133 and the issue is no longer occurring. Not sure what actual update resolved it, but it's fixed now. Thank you!
3 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
