Hey.
I’m running DNSMasq to route my duckdns.org address to a local ip.
Working fine when queried from another machine.
I would like to point Home Assistant at that DNS server if possible, but when I do, it doesn’t seem to be able to hit it. Nothing resolves.
Is this expected behaviour? A limitation of Hassos?
Thanks. 
Yes home assistant can use itself for DNS. This is because DNS uses a client server model. The DNS Server software uses port 53 and the DNS Client software uses any random port above 1023. Whenever the client needs to resolve a DNS name it picks a random port then sends the message to port 53. Then the server software responds and sends the resonse back to whatever port the client opened. I use windows as my DNS but it works the same way. As you can see from the photo I have both running at the same time.
Hey, thanks for the quick reply.
I know a system can use itself for DNS. Have done this plenty of times in the past.
I can’t seem to get it working in Home Assistant OS though. Setting the DNS server to the internal IP (or to 127.0.0.1) results in no domain name resolution.
DNS continues to work for external clients. It’s very odd…
Are you trying the same IP that you use on the external hosts?
Yup. Same IP, statically assigned.
Seems like Hassos can’t hit it for some reason.
go to your ha-console(cli)
type:
ha dns
use --help after each command for further help
ha dns info
ha dns reset
ha dns restart
I’d tried ha dns before, but had joy.
Have revisited after your suggestion, and it appears there’s just a long delay before it returns a result, not an issue I’ve experienced with other clients.
Weirdly, it’s not returning the internal IP for my duckdns address, mapped in DNSMasq. No idea why. Works when queried from another client.
Any suggestions?
Just tried adding the DNS server via command line, which has improved the response time, but still returns the wrong result.
➜ ~ ha dns info
fallback: true
host: 172.30.32.3
llmnr: true
locals:
- dns://8.8.8.8
mdns: true
servers:
- dns://192.168.2.64
update_available: false
version: 2022.04.1
version_latest: 2022.04.1
➜ ~ dig xxx.duckdns.org
; <<>> DiG 9.18.11 <<>> xxx.duckdns.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43719
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 3a42cbd2a23f7632 (echoed)
;; QUESTION SECTION:
;xxx.duckdns.org. IN A
;; ANSWER SECTION:
xxx.duckdns.org. 60 IN A 1.2.3.4
;; Query time: 2091 msec
;; SERVER: 172.30.32.3#53(172.30.32.3) (UDP)
;; WHEN: Mon Mar 27 02:20:02 BST 2023
;; MSG SIZE rcvd: 95
Always helpful to use
dig +trace xxx.dyndns.org
HA needs to have a working DNS, so there is a hardcoded fallback DNS in the code.
When the entire host starts up, then the DNS might not started up for when HA needs it, so it uses the fallback and it might take some time for it to realize that the original DNS service is online and it can revert to it.
Older versions of HA also had a bug that often prevented it to revert, so make sure you are running a newer version of HA.
@WallyR Ah, so you think the dig response above (172.30.32.3) is actually coming from the built in DNS, rather than DNSMasq?
Could be.
I do not know how HA behave when those scenarios occur.
I only know of what I have read on this forum about it.
I found this article about it:
Progress, but not as expected!
Firstly, thanks for the link @WallyR . Hadn’t seen that.
Unfortunately, disabling the fallback didn’t change the result. Not what I was expecting.
I hadn’t considered that it might be DNSMasq causing the issue, so I just installed Adguard, had it listen on all available addresses, and it works perfectly!
Next guess is that DNSMasq isn’t listening on the right address to facilitate DNS requests from HA/Localhost?