Stopping hourly PTR lookups

Hello

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).

Thanks very much, solution would be appreciated.

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.

Tldr leave it alone. It’s normal DNS traffic.

1 Like

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.

1 Like

It’s not here for your benefit… And just because it’s static doesn’t. Mean there’s no ptr. It’s a reverse lookup.

The system needs to look stuff up. Or not. You don’t get to control that. And it’s not hurting anything.

Changing things will break it. Nothing to see here.

  • Your friendly ex DNS engineer.
1 Like

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.

1 Like

There is not and SHOULD NOT BE any other solution. It’s not hurting anything. I’m sorry you don’t like it in the log. But it’s normal.

Remove your v4 address if you like but that’s not the issue.

I’m not suggesting it’s hurting anything, it’s just “distorting” my stats charts :slight_smile:

Nevermind, if it’s not possible it’s not possible.

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…

1 Like

Read about Zeroconf then reassess. There are reasons.

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.

1 Like

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?

1 Like

Does HA use IPv6 for DNS as well? If so, will it still resolve with only IPv4 firewalled at the DNS server???

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).

1 Like

Enterprise Smart Home Syndrome

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