I’ve installed HAOS into a VM that runs on Proxmox.
The network interface is configured by DHCP and the DNS settings seems to be configured properly but HomeAssistant can’t resolve local hostname.
Using the SSH Add-on I tried to perform an nslookup and the domain is resolved:
curl -v test.lab.lan
* Could not resolve host: test.lab.lan
* Closing connection 0
curl: (6) Could not resolve host: test.lab.lan
This is the output of the command “ha dns info”:
ha dns info
fallback: true
host: 172.30.32.3
llmnr: true
locals:
- dns://10.10.30.1
mdns: true
servers: []
update_available: false
version: 2022.04.1
version_latest: 2022.04.
and the local DNS server is configured properly.
I’m trying to connect to my local MQTT Broker (test.lab.lan) but HomeAssistant can’t resolve its local hostname.
Anyone can help? I tried to consult the following threads but no one was useful to solve this issue:
Going to quote myself from one of the threads you linked
This is the problem. You can see it in the output of the first command. Your DNS server is returning an answer for an A request for test.lab.lan but is returning NXDOMAIN for the follow-up AAAA request on that domain (ipv6).
This means your DNS server is not following DNS spec correctly. DNS servers are only supposed to return NXDOMAIN if the name truly does not exist for all types of queries. If it exists but there are no answers for some types of queries (like say because you don’t use ipv6) then it should return a NOERROR response without any answers.
Alpine based systems like HA require DNS servers follow the DNS spec in this regard for the reasons I mentioned above. If your DNS server returns NXDOMAIN for any queries on a name then HA, most of HAs addons and any other Alpine based systems will assume the name does not exist for all queries.
Dig is a tool for testing DNS queries. It does exactly the type of query you ask for and nothing else then shows you all the debug details you might need a out it. If you don’t specify a type of query then it makes an A one by default. To test an AAAA type request you must explicitly ask for one like this:
dig test.lab.lan AAAA
This is notably different from nslookup which you were using before. That specifically makes both an A and an AAAA type query on the name and shows all the answers it found.
Ok I got the point. I’ve checked on my router and I didn’t find any way to return NOERROR instead of NXDOMAIN for AAAA queries. Is there a way to force HomeAssistant to only use the A record?
No. This isn’t a home assistant restriction, this is a musl Linux restriction (which is what Alpine uses). See the explanation and commit I linked above.
If your current DNS server isn’t following spec correctly that’s usually ok since HA uses cloudflares DNS as a fallback DNS server for this exact reason, this problem is actually pretty common. But a fall ack DNS can’t help with a local domain name, it only helps with public domain names that are resolved incorrectly.
For the lan name I would suggest just using homeassistant.local. That name is broadcast and resolved using multicast DNS. Your DNS server isnt involved in mdns requests so it works correctly. If you have some devices that don’t support mdns then you can put an entry in your DNS server for homeassistant.local to cover those devices.
If that doesnt work for you then you’ll likely need to run a different DNS server on your network. Adguard works well for me personally but there’s plenty of other options as well.
EDIT: Sorry I forgot for a second this was about HA talking to another device not resolving it’s name. Ignore the homeassistant.local stuff, that doesn’t apply. I think you have 3 options:
if the device you want HA to talk to supports LLMNR or MDNS then then turn that on and use that. Both multicast protocols are fully supported and work correctly since your DNS server isn’t involved
use the IP address instead and reserve it in your router. I know that’s a bummer but its easier then #3 which is
install and run a new DNS server that correctly follows spec on your network
I would like to thank you for all the explanations you gave me. I followed the 3th approach you suggested, I’ve installed Pi-hole (that was something I planned to do) and I set a DNS request route from my main router to Pi-hole for my local domain “lab.lan”. In that mode all DNS requests that belongs to my local domain is been resolved by Pi-hole and it works like a charm.
Honestly i think there is something more sinister here, prob my lack of understanding of the topic but what i see is quite strange.
So i have a DNS server running with local domain u****.int and everything works like a charm… except for HA.
And where i see the most impact?
In ESPHOME addon where there is this really strange behavior:
i install a new esp device plugged into the usb port of HA server and configure, all works fine and it joins the Wifi network. If i unplug and give it power again it joins the wifi network and if i go to esphome interface it is online and i can get the logs by wifi.
Now if i reboot/restart HA the device will never return to status online neither i will get the logs from it by wifi… Why?
The i go to HA cli and run this test:
[core-ssh ~]$ dig co-sensor-garage.u*******t.int
; <<>> DiG 9.18.13 <<>> co-sensor-garage.unhuzpt.int
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6091
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 06f26743910d7c7a (echoed)
;; QUESTION SECTION:
;co-sensor-garage.unhuzpt.int. IN A
;; ANSWER SECTION:
co-sensor-garage.u******.int. 5 IN A 192.168.178.143
;; Query time: 3 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue May 09 07:18:45 CEST 2023
;; MSG SIZE rcvd: 85
All other hosts/devices in the network get a DNS response from the sensor no matter they use the FQDN or not. But why HA not???
It works the very first time i configure the esp sensor and added in esphome.
Of course if i edit manually the config file for each esphome device i install and change the address to use FQDN it will work but that is not the right way things should work.