HA OS DNS Setting - Configuration not respected?

I am surprised about the network address resolution in HA.

I have an OPNSense firewall that provides its own IP as the DNS server and when examining the DNS configuration using ha dns info, I get:

[core-ssh ~]$ ha dns info
- dns://
servers: []
update_available: false
version: 2021.06.0
version_latest: 2021.06.0

On my firewall, I override some DNS entries to point to the local network address (10.X.X.X) rather than the public (dynamic) network address.

So I want MYPUBLICDOMAIN to resolve to 10.33.2.X (which depends on the subdomain as well).

When I resolve my network address using nslookup MYPUBLICDOMAIN, I get my public address, and when I do nslookup MYPUBLICDOMAIN, I get back.
A ping to MYPUBLICDOMAIN resolves in a ping to the public network address.

The anwser is more or less found in the dns log, which can be read using ha dns log:

[ERROR] plugin/errors: 2 . NS: dial tcp i/o timeout
[INFO] - 61064 "NS IN . udp 17 false 512" NOERROR - 0 30.000761029s
[ERROR] plugin/errors: 2 . NS: dial tcp i/o timeout
[INFO] - 17994 "A IN version.home-assistant.io. udp 43 false 512" NOERROR - 0 4.006484812s

So the local dns service is checking addresses on cloudflare - WTH ?! That’s not what I want - my firewall is acting as a DNS filter as well (it seems that I’ll need to find a way to block those alternative DNS services).

The expected behavior is to use the configuration provided by the DHCP server first. I would also not use a third party service unless getting acceptation from the user. And maybe let him choose between Cloudflare, freenom.world, google, etc.

How to make this work properly?

To point to my local dns service first, I did this:

 ha dns option --servers dns:// --servers dns:// --servers dns://

But IMHO that’s not something that should be required!

[Note: I am also adding a rule to my firewall: HOWTO - Redirect all DNS Requests to Opnsense - nslookup MYPUBLICDOMAIN now shows my local address as well]

1 Like

There is a long thread about this on this forum. Short result: if you don’t like this behavior, don’t use HA OS or HA Supervised, but switch to HA Container or HA Core.

1 Like

Well, were not really informed about it before installing it. AFAIK the general default behavior is to first check the DNS provided by the DHCP service

Anyway, my firewall now fixes it for whatever device tries to bypass the local DNS this way.

TBH, Supervised installing a half-dozen containers (and now requiring an “OS agent”) should be a big warning sign that it does more than it should :wink:

1 Like

I do not know how many hidden containers it installs, but having separate containers is a good thing to isolate services. So it’s not an indicator that it does more than it should for me, but give a positive impression instead.
My reported containers are: “Terminal & SSH”, “Check Home Assistant configuration”, “Mosquitto broker”, “File editor”, “Custom deps deployment”, “SQLite web”, “Grafana” . So that’s half a dozen but I am sure that they are not all there.

My point is: Why does an application like HomeAssistant needs to install a DNS server of it’s own in your/my LAN in the first place…

Look at the one’s starting with Hassio:

@francisp How did you get that list? I’ld love to be able to intervene on the containers (I am running two systems: on on a Pi and another one on a Nuc).

@koying As far as I understand, the DNS server is an Add-on that can be added by choice - as I did not see any use for it, I did not add it.

The description says: “For example, you can have your Home Assistant domain resolve with an internal address inside your network.”.
So yes, that is what I did on my firewall - my publicdomain is resolved to a local IP inside my network.
That addon allows you to add static IPs, etc.

Then of course the DNS server would also require the DHCP server to be installed so that you can tell your clients that they should not use the internet router.

As long as those are choices, that’s fine by me, sending of DNS queries to a party not “dictated” by my setup is another. I know that some information for usage statistics is sent to Nabu Casa in several ways which is pretty much unavoidable if you configure a system for automatic updates.

Base on the list provided by @francisp , I am in favor of this approach and I do not consider it to be excessive - it’s almost not enough because there could be one container per integration - that might help avoid restarting my ZHA every time I make a change to the configuration that requires an HA restart which stops my ZHA for a moment, and puts some of the devices to a temporary sleep - I even have a few that do not recover all the time from such an interruption.

Looks like Portainer

Indeed, Portainer.

Nope. hassio-dns is not optional, and you have it, whether you like it or not, as you noticed, basically.

Sidebar, and I’m interested: what do the firewall rules look like around this?
I mean, blocking local devices from reaching out to is only half of the fight, right?

Now back to the subject - With the levels of control you are looking for, the install method of HAOS might not be for you. Consider either Core or Container methods.

  • Unfortunately, Portainer is discontinued - it would have been nice for monitoring/restarting only.
  • hassio-dns is not optional- Ok, I can’t check because I cant install portainer - while the configuration looks more like a “resolv.conf” than a DNS Server, there is a [full DNS server as far as information goes]
  • @k8gg I provided the HOWTO in my initial post - basically you add a rule to the firewall matching all outbound requests to port 53 and route the to the firewall’s local DNS server. So I did not add a rule to block and specifically, but this reroutes all historical DNS requests (it does not block all DNS request types). There is probably a list out there with all “public” DNS services so that you could block their IPs.
  • Control: I am not looking for full control - there’s stuff I like in HAOS - I do not have to care so much for the host os, etc.

I think you are confusing one of the addons and the actual plugin.
hassio-dns is a full CoreDNS server, and I don’t remember any configuration options on the user side (I stopped using Supervised when a root os-agent was requested above all the stuff that was already installed).

Where did you get that idea ? Portainer has been replaced by Portainer-ce, but they are essentially the same.

The portainer addon is discontinued. They really don’t want you to install anything else…

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 … :rofl:

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 :cry:

Note the message “used for unsupported purposes”…