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.
2 Likes
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
Yeah, I realized that after he replied. I saw the post opened in '20, then saw “Feb 20” Missed the fact there was no ’ in front of the 20. The formatting of date/time posts and replies are written is not exactly clear in this forum…
2 Likes
agree on that 
Not sure if this is the correct place to post this, but you guys seems to be knowledgeable regarding the DNS setup in Home Assistant.
I’m having errors that I think might be related to DNS basically not working at all, no external resolving, so any pointers here would be great. Did a fresh install of HAOS on an Intel NUC, running 10.5, and Home Assistant Core 2023.9.2.
I have the following DNS config:
This is the result when trying to resolve from HA:
So basically ignoring the config.
This is the DNS log from the built in log viewer:
This is the output from ha resolution info:
This is the settings in /etc/resolv.conf
This is the output from nslookup from a computer on my local network:
Any clues on what is going on and how DNS can have ended up so complicated and in this state?
Br
/Micke
Solved the issue, the DNS container might have been broken for some reason, a supervisor repair solved the issue so that DNS resolution works again.
So to be clear, this problem still is not solvable if you are running a standard docker installation? (homeassistant/homeassitant)
I’m running HA along with AdguardHome, and using unbound to forward to cloudflared or dnscrypt proxy, in docker containers. Since firing up AdguardHome in docker, HA won’t initialize basically any of my integrations.