Since installing HA a few years ago, every hourly interval it is performing roughly 1,000+ PTR lookups to the primary local nameserver (my LAN is a /22) for every IPv4 address on the subnet, illustrated here:
How do I go about stopping this behaviour? As far as I’m aware it was doing this since fresh installation so I don’t believe it’s an extension/addon but I might be wrong on that.
It’s statically configured primarily IPv6 but it has a static LAN v4 address as well, which it appears to be using to do the lookups - it’s the v4 address that is hitting the primary.
My only other solution is that I will just have to entirely remove the IPv4 address from the configuration and see if that solves it (I don’t use v4 unless no other option).
The amount of pyr lookups comes up psrennially… In short. You don’t - the system needs to look up its information and it’s a minor blip as far as your DNS server is concerned
Unless you prefer not being able to find things on the network.
I don’t need to find anything on the network and I’d rather disable it so it’s not distorting the stats charts. Everything on my LAN is statically configured where useful - servers, switches, cameras, etc with local DNS. Absolutely no need to be able to find things.
I’m not concerned about the actual hitting of the BIND9 nameservers I run, they don’t care, it’s only 1000 PTR requests in a short burst and forward and reverse addressing is fully configured for the LAN on v4 and v6. That’s not the issue. I just don’t have any need for this behaviour. Everything in HA is configured, there is no discovery or scanning or hosts required.
I’ll just remove v4 from HA or confiugure it on a different subnet where it can’t chat, and see if that solves it, if there is no other simple solution.
Can you firewall HA’s IPv4 address at your local DNS server? Would that help?
Count me in the apparent minority opinion that running reverse-DNS lookups on a local, non-routable subnet in a home setting where the needed PTR records are usually never configured is a silly waste of resources, and should trigger an IDS alert if it is scanning the entire local subnet…
Yep… The PTRs are configured on my local nameservers, but yes my personal opinion is that this is not required in my scenario and there should be an option to disable this. I don’t like unnecessary things and performing 1000+ PTR lookups every hour is one of these things.
It is a waste of resources and unnecessary thrashing of servers for no useful purpose, even though it’s not impactful in any way, it’s the principle.
I could firewall it easily, but I don’t want to block HA from being able to perform lookups in general.
I don’t use DHCP (on HA), everything including the nameservers and v6 is statically configured.
I’m aware what that is, I have no need for zeroconf on my HA.
If I switch the v4* subnet to a /16, what’s it going to do? Perform roughly 65,536 PTR lookups every hour? If I switch it to a /8 is it going to do roughly 16.7 million PTR lookups every hour?
It has the two v6 nameservers statically configured as well, but it seems to use v4. I’d have to test that theory, it might do, I suspect it just prefers v4 but would fallback to v6 if no joy (at a guess).
I worked professionally on the opposite side of this issue for almost four decades, managing a Class B IP subnet (showing my age, a /16 public IP netblock) with thousands of home-grade wifi devices on the network. You have no idea how many splintered Android versions and poorly-implemented embedded electronics or IoT devices won’t even connect to wifi, or fall apart when they try to roam between almost a thousand wifi access points…and that’s before you need to deal with the flood of mDNS packets from home-grade devices on the wired backbone, lack of WPA2/3-Enterprise and 802.1x support (to meet auditor’s requirements), etc…
You can stop it by changing your configuration file, at your own peril.
Basically, stop using the default config and use the integrations you need.
DHCP is the culprit, removing it will stop noise, and HA will continue to find devices.
Example:
# default_config: # ← remove / comment this out
homeassistant:
# keep only what you need
frontend:
system_health:
person:
logbook:
history:
#dhcp: no! bad
zeroconf:
ssdp:
mobile_app:
# your includes
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml