HA spamming PTR DNS lookups?

[a1ad]

Ah yes indeed, how can i remove the dhcp and keep all the others in default?

[CentralCommand (Mike)]

The only way is to remove default_config: and instead list out everything it includes individually. There’s no way to use default config but exclude one.

[CentralCommand (Mike)]

Going through the list of things in default_config now. I’ve had this disabled for a while because I got frustrated by a few things. Two of the ones I have had disabled are ssdp and zeroconf (yes I forgot I disabled this in my post earlier). Both of these are also network scanners although I don’t know for sure if they use DNS. If you still see mass PTR requests after disabling DHCP then maybe try turning off one or the other of these as well.

[a1ad]

can you give me a list on what to enable from default_config?

[CentralCommand (Mike)]

I mean the doc on it is here. If you’ve had it enabled then I’d say just list everything you don’t already have listed somewhere in your configuration.yaml. Most of them have no real configuration, just list the name of the component with a colon. Like map: for map or my: for my

[a1ad]

ok, got it. Lets try

Urgh: still the excessive supervisor dns lookups.

edit: oh lol, the supervisor dns lookups are not from HA… damn :-s
edit2: its the nodered container

[woodsaw]

Thanks for the info. I had the exact same problem. I can confirm that removing DHCP from the core
discovery work like a charm. no more PTR requests.

one other item that has been spamming my adguard queries is the version.home-assisstant.io. I don’t know what its for and how to reduce/eliminate it. it shows up every 5 minutes and there’s about 830 of them per day! Any ideas?

[123 (Taras)]

@woodsaw

it shows up every 5 minutes and there’s about 830 of them per day! Any ideas?

If you are using Home Assistant OS, it performs an Internet connectivity check every 5 minutes. The setting is in its NetworkManager.conf file and it cannot be modified.

In addition, for both OS and Supervised, the Supervisor is also hard-coded to perform periodic Internet connectivity checks. Plus, at each interval, multiple requests are made. It also periodically checks for the latest version information.

For the last two months, I was able to patch Supervisor’s code so that it would perform the check every 4 hours and the version check once a day. It was only a matter of changing two integers. However, the latest version of Supervisor includes code that detects source code modifications and then marks your installation as being unsupported and unhealthy (it’s the “unhealthy” designation that prevents you from installing Add-Ons and possibly even upgrades).

If you are interested, I reported it here and the conclusion, although I admit I am not entirely clear about it, is that it may be possible to disable the source-code check using Home Assistant CLI. I haven’t explored that suggestion yet. As for the frequent connectivity checks, it was explained to be normal and acceptable.

FWIW, I will be posting a Feature Request in the Supervisor repo to permit an end-user to adjust the frequency of connectivity and version checks via a configuration file (I think that might be more acceptable to the development team than having controls in the frontend).

[woodsaw]

ok, thanks for the detailed response. if its just checking for connectivity, then I guess its fine, although I would still prefer if the frequency was user configurable.

[123 (Taras)]

@woodsaw

if its just checking for connectivity

It’s unclear to me why that task must be repeated ever 5 minutes (and making multiple DNS lookups each time). Even commercial Internet-connected devices aren’t that chatty.

Plus, what recourse does it have if it does encounter no Internet connection; it can’t mitigate it.

Supervisor makes Home Assistant one of the busiest devices on my local network, constantly checking its connection to version.home-assistant.io. Given that I have almost no Internet-dependent integrations (aside from weather) I would prefer to have the ability to reduce the frequency of connectivity (and version) checks. Like I said, I did reduce it in the past (without any negative side effects) but now there’s a penalty for patching Supervisor’s source code.

[123 (Taras)]

Done. Please vote if you want to have control over Supervisor’s connectivity/version checks and other functions it performs. Feel free to add to the Feature Request.

Allow some degree of control over Supervisor

Currently, Supervisor performs varies activities over which the user has no control. For example, it performs an Internet connectivity check every 5 minutes (and makes several DNS lookups each time). It also performs version checks many times a day. This activity makes it one of the most chatty clients on my local network (more than commercial devices I have that rely on the cloud). It would be useful to have a supervisor.yaml file where one could control some of Supervisor’s activities. For e…

[eazysnatch]

I hit the same error with the newest version core-2021.6.6. My SSD Disk 256GB was full that is how i found out. I got more than 500MB text files for a couple of hours. For me its not 3000 per 10 mins its like 200 000 for 10 mins. I dont have “default_config” , nmap , dhcp and currently im trying to figure out what is causing it.

I can see its the docker DNS

➜  log sudo docker ps | grep dns
60db8694e5dd        ghcr.io/home-assistant/armv7-hassio-dns:2021.06.0        "/init"                  4 hours ago         Up 4 hours                                                                                   hassio_dns

Jul  1 16:42:57 pi4 60db8694e5dd[756]: [INFO] 127.0.0.1:60215 - 40549 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 0.082305443s
Jul  1 16:42:57 pi4 60db8694e5dd[756]: [INFO] 172.30.32.1:41332 - 22422 "PTR IN 107.1.168.192.in-addr.arpa. udp 55 true 2048" NXDOMAIN qr,rd,ra 44 6.242447876s
Jul  1 16:42:57 pi4 60db8694e5dd[756]: [INFO] 127.0.0.1:33570 - 56066 "PTR IN 102.1.168.192.in-addr.arpa. udp 55 true 2048" NXDOMAIN qr,rd,ra 44 0.13718296s
Jul  1 16:42:57 pi4 60db8694e5dd[756]: [INFO] 172.30.32.1:54249 - 40549 "PTR IN 2.0.17.172.in-addr.arpa. udp 52 true 2048" NXDOMAIN qr,rd,ra 41 6.37204171s
Jul  1 16:42:57 pi4 60db8694e5dd[756]: [INFO] 172.30.32.1:40576 - 56066 "PTR IN 102.1.168.192.in-addr.arpa. udp 55 true 2048" NXDOMAIN qr,rd,ra 44 5.687066021s
Jul  1 16:42:57 pi4 60db8694e5dd[756]: [INFO] 127.0.0.1:53884 - 56963 "PTR IN 2.1.168.192.in-addr.arpa. udp 53 true 2048" NOERROR - 0 12.843435775s
Jul  1 16:42:57 pi4 60db8694e5dd[756]: [ERROR] plugin/errors: 2 2.1.168.192.in-addr.arpa. PTR: tls: DialWithDialer timed out
Jul  1 16:42:57 pi4 60db8694e5dd[756]: [INFO] 127.0.0.1:51206 - 61188 "PTR IN 138.1.168.192.in-addr.arpa. udp 55 true 2048" NOERROR - 0 9.272147204s
Jul  1 16:42:57 pi4 60db8694e5dd[756]: [ERROR] plugin/errors: 2 138.1.168.192.in-addr.arpa. PTR: tls: DialWithDialer timed out
Jul  1 16:42:57 pi4 60db8694e5dd[756]: [INFO] 127.0.0.1:55640 - 42006 "PTR IN 101.1.168.192.in-addr.arpa. udp 55 true 2048" NOERROR - 0 9.228136978s
Jul  1 16:42:57 pi4 60db8694e5dd[756]: [ERROR] plugin/errors: 2 101.1.168.192.in-addr.arpa. PTR: tls: DialWithDialer timed out
Jul  1 16:42:58 pi4 60db8694e5dd[756]: [INFO] 127.0.0.1:56376 - 56963 "PTR IN 2.1.168.192.in-addr.arpa. udp 53 true 2048" NOERROR - 0 13.004465817s
Jul  1 16:42:58 pi4 60db8694e5dd[756]: [ERROR] plugin/errors: 2 2.1.168.192.in-addr.arpa. PTR: tls: DialWithDialer timed out
Jul  1 16:42:58 pi4 60db8694e5dd[756]: [INFO] 127.0.0.1:37551 - 56963 "PTR IN 2.1.168.192.in-addr.arpa. udp 53 true 2048" NXDOMAIN qr,rd,ra 42 4.965997912s
Jul  1 16:42:58 pi4 60db8694e5dd[756]: [INFO] 127.0.0.1:53369 - 38627 "PTR IN 106.1.168.192.in-addr.arpa. udp 55 true 2048" NXDOMAIN qr,rd,ra 44 4.966344368s
Jul  1 16:42:58 pi4 60db8694e5dd[756]: [INFO] 127.0.0.1:39277 - 22422 "PTR IN 107.1.168.192.in-addr.arpa. udp 55 true 2048" NXDOMAIN qr,rd,ra 44 4.966840212s
Jul  1 16:42:58 pi4 60db8694e5dd[756]: [INFO] 127.0.0.1:38663 - 5714 "PTR IN 205.1.168.192.in-addr.arpa. udp 55 true 2048" NXDOMAIN qr,rd,ra 44 4.968133615s

CoreDNS is using 100% CPU.

After ‘ha dns restart’ we are back to normal. but i’m trying to find out the root cause.

[afelds (Adam)]

I’m a user of the AdGuard Home add-on and recently noticed tons of PTR queries in the AdGuard Home query log, all from dns.local.hass.io.

I was able to resolve the high volume of queries by adding my router’s private IP to the “Private DNS servers” list in AdGuard Home Settings > DNS Settings > “Upstream DNS servers” top section.

Further details for the curious:

• Please note my router runs a DNS server, I believe most but not all routers do.
  • I have a Unifi Dream Machine (UDM).
• My HA OS runs in a Proxmox VM and receives its IP and DNS nameservers via DHCP.
  • That IP does not change, due to the router’s DHCP configuration.
  • I did not attempt changing HA OS to use a static IP or static nameservers.
• I did not disable “Enable reverse resolving…” in AdGuard.
  • There continue to be a non-annoying number of PTR queries for my LAN’s private IPs in the AdGuard query logs, some of which my router answers with the hostname for the IP and NOERROR.
• Most of the queries were IPv4 (*.in-addr.arpa), some were IPv6 (*.ip6.arpa).

My HA OS nameservers are (in-order):

1. AdGuard Home (HA OS private IP)
2. My router’s private IP. The router runs its built-in DNS server (Unifi UDM)
3. Nameservers no. 3 and 4 are both public IPs for my DNS provider (NextDNS).

[lennardw (Lennard)]

For me this helped:

Huge amount of .in-addr.arpa requests from HASS

I had the same issue and got it resolved for me. I had the name servers in the GUI configured to my DNS-servers (I have two Adguard Home installations running in my LAN). I changed the following: I set my DNS-server in the GUI to my local HA DNS-service (172.30.32.3) - You can find that in the ssh interface with the: ~ $ ha dns info host: 172.30.32.3 locals: dns://192.168.XXX.YYY dns://192.168.XXZ.YYZ servers: [] update_available: false version: 2021.06.0 version_latest: 2021.06.0 …

[DeadlySin2]

The same issue for me.

Latest Home Assistant OS. Adguard home installed. Nothing from the advices above help me
My pi4 is using 40% of CPU and have more than 1000 connections every minute. The only thing that is working for me is to ban dns.local.hass.io in the adguard. This lowers CPU usage to 2%

[ralong (Oskar Gawlik)]

I have the same problem. and I don’t really get it where the file is.
Do You mean i need to do it like this:
delete default_config: entry from configuration.yaml file, then add:

automation:
cloud:
config:
...

and so on?

[CentralCommand (Mike)]

Yes, that’s exactly it

[ralong (Oskar Gawlik)]

Ok. here is the code for other people to find in the future:
delete default_config: and add this to configuration.yaml file

#custom default config
automation:
cloud:
config:
counter:
#dhcp:
energy:
frontend:
history:
image:
input_boolean:
input_datetime:
input_number:
input_select:
input_text:
logbook:
map:
media_source:
mobile_app:
my:
person:
scene:
script:
ssdp:
stream:
sun:
system_health:
tag:
timer:
updater:
usb:
webhook:
zeroconf:
zone:

[aidbish (Adrian)]

What about a warning that any new service added by HA via default config, wont work until you manually add it now

[ralong (Oskar Gawlik)]

I really don’t know what im doing. I Installed HA today and I’m just trying to learn and fix some problems I’m having.