Local DNS!

[modelstudent101]

And you don’t have any issues?

Even if you disable IPv6 in Home Assistant, I believe it uses IPv6 link-local addresses for communication between containers. However, the issue I’m mentioning is partly due to the specific response served when HA queries for an AAAA (IPv6 DNS) record… even when it is disabled, Home Assistant still sends the AAAA query to the DNS server, and prioritizes that response. Some DNS servers, mostly locally run, will either not respond (which causes a SERVFAIL) or respond with NXDOMAIN, even though the A (IPv4 DNS) record is valid and exists.

In many cases, this causes the domain to appear as non-existent to Home Assistant.

[Chykan (Hunter)]

No I have issues, thousands of PTR requests. Does not cause any issues on the surface but is in the DNS logs. All of the IP addresses are leases that are not occupied in my router.

This is with IPv6 set to Automatic in HA Network Settings. Disabling DHCP fixes it for a short while and then it comes back.

With dhcp disabled with default_config_disabler and performing the below commands in terminal

ha dns reset
ha dns restart

I get the below

This is what happens on startups

[modelstudent101]

Ah, yeah I have the same PTR issue. The i/o timeouts on startup never resolved until I created a manual iptables rule, but I think it’s essentially the same issue. The DNS provider is 1) dropping the IPv6 query, causing the i/o timeout (notice the timeouts are all AAAA requests, which HA is prioritizing); and 2) sending the PTR requests out to the upstream DNS provider, which is returning NXDOMAIN (which is accurate).

It seems like your DNS server (assuming it’s provided by your internet provider) is responding in the way that Alpine doesn’t like. Additionally, they may be re-routing traffic to external DNS servers (i.e. attempts to reach 8.8.8.8 or 1.1.1.1) to their own DNS server, which might explain why some people have been able to fix their problems by changing the provider (Timeout while contacting DNS servers).

I haven’t dug into the PTR requests yet, but it’s my working theory anyhow. The HA team seems to have taken the stance that the way Alpine musl handles AAAA records is correct, although it is debatable. I don’t know much about Unifi, so I don’t know if you can run your own dnsmasq/Unbound instances, but I’ll give you a brief overview of my workflow.

1. IPv6 disabled on router
2. Unbound has IPv6 enabled (do-ip6: yes, prefer-ip6: no) to allow Alpine to get its AAAA requests
3. dnsmasq serves DNS requests via its cache; if a request is not cached, it forwards the request upstream to Unbound
4. All inbound and outbound IPv6 routes are dropped by iptables rules
5. All requests from containers in the subnet 172.30.32.0/24 are routed back to the proper containers using NAT rules

My other working theory is that HA DNS requests from containers were previously translated within HA; so, when the request would go out, it would be come from the main HA instance (i.e. 192.168.1.x or whatever your local IP for HA is).

So, the container would send the request to HA’s dns, which would then forward it upstream. The response would then go back to HA, which would route the response back to the container.

I think the DNS requests are now leaking from the containers if IPv6 is disabled in Home Assistant, so the router sees the request coming directly from the container at 172.30.32.x, instead of HA. Thus, the response is sent to 172.30.32.x – which doesn’t exist on the local network – so Home Assistant never gets the response.

EDIT: NAT is network address translation. So, the router sees the request, translates it before sending it to the DNS provider so that the response will come back to the router instead of where the packet originated. The router then receives the response, and sends it back to where it came from. HA can then properly route it to the correct container.

[Chykan (Hunter)]

Home Assistant Network Settings

Unifi has the following options

Under Network Options

If unchecking auto given these options.

Under Internet Options

if unchecking Auto

I just found a new box at the bottom of the HA Netwok Setting Page. Network Discovery

Clicking in SSDP I get the following. DHCP is blank as I have DHCP turned off at the moment.

[Benji2020]

I didn’t realise it was so long since I started this thread, March 2020… 75.4k views and 56 users later and still having problems, and no official “this is how it all works” even.

[Chykan (Hunter)]

You are correct. Something you would think would have some sort of resolve.

[modelstudent101]

Because the HA library is developed on Alpine Linux, and they aren’t going to change that, they have sort of taken the response that there is nothing they can do; I suspect they rely upon IPv6 link-local addresses for communication between add-ons and docker containers within HA. It’s very strange how much pushback they gave about disabling the hard coded DNS fallback servers and I don’t know how much of the core team has network administration experience. You would think a platform that is all about communication between different services on a network would have more of a focus on it, but I am not a developer by trade and can only speculate.

HA is sort of in a weird place. They rely heavily on community volunteers to create and maintain the libraries for integrations. They also make breaking changes regularly in an attempt to make it easier for people who do not have much experience with this stuff. While they have general principles in place, it’s a huge undertaking, given what I assume to be a major driving force in decisions—compatibility with as many different services as possible.

It feels like a lot of the power users spend a few years heavily investing in HA, and then fizzle out. I know the amount of times I’ve pushed an update and then found out several of my necessary integrations or automations have broken has caused me days of frustration as I try to get the lights in my house working again.

My experiences have also led me to target HA’s DNS as a first step in troubleshooting unresponsive integrations; I’ve also been running HA since around 2018-2019, and the DNS issues have arisen several times throughout the years.

[marktheraptor]

That’s because they keep insisting on having the system cover the 95% of the use cases and not following the damn specs. They fortunately gave up on the “I want to push my resolver no matter what” and at least now there is a way to allow the user to tell the entire thing to call the DNS server that the user configured along the IP address/netmask and gateway. You wouldn’t try to deliver frames to another IP address that’s not your default gateway, right? If the user said that the default gateway is the .69 why on Earth they want to push to deliver frames to .1? That’s the same thing they kept doing with DNS.

[modelstudent101]

I’m with you.

What differentiates Home Assistant from other platforms is the idea that people should be able to exercise control over their devices and network. The backlash against any company that requires cloud connected services is often led by this community, and some of the developers here.

But they have this weird bifurcated approach: we want to be the most customizable and open home automation environment, yet we are going to block users from controlling how that information is communicated. It doesn’t make any sense that one of the foundational protocols for routing information has been walled off.