Good to know, thanks for that, sadly I fall under the last category:
# resolvectl status 3
Link 3 (enp0s3)
Current Scopes: DNS LLMNR/IPv4 mDNS/IPv4
Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.103.33
DNS Servers: 192.168.103.33 192.168.103.32 192.168.103.31
DNS Domain: <bla>.local
Oh sorry to be clear I meant there’s a race between your configured DNS servers. Even if you enable the fallback it will only be tried after all of those. But I couldn’t tell you which one of those 3 you’ll get an answer from, it should be whichever responds first.
EDIT: Actually I forgot, there’s no races. It uses policy sequential:
I forgot we had to leave that so any DNS overrides added in HA by users via ha dns options --servers were used first. But either way the fallback is not in the forward list anymore, it only happens if all else fails.
This rural ISP here has pretty awful tech support. I’ll try to see if they can enable IPv6 or even have firmware updates that may address this DNS issue. Given that they refused to enable bridge mode on their provided required router so that I can use my ASUS/Merlin routers to manage connections, I have little hope they will help.
Sounds like my best option is to install the DNSMASQ addon and point everythingHASS to its own DNS.
Thanks again for all your help.
Following up… Local ISP updated Calix Gigacenter router firmware. No change. The agent then switched my router to IPv6 Internet connectivity only, saying (incorrectly) that having both IPv4 and IPv6 (dual-stack) wasn’t possible. And that now it has been switched to IPv6, they will lose remote connectivity for support.
it didn’t work. Internet access was dead. They had to send out a technician to come on site to diagnose it. He then configured it for dual-stack so IPv4 was back online, but IPv6 still not working. So back to IPv4-only. Painful, but worth trying. Hello DNSMASQ.
can this be automated when the container starts? it is really annoying to do this every time you restart the haos.
I suppose that yes, a copy command to the container can be done, but I changed my router to a OpenWrt one and since then the problem is gone to me.
This suggestion is quite old. The ability to disable the fallback DNS has been added a while ago. Not sure why you’d still need to do this.
EDIT: Oh I see, this isn’t about fallback. Guessing your local DNS server is responding with NXDOMAIN for AAAA queries on your local domain? Is there a bug open for the DNS software you use? That goes against the DNS spec so it should be one.
I think i’m facing a similar issue. While trying to establish TTS notifications, i noticed that Homeassistant is unable to connect to it’s own hostname. I’m using Duck DNS to get a certificate and Hostname that points to my dynamic WAN-IP. My Homeassistant is reachable from outside my local LAN and from the inside, as i have a local dns-resolver (Pi-Hole) that translates that hostname from Duck-DNS into the local LAN IP. However Homeassistant itself seems unable to resolve its own FQDN using the internal DNS-resolver. Homeassistant is configured to use Pihole as the DNS-Server.
From an SSH-shell on my Homeassistant-Box (Pi4), i tried explicit
nslookup <homeassistant-fqdn> <pi-hole-dns-server-ip>
but there is no corresponding query in the pihole logs nad Homeassistant’s duckdns-fqdn gets resolved to its WAN-IP.
On every other machine in my network, this works and resolves correctly to the internal LAN-IP.
I assume, that Homeassistant is still forwarding its queries to an external resolver although it has been configured to use the internal and fallback-option to be disabled.
I just got it to work by using “SSH & Web Terminal”-Addon to enter the docker-container “hassio_dns” to edit the hosts-file. I just added the duck-dns-fqdn for my installation pointing to its local LAN-IP.
However: i don’t know if this has any other implications nor if it will survive reboot and updates.
There should be a simpler solution to this obscure black magic hacks.
Is there any documentation on how homeassistant’s name-resolving works in detail and how/when it uses the local dns-server that is configured via webgui and/or SSH?
Some extra dns info can be gotten in the terminal window :
[core-ssh ~]$ ha dns info
fallback: true
host: 172.30.32.3
llmnr: true
locals:
- dns://192.168.11.253
- dns://192.168.11.1
mdns: true
servers: []
update_available: false
version: 2022.04.1
version_latest: 2022.04.1
[core-ssh ~]$
ha dns info and Nslookup on homeassistant:
➜ ~ ha dns info
fallback: false
host: 172.30.32.3
llmnr: true
locals:
- dns://192.168.30.1
mdns: true
servers:
- dns://192.168.30.1
- dns://192.168.15.1
update_available: false
version: 2022.04.1
version_latest: 2022.04.1
➜ ~ nslookup <SECRET>.duckdns.org
Server: 172.30.32.3
Address: 172.30.32.3#53
Non-authoritative answer:
Name: <SECRET>.duckdns.org
Address: 77.<SECRET>.<WAN>.<IP>
➜ ~ nslookup <SECRET>.duckdns.org 192.168.30.1
Server: 192.168.30.1
Address: 192.168.30.1#53
Non-authoritative answer:
Name: <SECRET>.duckdns.org
Address: 77.<SECRET>.<WAN>.<IP>
➜ ~ nslookup <SECRET>.duckdns.org 192.168.15.1
Server: 192.168.15.1
Address: 192.168.15.1#53
Non-authoritative answer:
Name: <SECRET>.duckdns.org
Address: 77.<SECRET>.<WAN>.<IP>
FQDN gets resolved to WAN-IP. Note that no entries in the query log appear on the local dns-server. So my guess is, that despite homeassistant is telling me its asking the local DNS in doesn’t.
Nslookup on another box in my LAN resolves to the local IP:
┌──(ubuntu🌍unimatrixzero)-[~]
└─$ nslookup <SECRET>.duckdns.org 192.168.30.1
Server: 192.168.30.1
Address: 192.168.30.1#53
Name: <SECRET>.duckdns.org
Address: 192.168.30.190
┌──(ubuntu🌍unimatrixzero)-[~]
└─$ nslookup <SECRET>.duckdns.org 192.168.15.1
Server: 192.168.15.1
Address: 192.168.15.1#53
Name: <SECRET>.duckdns.org
Address: 192.168.30.190
This is why i’m trying to understand the namelookup process within homeassistant.
Why is the behaviour of homeassistant different here?
Writing the FQDN to the hosts-file of the “hassio_dns”-container works but it doesn’t survive a container restart.
Is there a possibility to make permanent entries to the hosts-file, so that they survive container restarts, system reboots and updates?
i used to need this add-on for proper dns resolution : HomeAssistantAddons/core-dns-override at master · bentasker/HomeAssistantAddons (github.com)
Might be of use to you.
All the reasons given for the existence of that addon in the readme have since been fixed.
If the DHCP/Owner configured DNS server responds with REFUSED, SERVFAIL or NXDOMAIN rather than being respected, the query will be retried via Cloudflare
The fallback DNS can now be completely disabled with ha dns options --fallback=false
The “fallback” (127.0.0.1:5553) is specified in the main pool, so will sometimes be used instead of the configured DNS
It’s not anymore. That addon is showing an old version of the config file.
Behaviour has been observed where it then won’t switch back to local DNS for later queries
This was related to the point above which has been fixed. Also the fallback can be entirely disabled.
Queries sent to cloudflare will be unable to resolve local names
Where queries are sent to CF, local DNS names may be leaked
Right. Hence why an option was added to disable the fallback
HomeAssistant users have, in effect, been signed up to this without their knowledge
True. Cloudflares DNS is still the fallback default. The reason this is still true is here. But again if you are one of the users who run their own DNS server and this bothers you it can be disabled.
Health check probes will be sent to cloudflare every 5 minutes
It no longer healthchecks cloudflare at all, has also been changed in the config.
Besides I’m not sure how that addon would help @derco0n given this:
The hassio_dns container is giving the same response as nslookup queries aimed directly at their DNS servers. The latter two nslookup queries don’t involve the DNS containers at all, if they are returning the wrong thing then something else is going on. especially if none of those are actually asking the DNS server, even the nslookup requests directly targeted at it.
It seems like something is cached is my guess. @derco0n clearly you’ve restarted the DNS container during this since you said things didn’t persist but have you restarted the ssh container or the host itself? Just to clear out any cached DNS answers in the various containers.
Thank you @CentralCommand for your response. Yes i restarted multiple times using
ha dns restart
and i even rebooted the system multiple times during my testing.
Using the following commands, i can force a host entry in the hosts-file within the “hassio_dns”-container, which might be a dirty workaround. However this isn’t a persistent solution.
➜ ~ nslookup <SECRET>.duckdns.org
Server: 172.30.32.3
Address: 172.30.32.3#53
Non-authoritative answer:
Name: <SECRET>.duckdns.org
Address: 77.<SECRET>.<WAN>.<IP>
➜ ~ docker exec -i hassio_dns cat "/config/hosts"
127.0.0.1 localhost localhost.local.hass.io
172.30.32.2 hassio hassio.local.hass.io supervisor supervisor.local.hass.io
172.30.32.1 homeassistant homeassistant.local.hass.io home-assistant home-assistant.local.hass.io
172.30.32.3 dns dns.local.hass.io
172.30.32.6 observer observer.local.hass.io
172.30.33.0 core-mosquitto core-mosquitto.local.hass.io
172.30.33.2 core-duckdns core-duckdns.local.hass.io
172.30.33.3 15d21743-samba-backup 15d21743-samba-backup.local.hass.io
172.30.32.1 5c53de3b-esphome 5c53de3b-esphome.local.hass.io
172.30.33.4 core-configurator core-configurator.local.hass.io
172.30.32.1 a0d7b954-ssh a0d7b954-ssh.local.hass.io
➜ ~ echo "192.168.30.190 <SECRET>.duckdns.org" | (docker exec -i hassio_dns sh -c "cat >> /config/hosts")
➜ ~ docker exec -i hassio_dns cat "/config/hosts"
127.0.0.1 localhost localhost.local.hass.io
172.30.32.2 hassio hassio.local.hass.io supervisor supervisor.local.hass.io
172.30.32.1 homeassistant homeassistant.local.hass.io home-assistant home-assistant.local.hass.io
172.30.32.3 dns dns.local.hass.io
172.30.32.6 observer observer.local.hass.io
172.30.33.0 core-mosquitto core-mosquitto.local.hass.io
172.30.33.2 core-duckdns core-duckdns.local.hass.io
172.30.33.3 15d21743-samba-backup 15d21743-samba-backup.local.hass.io
172.30.32.1 5c53de3b-esphome 5c53de3b-esphome.local.hass.io
172.30.33.4 core-configurator core-configurator.local.hass.io
172.30.32.1 a0d7b954-ssh a0d7b954-ssh.local.hass.io
192.168.30.190 <SECRET>.duckdns.org
➜ ~ nslookup <SECRET>.duckdns.org
Server: 172.30.32.3
Address: 172.30.32.3#53
Name: <SECRET>.duckdns.org
Address: 192.168.30.190
Is there a possibility to run the command
echo "192.168.30.190 <SECRET>.duckdns.org" | (docker exec -i hassio_dns sh -c "cat >> /config/hosts")
on each reboot? Unfortunately an automation doesn’t work for this, as automations run within the “homeassistant”-container as far as i know.
Thanks very much everyone for the detailed technical discussion that helped me to understand the problem. My router recently updated the dnsmasq to version 2.88, that suddenly from v2.86 started returning NXDOMAIN for non existent IPv6 records for local domains instead of previous NODATA-IPv6. Or to be more precise, it forwards them upstream which is obviously nowhere in this case.
So to make it work - the less than ideal workaround is to add another entry into dnsmasq.conf file for the dummy (localhost - :: ) IPv6 address, so something is returned for the AAAA query, but IPv4 result of the A query is still used.
address=/router.home/192.168.1.1
address=/router.home/::
Ideally, there would be a dnsmasq option to change that behaviour and also Home Assistant should not be asking for IPv6 addresses, when IPv6 is disabled.
Just wanted to give you and my future self a nudge.
I resolved my issue using the unofficial Addon "Run On Startup.d", which i use to add a custom entry to the hosts file of the hassio_dns-container:
➜ ~ cat /config/startup/startup.d/hassio_dns.sh
#! /bin/bash
echo "This script is executed in the hassio_dns container";
env;
echo "192.168.30.190 SECRETHOSTNAME.duckdns.org" >> /config/hosts;
This way, everytime homeassistant boots, the Hostname gets an entry with it’s local IP.
That’s an innovative use. I had never thought to modify DNS entries.
Maybe it helps someone with “.local” dns problem: HA OS does not resolve .local hostnames(Solved) - #7 by robot468
uhhh… You’re aware that you just necro’d a 3 year old thread, yes?
Yeah, it’s just the most informative thread on a problem I’ve encountered. Perhaps those who encounter it later will also find this thread.
it’s true it was “opened” 3 years ago, but if you bother to look through, or just alittle bit up in the posts, i.e Feb 20, that’s in 2023 
etc. etc. so frankly a very “alive” topic still