I did not know that. I still have it installed on my HA instances.
Luckily i installed Portainer as an Add-on ~2 weeks ago. But I noticed with core-2021.11.3 the icon has suddenly changed.
Well, it was used a lot for unsupported porposes … 
The noose tightens for HA supervised users.
I’ve been a bit harsh with the DNS plugin: it basically mimic what docker is doing in bridge mode to resolve docker containers, specifically addons here, in host mode.
I’ve done some tests in a VM, and DNS resolution works fine: it does go to my internal DNS without tweakings.
Cloudlare is only a fallback if the default DNS cannot be reached.
OP, you didn’t tell what kind of installation you have: HassOS on device? HassOS in VM? Supervised?
It was a toys out of the pram moment I think 
Note the message “used for unsupported purposes”…
Have you logged in to Portainer today? Mine won’t accept my credentials.
"Protection Mode is Off. Is there another switch I’m forgetting?
Not that I am aware of. Are you reaching the Login page? Remember that the username and password are not the same as the credentials you are using to Login into your HA instance.
Yes, I’m getting to the login page in Chrome. Mozilla gives me 401: Unauthorized. I created separate credentials when required awhile back. I must have written them down incorrectly. I assume a reinstall isn’t an option anymore.
If it can help, I’ve forked the addon and added it to my addon repo:. No guarantee whatsoever 
1 Like
@koying
The install where I noticed it is running hassOS on an x86 nuc installed from the generic x86 image. I have another setup on a Rasberry Pi, also hassOS, but no external firewall .
It’s strange that its in appearance working differently for you. Clearly, the ‘locals:’ section of the ‘ha dns info’ was clearly indicatingn the local DNS, and with ‘ha dns option’ I just added that to the start of the DNS servers list and then it works.
This is noticed by multiple people including me. Among other posts:
- Improve Privacy, Stop using hardcoded DNS - #30 by rimo
- Hass.IO - Baked-In DNS Client? - #7 by zmodem
- Add-on icons are gone and also add-on store is no longer showing the list of available add-ons - #11 by Recte
This topic was new for me and I found it via: NVD - CVE-2020-36517
I’m curious about what will happen next.
1 Like
Interesting… Vulnarability base score 7.5 HIGH
Do you track CVE notices or was this a hazard to find it ?
I track them using this RSS feed: National Vulnerability Database
Next I filter things that are relevant to me and HA popped up.
1 Like
This DNS issue is still occurring with all current Debian HA versions as of today’s date. Now for the past few months, I was wondering why my HA restarts took nearly 5 minutes on my the old Dell laptop with SSD that takes ~30 seconds to reboot. I also had all outbound DoH (TCP:853) being rejected on my pfSense (not blocked but rejected). I changed that ha dns option --servers dns:xxx and adjusted my firewall rule to block instead of reject. Everything is somewhat better. HA restarts take 35 seconds or so.
When I enabled logging of the reject DoH rule, HA was hitting the firewall ~30 times per second and noticed about 2 Mb/s traffic trying to get to 1.1.1.1 / 1.0.0.1 with rejected. Now that it is set to blocked, it is only a few times per second due to the way that block does not send an ICMP not available response back.
Either way, this all needs to be easily end-user configurable and not hard-coded.
1 Like
I redirect all outgoing DNS traffic to my firewall’s DNS using a NAT rule.
1 Like
That is of no use in case of DoT, cause the certificate fails. It’s only useful for DNS over 53
1 Like
That’s DoT (DNS over TLS → 843), DoH uses 443, that makes it even harder to block.
The only way is to block all DoH you know.
I once found the script below to check if a server is a DoH or just a HTTPS server. The nmap command syntax to check if 1.1.1.1 is DoH (which it is too) is: nmap 1.1.1.1 -p443,53 --script=./Scripts/dns-doh.nse 1.1.1.1 --script-args query=A,target=cnn.com
local nmap = require "nmap"
local shortport = require "shortport"
local http = require "http"
local stdnse = require "stdnse"
local string = require "string"
local table = require "table"
local json = require "json"
local strbuf = require "strbuf"
description = [[
Performs a DOH lookup against the target site
variables: t = <target of dns query>
q = <dns query type>
]]
---
-- @usage
-- nmap <target> --script=doh <DNS server> --script-args query=<query type>,target=<DNS lookup value>
--
-- @output
-- 443/tcp open https
-- | results of query
--
---
author = {"Rob VandenBrink","[email protected]"}
license = "Creative Commons https://creativecommons.org/licenses/by-nc-sa/4.0/"
categories = { "discovery" }
portrule = shortport.http
action = function(host,port)
-- collect the command line arguments
local query = stdnse.get_script_args('query')
local target = stdnse.get_script_args('target')
-- check that both arg values are present and non-zero
if(query==nil or query == '') then
return "DNS query operation is not defined (A,AAAA,MX,PTR,TXT etc)"
end
if(target==nil or target=='') then
return "DNS target is not defined (host, domain, IP address etc)"
end
-- construct the query string, the path in the DOH HTTPS GET
local qstring = '/dns-query?name='..target..'&type='..query
-- define the header value (which defines the output type)
local options = {header={}}
options['header']['accept'] = 'application/dns-json'
-- Get some DOH answers!
local response = http.get(host.ip, port.number, qstring, options)
-- convert results to JSON for more legible output
local stat, resp =json.parse(response.body)
return resp
end
FYI you can disable the fallback DNS by entering the following in the cli:
ha dns options --fallback=false
Also less is potentially leaked out of the box after
Now supervisor does as systemd-resolved does and no longer sends LLMNR or MDNS queries to resolvers at all even if the fallback is enabled.
My general advice to anyone before disabling the fallback is to run the following command first:
ha resolution info
If you see no issues, feel free to disable it. If you see issues related to DNS then that means HA has issues working with your DNS server and you should fix those first.
And yes it is possible for HA to have an issue with a DNS server even though literally every other device on your network does not because of this:
If you have that musl related issue them it’ll show up as an issue when you enter that command. If not then feel free to disable the fallback.
5 Likes
Hey all,
I have a very strange issue. ha dns info says that my dns server is X. But its not, unless my old windows DNS server is running. Nothing will resolve. Or most importantly my ethernet ZHA coordinator
What am I missing?