Home Assistant gets me banned from quad9

[theseal]

The problem

I use my router as DNS resolver and recently changed its forwarder from Cloudflare to Quad9. This change in combination with the fact that I'm running Home Assistant in the same network caused a lot of headaches and connection issue - both in HA and the network in general. After some digging I found that Quad9 occasionally (sometimes every hour) temporarily banned my IP so any DNS queries times out.

Contacted the Quad9 support and their first question was if I was running Home Assistant (so the problem is probably spread) and linked to the forums: https://community.home-assistant.io/t/ha-spamming-ptr-dns-lookups/143687/88

The support stated that

We're receiving large PTR spikes from your IP that result in 20-minute blocks. Yes, the block duration are severe, because PTR spikes are the most-common attack vector for open recursive resolvers.

With tcpdump I could confirm the same behaviour that the forum threads describes - Home Assistant asks a lot of PTR records hourly which then bans me (an others?) for 20 min causing the internet of things to not be to happy.

With that said I'm wondering what the PTR querying really gain. Who has PTR records for their home network setup? I'm guessing very few which makes me wondering if this is a sane default to have in default configuration.

Can we make PTR querying optional or slow it down?

I would guess that this is related to #145708

What version of Home Assistant Core has the issue?

core-2025.6.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

dhcp

Link to integration documentation on our website

https://www.home-assistant.io/integrations/dhcp

Diagnostics information

No response

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

No response

[home-assistant]

Hey there @bdraco, mind taking a look at this issue as it has been labeled with an integration (dhcp) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of dhcp can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign dhcp Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

dhcp documentation
dhcp source
_{^{(message by IssueLinks)}}

[github-actions]

🔍 Potential duplicate detection

I've analyzed similar issues and found the following potential duplicates:

• #139957: DNS query burst after upgrade

What to do next:

1. Please review these issues to see if they match your issue
2. If you find an existing issue that covers your problem:
   • Consider closing this issue
   • Add your findings or 👍 on the existing issue instead
3. If your issue is different or adds new aspects, please clarify how it differs

This helps keep our issues organized and ensures similar issues are consolidated for better visibility.

This message was generated automatically by our duplicate detection system.

[bdraco]

We already exclude public DNS services from reverse lookups, since they won’t return meaningful results for internal IPs.

https://github.com/Bluetooth-Devices/aiodiscover/blob/49ba37a6a7aa63522432ebbdf6e8fe6874934da0/aiodiscover/network.py#L168

[bdraco]

My guess is that something internal is forwarding the DNS requests externally. So even though aiodiscover excludes external DNS servers, the internal DNS server may be forwarding those queries to a public resolver. If that’s the case, it's a bit surprising since a DNS server typically shouldn't forward internal reverse lookups to the public internet. This might point to a misconfigured DNS forwarder.

We recently changed the server lookup order in response to this issue.
It's possible that change is contributing to the problem, but we need a clearer picture of what's going on before considering a revert.

[theseal]

Good that you already tried to handle external resolvers!

Pi Hole, AdGuard and similar seems very popular nowadays and ends up a local resolvers. I don't know if they are configurable to not forward local PTR or if they forward requests at all, they might even do the whole DNS dance themselves. I think it's very likely that they will forward the request upstream which then will make the attempt of excluding public resolvers not work.

My router (Mikrotik) is not capable to not forward local PTR requests - it's mostly used as a cache but can store static records (which I just now learned creates a PTR for each A and AAAA 🤯).

Do you think most users gain something from the PTR querying? Feels like a waste of CPU cycles and network traffic. Disable by default and let power users enable it?

[bdraco]

Do you think most users gain something from the PTR querying?

Yes a large number of home and office routers (including unifi which is one of the most common) map their dhcp names to PTRs.

Disable by default and let power users enable it?

Disabling by default would break a large number of users expecting their devices IPs to update automatically when the dhcp reservation changes and Home Assistant has been offline, upgrading, or restored. They would have to wait 24-48 hours for a new dhcp reservation to be seen for the new IP to be found and the device to come back online which would result in some very unhappy users.

[theseal]

Do you think most users gain something from the PTR querying?

Yes a large number of home and office routers (including unifi which is one of the most common) map their dhcp names to PTRs.

Ah, of course Unifi handles it! Quite popular in this community as well.

Disable by default and let power users enable it?

Disabling by default would break a large number of users expecting their devices IPs to update automatically when the dhcp reservation changes and Home Assistant has been offline, upgrading, or restored. They would have to wait 24-48 hours for a new dhcp reservation to be seen for the new IP to be found and the device to come back online which would result in some very unhappy users.

I understand, especially now when I know that Unifi creates PTRs. Does Unifi handle forwards request as well or do they forward non matching entities upstream?

Maybe a toogle could be on as default but possible to disable if behaviour isn't desirable.

I will reach out to Mikrotik and ask about their option on forwarding PTRs for the local network.

[bdraco]

Does Unifi handle forwards request as well or do they forward non matching entities upstream?

Unifi handles it correctly and returns NXDOMAIN and does not forward upstream

[bdraco]

Maybe a toogle could be on as default but possible to disable if behaviour isn't desirable.

That’s a good suggestion! We could add a WebSocket API to toggle the behavior, store the preference so it sticks, preload it during bootstrap, and include a new option in the frontend under the network settings that can be unchecked.

That said, it’s a fair bit of work, and ideally the router vendor would just fix their implementation. So while it’s something we could consider for the future, it’s not high on the list for now.

[theseal]

We already exclude public DNS services from reverse lookups, since they won’t return meaningful results for internal IPs.

https://github.com/Bluetooth-Devices/aiodiscover/blob/49ba37a6a7aa63522432ebbdf6e8fe6874934da0/aiodiscover/network.py#L168

This seems not to work I'm afraid.

Changed my resolver in the router (option 6 in the DHCP ACK) to 9.9.9.9 and once again got banned from quad9.

To not mess up my internet again I then changed the resolver option to cloudflare (1.1.1.1) during debugging since they seem not as disturbed with PTR records as quad9.

The following is captured after a reboot of Home Assistant so to my knowledge there is no cached data available (if it ever was?).

I can see with tcpdump that option 6 is only set to one server, 1.1.1.1.

Frame 4: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits)
Ethernet II, Src: Routerboardc_ (), Dst: NabuCasa_ ()
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.1.50
User Datagram Protocol, Src Port: 67, Dst Port: 68
Dynamic Host Configuration Protocol (ACK)
    Message type: Boot Reply (2)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xb956b8cb
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 192.168.1.50
    Next server IP address: 192.168.1.1
    Relay agent IP address: 0.0.0.0
    Client MAC address: NabuCasa_ ()
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (ACK)
    Option: (1) Subnet Mask (255.255.255.0)
    Option: (3) Router
    Option: (6) Domain Name Server
        Length: 4
        Domain Name Server: 1.1.1.1
    Option: (42) Network Time Protocol Servers
    Option: (51) IP Address Lease Time
    Option: (54) DHCP Server Identifier (192.168.1.1)
    Option: (255) End
    Padding: 0000000000000000000000000000000000000000

After a while Home Assistant starts to request PTR records from 1.1.1.1. E.g

Frame 323: 96 bytes on wire (768 bits), 96 bytes captured (768 bits)
Ethernet II, Src: NabuCasa_ (), Dst: Routerboardc_ ()
Internet Protocol Version 4, Src: 192.168.1.50, Dst: 1.1.1.1
User Datagram Protocol, Src Port: 49259, Dst Port: 53
Domain Name System (query)
    Transaction ID: 0x9f67
    Flags: 0x0100 Standard query
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        84.1.168.192.in-addr.arpa: type PTR, class IN
    Additional records
        <Root>: type OPT
    [Response In: 329]

What's even more odd to me is that after going through my whole subnet with PTR requests Home Assistant starts again against my router

Frame 665: 107 bytes on wire (856 bits), 107 bytes captured (856 bits)
Ethernet II, Src: NabuCasa_ (), Dst: Routerboardc_ ()
Internet Protocol Version 4, Src: 192.168.1.50, Dst: 192.168.1.1
User Datagram Protocol, Src Port: 34227, Dst Port: 53
Domain Name System (query)
    Transaction ID: 0x4b2c
    Flags: 0x0100 Standard query
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        1.1.168.192.in-addr.arpa: type PTR, class IN
    Additional records
        <Root>: type OPT
    [Response In: 675]

At this stage there is to my knowledge NO information anywhere that states that 192.168.1.1 should be a DNS resolver of any kind. It just happens to be started and unfortunately responds to the requests which in both cases will get me banned.

[egerlach]

I'm running into this issue as well: I was getting rate-limited by Quad9. I have to agree with @theseal's most recent comment: my HA's resolv.conf (in its container) has only quad9 listed. There's no internal resolver there.

I can try to hook my installation up to a debugger, but I'm not sure if that's needed. Let me know if it would be useful.

[ztheory]

Greetings from Quad9.net,

To add context, we're currently seeing around 1 support ticket per week where we identify Home Assistant's bulk PTR queries as the root cause of rate limiting/blocking. There could be significantly more that never report this issue to Quad9.

My guess is that something internal is forwarding the DNS requests externally. So even though aiodiscover excludes external DNS servers, the internal DNS server may be forwarding those queries to a public resolver. If that’s the case, it's a bit surprising since a DNS server typically shouldn't forward internal reverse lookups to the public internet. This might point to a misconfigured DNS forwarder.

There are very few consumer-grade routers that are mindful enough to include RFC-1918 and IPv6-equivelent PTR zones as local zones by default. Many will recurse to the DNS Servers set in the router.

Configuring a third-party DNS service in the router's DNS Server settings (not DHCP) is typically recommended, so that all devices connected to a local network use the desired DNS servers without individual configuration, and so the router acts as a network-wide cache, as opposed to configuring the DNS IPs in DHCP assignment.