Have seen a little on Thread & Matter, just assumed HA would use NAT64 if ipv6 was unavailable on the host side of the network. My ISP doesn’t support ipv6 and neither does my router 
Maybe. Like I said, I also have a lot of learning to do in this space. Sorry didn’t mean to get off topic, really just meant to point out that it was going to become more important soon.
2 Likes
Thank you so much for taking over this. Really appreciate and would be happy to support!
5 Likes
Hi Mike, I’ve only just discovered your post via a post by balloob on reddit. Just to let you know I have been running the supervisor 2022.4.2 beta pretty much since it came out a week ago. Zero issues here. 
1 Like
FYI all I’ve added an option to disable the fallback DNS to the beta channel. You will actually need to be on the beta channel to try it out in this case as it involved updates to multiple components:
- Add a new option to enable/disable the fallback DNS to supervisor’s API
- Update the CLI to support this new option
- Update the DNS plugin to understand this new option
If you want to try it out I would appreciate the feedback. If you would prefer not to switch to the beta channel I understand. Assuming no issues it should make it to stable soon.
To use it is a bit tricky at the moment because the SSH add-ons will need to update to use the new version of the CLI. That won’t happen until it is available in the stable channel. So what you’ll need to do is SSH into one of the addons and then call supervisor’s API directly like this:
curl -X POST http://supervisor/dns/options \
-H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" \
-H "Content-Type: application/json" -d '{"fallback": false }'
You can confirm it worked with the following command, fallback should be false in the output:
> ha dns info
fallback: false
host: 172.30.32.3
llmnr: true
...
The info command is able to show this because it simply prints everything in the output even if its something new its never seen before (like fallback). The options command does require an update to add support for new flags. Once this change does make it to stable and the SSH add-ons are updated then you will simply be able to do this to enable/disable the fallback DNS:
ha dns options --fallback=false
I also want to note that doing this will not necessarily mark your system as unsupported. It will only mark your system as unsupported if we detect an issue with one of the other DNS servers you provided. The two issues we are looking for are:
- DNS server unable to resolve A query on
_checkdns.home-assistant.io - DNS server returns status other then NOERROR for AAAA query on
_checkdns.home-assistant.io. See here for why that is a problem.
If you have one of these issues you will see it when you execute the following command:
ha resolution info
The fallback guaranteed us a DNS server able to resolve the names we need it to correctly. Without that enabled you will need to make sure yours do or else you will likely hit unexpected issues. But as long as your provided DNS servers are working correctly the system is considered supported with or without the fallback DNS.
I do want to note though that this is new territory for us. It’s possible we’ll have to add more checks for DNS server requirements in the future if we see new issues come up with people that have disabled the fallback DNS.
8 Likes
Wanted to give everyone a heads up, supervisor is being updated now. 2022.05.0 is being pushed out to stable which includes the option to disable the fallback DNS. Additionally both SSH addons (the official one and the one in community) have been updated with the latest CLI version that includes support for disabling the fallback. Which means you can ignore all the curl stuff above and just type this:
ha dns options --fallback=false
Although I would recommend running ha resolution info first to make sure that supervisor did not identify any issues with your configured DNS servers. These checks do run on a schedule so if you want to be sure the check ran you can either wait a couple hours or force it to run immediately by doing ha resolution healthcheck.
One minor catch, the DNS plugin also needs an update to acknowledge and support this new option. We’re going to wait about 8 hours from now to merge https://github.com/home-assistant/version/pull/223 so that supervisor has updated everywhere first. Once this second PR goes in and your DNS plugin updates then you’re free to disable the fallback DNS if you want.
8 Likes
I also have the issue that .local adresses can’t be resolved since yesterday (probably ha update).
Running home assistant 2022.04.01 with CoreDns 1.8.4
I have a fritzbox that’s setup to use a seperate RPI with PiHole.
Whenever i want to use for example tv.local in homeAssistant there is no request made to PiHole and it just times out. When i change to tv.de it all works fine.
I openend an issue here:
I tried using ha dns options --fallback=false but it didn’t help
I’m using HA OS and updated to 2022.5.0 this morning as well as Supervisor 2022.05.0. I wasn’t having any issues using local hostnames in the configuration prior to today. I tried going to my backup of 2022.04.07, but still having issues, so I don’t think it is specifically 2022.5.0 that is the issue.
I have an Adguardhome LXC running on the network with DNS Rewrites for all the local hostnames and like I said that has been working fine until today.
I have gone through all the sites I can find for a solution. Even added the DNSMasq add-on to see if HA would work better with that. I checked in ha dns info, both local and servers include the 192. address for the AdGuardHome server. I also set fallback to false. Still could not get configs to work with hostnames, so I installed tcpdump on the HA OS filter on udp port 53 and noticed a couple of things
- if I run
nslookup mosquitto.jnetinc.local, it fails out and tcpdump shows traffic between core-ssh.local.hass.io.39905 > hassio_dns.hassio.53 - if I run
nslookup mosquitto.jnetinc.local 192.168.X.Xusing the AdGuardHome IP, I get the appropriate response and tcpdump shows the traffic between core-ssh.local.hass.io and 192.168.X.X - If I go in to HA Dashboard and configure the MQTT using mosquitto.jnetinc.local as the hostname, it fails to connect, tcpdump doesn’t show any traffic at all, so it’s like it’s not even asking
Am I missing something?
In adguard home did you add a DNS rewrite for mosquitto.jnetinc.local?
Yes, they have been there for a while and I was using the hostname in the MQTT configuration without an issue for several months now. Just stopped working today when I restarted Core as part of the 2022.5.0 update. All configs using local hostnames stopped working. It’s possible to use the IP addresses for some, but that’s messy. And there are a few that use certificates that fail as they are tied to the hostname.
1 Like
Yes so that actually won’t work anymore. People submitted CVE-2020-36517 saying that we were forwarding local domain names inappropriately so we did an audit. One of the things we realized that we were in fact handling .local poorly. This was changed in this PR:
We looked at what systemd-resolved did for handling LLMNR and MDNS names and noticed that it flatly refused to forward these types of queries to resolvers as they are reserved for LLMNR and MDNS, you can see that code here. So now we do this as well.
If you need to use a DNS rewrite for .local then something is not working properly in your network. .local is exclusively for mdns and DNS resolvers are not supposed to answer queries for those. Something either isn’t broadcasting mdns correctly or is handling mdns queries incorrectly.
Or alternatively you can switch to using a domain like .lan or one of the other reserved for local TLDs. But not .local since that is reserved for multicast only.
Using mosquitto.jnetinc.home.arpa and adding that to the DNS Rewrites fixed the issue. Never knew that about .local. Now to start the process of updating my self signed certs and configs…
1 Like
Yea that will work. Sorry about that but it was handled as a security issue. Those warrant breaking changes sometimes. We do need to work on communication of some of these though.
Just as an aside, I have a neat trick for SSL within my LAN. This guide shows how to set up a completely private vaultwarden instance but with publicly trusted (not self-signed) certificates and can be used for almost anything (not really about vaultwarden). Basically you do this:
- Buy a domain
- Transfer that domain to cloudflare (others may work for this, not sure, cloudflare definitely does)
- Create a subdomain and assign it a local IP address
- Use certbot with the DNS challenge to get a Let’s Encrypt certificate for that subdomain
- Use that subdomain as your internal URL everywhere. SSL on your LAN without any warnings, uploading certificates or really any out of the ordinary certificate management.
2 Likes
I will need to look in to this. I’ve just gotten started with certs for internal traffic, nothing external, so self-signed hasn’t been too bad, but I am considering opening somethings to the external world and definitely want real certs for that.
Ah yea. Well when you are dealing with a publicly facing URL that’s usually pretty straightforward. There’s lots of guides for getting a certificate in those cases. Plus the Let’s Encrypt addon makes it really easy.
The tricky bit is if you want SSL for a private URL only accessible within your network. Self-signed certificates work for that they’re just kind of a pain. You have to upload that certificate to every device that wants to connect. And some devices simply don’t have that option so you either have to hope they ignore SSL warnings or you’re screwed.
Normally trusted public CA’s won’t give certificates for private domains but with that guide you can make it happen.
@CentralCommand Hey man, do you have any idea if this change will break sonofflan?
It uses mDNS to receive status updates from sonoff devices, as that’s the only way they respond to any commands.
I mean it shouldn’t? mdns doesn’t involve DNS resolvers. Devices that should respond on mdns names broadcast that on your network and others use that information to resolve queries. It has nothing to do with whatever DNS server you’re using, its a different mechanism entirely.
If you’re worried you can test it though. I use these commands for testing mdns queries on my network:
# Query an mdns name
alias dig-mdns='dig -p 5353 @224.0.0.251'
# Query an LLMNR name
alias dig-llmnr='dig +noedns -p 5355 @224.0.0.252'
# Browse and inspect broadcasted mdns services
alias mdns-browse='dns-sd -B _services._dns-sd._udp.'
alias mdns-query='dns-sd -B' # Type (ex. "_home-assistant")
alias mdns-inspect='dns-sd -L' # Name (ex. "Home") Type (ex. "_home-assistant")
Those ports and ip addresses are not unique to my network, they are standard. Same commands should work on yours.
Cool cheers, I’ve literally just got a pi this week (haven’t set it up yet, using core right now) - will find out when I set it up 
Excuse my ignorance but I don’t get it. No internal name is resolveable anymore since that change. Before everyting was nicely working when I manually removed the fallbck and my DNS servers where just handling it. How can I just have my DNS servers handling my DNS lookups, it can’t be that complicated, other apps/servers/systems can do it too.
Now my ha dns log is full of NXDOMAIN, howerver a nslookup and ping from any other machine works fine.