HA spamming PTR DNS lookups?

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

@alvarobas
So how is it going after those few days?

Working ok, problem solved :slight_smile:

Thanks all for the suggestions!

I’m asking because it didn’t work for me.
But I’m happy that it works for someone :slight_smile:

Interesting discussion!

It’s a shame that the -n parameter for nmap is not honoured. That should fix the problem. When testing on my Macbook the -n parameter works like a charm! Without I get many reverse lookups in PiHole and with the parameter I don’t get them.

Some thoughts I had on how to fix this:

  1. prevent PiHole from recording reverse lookups in the log: FAIL
  2. prevent HA from doing reverse DNS lookups: FAIL
  3. prevent reverse DNS lookup traffic from entering PiHole or leaving HA using a firewall? Can the firewall distinguish between normal DNS traffic and reverse lookups? HOW?
  4. populate the HA /etc/hosts file with all devices? FAIL
  5. stop using nmap and use the configurable ping instead (not dynamic): OK

Would it be an option to file a bug/find out why -n does not seem to be used?

Cheers
DJ

1 Like

Devices flooding pihole with PTR requests

Here’s the Fix:

  1. SSH or log into your pihole
  2. Run the command: sudo vi /etc/pihole/pihole-FTL.conf (or whatever text editor you use)
  3. Add the line: ANALYZE_ONLY_A_AND_AAAA=true
  4. Save the file. [ESC] + :wq - for vi
  5. Run the command: sudo pihole restartdns
1 Like

PTR request quantity came back to normal after I re-configured pi-hole.

pihole -r

I’m not completely sure what was the issue, but I suspect it was due a recent change on pi-hole’s server IP address. After this change I just pointed DNS to the new IP and everything seems to be fine, except for this burst of +400k PTR requests / day. Immediately after “pihole-r”, no more PTR request (I didn’t even restart home-assistant).

Seeing the PTR messages on Fresh Install without PiHole or AdGuard - Why?

Hi, I know this is an old post, but I’m also seeing hundreds of PTR messages logged every hour, on a fresh HA install (Pi4 Supervised) with only Mosquitto and Tasmota integrations configured. And, unlike most posts above, I’m not using PiHole or AdGuard (as far as I know?).

Yet I’m still seeing these reverse DNS lookups every hour for the 1.1.168.192.in-addr.arpa to 254.1.168.192.in-addr.arpa ranges.

So I guess my questions are:

  1. Is this normal/expected behaviour? It doesn’t seem to be causing a problem, it just seems odd.
  2. Can I change something to at least cut down the logging. This generates 12,000 syslog entries per day which is really cluttering up the log files.
Aug 18 10:08:07 localhost x9b[602]: [INFO] 127.0.0.1:57553 - 61215 "PTR IN 1.1.168.192.in-addr.arpa. udp 53 true 2048" NXDOMAIN qr,rd,ra 42 0.044268299s
Aug 18 10:08:07 localhost x9b[602]: [INFO] 172.30.32.1:43556 - 61215 "PTR IN 1.1.168.192.in-addr.arpa. udp 42 false 512" NXDOMAIN qr,rd,ra 42 0.057752538s
Aug 18 10:08:07 localhost x9b[602]: [INFO] 127.0.0.1:57553 - 46571 "PTR IN 2.1.168.192.in-addr.arpa. udp 53 true 2048" NXDOMAIN qr,rd,ra 42 0.015852347s
Aug 18 10:08:07 localhost x9b[602]: [INFO] 172.30.32.1:43556 - 46571 "PTR IN 2.1.168.192.in-...

What is this log from?

Hi Nick, is the Debian Linux /var/log/syslog log file, from a HA node on a Pi 4.

So your Debian box is running your DNS server.

Perhaps run DNS so as it does reverse DNS lookups properly.

Nick, I’m not really sure what point you are making. This is a vanilla Debian installation, and it is not configured as a DNS server. The Home Assistant installation is also very basic, but includes - as standard - a dns container, see below. So if there is a problem, and I don’t know that there is because the reverse lookups aren’t actually failing, I can only assume its within HA. Not the Debian OS. I’m simply trying to understand what is generating the lookups, and how I can stop the log files getting cluttered.

CONTAINER ID   NAME                      CPU %     MEM USAGE / LIMIT     MEM %     NET I/O          BLOCK I/O         PIDS
cb8b0a320a9a   addon_core_configurator   0.02%     22.55MiB / 3.703GiB   0.59%     5.88MB / 0B      21.7MB / 119kB    4
fcb30028bbff   addon_core_mosquitto      0.03%     62.73MiB / 3.703GiB   1.65%     6.12MB / 163kB   56.6MB / 311kB    16
ee5ce65f9ee6   hassio_multicast          0.04%     960KiB / 3.703GiB     0.02%     0B / 0B          53.2kB / 111kB    4
c727419c6e8c   hassio_audio              0.34%     23.5MiB / 3.703GiB    0.62%     5.89MB / 0B      21.4MB / 324kB    13
b041d352914e   hassio_dns                0.00%     19.76MiB / 3.703GiB   0.52%     9.18MB / 1.7MB   25MB / 119kB      13
d9cdf81a57a1   hassio_cli                0.00%     3.785MiB / 3.703GiB   0.10%     5.89MB / 806B    11.3MB / 291kB    6
644a880db29d   homeassistant             0.21%     333MiB / 3.703GiB     8.78%     0B / 0B          160MB / 240MB     31
cece14c1cdae   hassio_supervisor         0.00%     158.8MiB / 3.703GiB   4.19%     9.92MB / 13MB    72.2MB / 1.23MB   21
7f63ea18df69   hassio_observer           0.00%     14.8MiB / 3.703GiB    0.39%     6.12MB / 160kB   12.2MB / 106kB    8

Update: I’m also seeing this on a VirtualBox VM - so its not specific to a Raspberry Pi.

If no solution was post on this. I found what this regarding on.


Do this and you are good to go. All the request stop.

1 Like