HA spamming PTR DNS lookups?

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

1 Like

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. :slight_smile:

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?

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

1 Like

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.

1 Like

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.

2 Likes

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.

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.

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

For me this helped:

The same issue for me.

Latest Home Assistant OS. Adguard home installed. Nothing from the advices above help me :frowning:
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%

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?

1 Like

Yes, that’s exactly it

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:
1 Like

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

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.

Sadly this didn’t do anything for me:
Still over 4000 queries from HA every hour

This is huge problem for me also, the logs are essentially flooded by these arpa dns lookups and they grow very big very quickly. The lookups take place exactly once per hour and range from 1 to 254 in reverse order (eg. 242.1.168.192 instead of 192.168.1.242).
Is there at least a way to change the log level of hassio-dns container?

Same problem for me…

almost all queries maked from HA

Still no solution for that?

In the end I reset the DNS-configuration in HA and all of my issues disapeared:

ha dns reset
ha dns
ha dns options --servers dns://192.168.xxx.yyy --servers dns://192.168.xxx.zzz

1 Like

Hi All,
first time here.

I subscribed to share my attempts at solving similar problem of floods of PTR records in my PiHole server generated by HA (PiHole is physically another server).

Apparently I solved by:

  • Configuring HA DNS servers in the Web GUI as explained above by @lennardw
  • Disabling ‘default_config:’ and adding each config “pieces” as explained by @ralong disabling DHCP, SSDP and ZEROCONF.
  • Rebooting HA server

Only few hours since I did that but so far so good. Finger crossed…

Hope this helps.
A