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.
can you give me a list on what to enable from default_config?
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
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. 
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
PTRqueries for my LAN’s private IPs in the AdGuard query logs, some of which my router answers with the hostname for the IP andNOERROR.
- There continue to be a non-annoying number of
- Most of the queries were IPv4 (
*.in-addr.arpa), some were IPv6 (*.ip6.arpa).
My HA OS nameservers are (in-order):
- AdGuard Home (HA OS private IP)
- My router’s private IP. The router runs its built-in DNS server (Unifi UDM)
- 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 
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.
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?