Improve Privacy, Stop using hardcoded DNS

Feature Requests
70

This is good news.

I captured some metrics (leading to the GH issue above) and found that use of Cloudflare added about 1/2 second of latency on for me (despite CF only being about 15ms away). I’ve been meaning to rewrite the fallback to use UDP to try and prove whether it’s DoT overhead, but got sidetracked on other things.

Having adguard active shouldn’t come into play, no - as Phil says, the underlying problem is that the cloudflare fallback bypasses everything/anything you’ve set up on the LAN.

1 Like
71

Hopefully it’ll gain some traction, but I’m not going to hold my breath.

To be honest, if it doesn’t, then I’ve already got a path in mind.

I have a working PoC for replacing supervisor and coredns images with patched versions without triggering the codeNotary checks (so it won’t mark itself unhealthy/unsupported and block updates) - if push comes to shove that’ll allow me to patch out any bits they’re not willing to fix as and when they arise, and then I can get back to using HA as an appliance rather than a source of frustration :slight_smile:

3 Likes
72

what is so difficult to make this a configurable option? Let the people decide, let people opt out from the DNS TLS Cloudflare lookup if they dont want

2 Likes
73

I replaced the CoreDNS image with custom-made dnsmasq container instead. Works great.

74

This’s getting unacceptable.
My HA runs in a network where all traffic must go through my own DNS server to avoid DNS poisoning, thus any other DNS requests is blocked or redirected.
I wasn’t aware of the situation before this post and it explains A LOT why HA’s been countering some weird network issues.

PLEASE DON’T force people to use embedded DNS, cause google devices do and they’re a such a pain in the ass.

4 Likes
75

Just watch your install doesn’t get marked Unsupported and Unhealthy as a result - it’ll prevent you from installing addon updates.

One of the things Supervisor does is list out running containers and check they’re “approved”. One of the conditions of a supervisor install is

The operating system is dedicated to running Home Assistant Supervised.

(from architecture/adr/0014-home-assistant-supervised.md at 3331ea0255844a46d2830f3d780672b37b5793ff · home-assistant/architecture · GitHub).

It feels like there’s a certain disconnect with reality in all this. I don’t mind not getting support where I’ve done something custom, I do mind not being able to update stuff though.

76

Yes, this caught me when I first tried replacing it without any nuance. Supervisor went nuts trying to replace it but of course, as soon as it stopped the container, it lost name resolution and therein lies madness (and possibly ironically, the reason DNS is so tenaciously configured).

Since then I have prepared my replacement container such that it is no longer rejected by Supervisor, but it does take a little bit of a fandango during upgrades.

77

This is fantastic. I did however have an issue trying to install:

Failed to install add-on

The command ‘/bin/bash -o pipefail -c apk add --no-cache docker’ returned a non-zero code: 1

From system log:
21-11-23 15:05:47 INFO (SyncWorker_6) [supervisor.docker.addon] Starting build for 68e874ae/aarch64-addon-coredns-fix:0.1.1
21-11-23 15:06:01 ERROR (SyncWorker_6) [supervisor.docker.addon] Can’t build 68e874ae/aarch64-addon-coredns-fix:0.1.1: The command ‘/bin/bash -o pipefail -c apk add --no-cache docker’ returned a non-zero code: 1
21-11-23 15:06:01 ERROR (SyncWorker_6) [supervisor.docker.addon] Build log:
Step 1/23 : ARG BUILD_FROM=ghcr.io/hassio-addons/base/amd64:10.0.1
Step 2/23 : FROM ${BUILD_FROM}
—> 77db0d03c09e
Step 3/23 : SHELL ["/bin/bash", “-o”, “pipefail”, “-c”]
—> Using cache
—> 2643c024c7ad
Step 4/23 : ENV TERM=“xterm-256color”
—> Using cache
—> 330311bea649
Step 5/23 : ARG BUILD_ARCH=amd64
—> Using cache
—> cfccee773891
Step 6/23 : RUN apk add --no-cache docker
—> Running in 0c97ca0a26fa
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/aarch64/APKINDEX.tar.gz
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.14/main: temporary error (try again later)

78

I think the Alpine repo’s been having some issues this week - I had an issue building another image the other day.

I should probably push a pre-built image to a registry though, there’s no real need to have to build it each time as we’re not customising anything based on the build host

2 Likes
79

Yeah just tried again and same error - will keep trying until I forget

80

Supervisor log output:

21-11-27 13:38:18 INFO (MainThread) [supervisor.store.git] Cloning add-on https://github.com/bentasker/HomeAssistantAddons/ repository
21-11-27 13:39:06 ERROR (MainThread) [supervisor.store.git] Can't clone https://github.com/bentasker/HomeAssistantAddons/ repository: Cmd('git') failed due to: exit code(128)
  cmdline: git clone -v --recursive --depth=1 --shallow-submodules https://github.com/bentasker/HomeAssistantAddons/ /data/addons/git/68e874ae
  stderr: 'Cloning into '/data/addons/git/68e874ae'...
fatal: unable to access 'https://github.com/bentasker/HomeAssistantAddons/': The requested URL returned error: 504
'.
21-11-27 13:39:06 INFO (MainThread) [supervisor.resolution.module] Create new issue IssueType.FATAL_ERROR - ContextType.STORE / 68e874ae
21-11-27 13:39:06 INFO (MainThread) [supervisor.resolution.module] Create new suggestion SuggestionType.EXECUTE_REMOVE - ContextType.STORE / 68e874ae
21-11-27 13:39:06 ERROR (MainThread) [supervisor.store] Can't load data from repository https://github.com/bentasker/HomeAssistantAddons/

It appears Github has an issue today.

81

Not wanting to flog a dead horse, but I’ve raised yet another issue on GitHub about this, as the behaviour on start-up has changed with the latest version

4 Likes
82

At this point, its better to modify to sources to shut this off.

83

A brave move. Best of luck.

84

This has just happened on mine… I have a DHCP-assigned static IP with a client option set for localised managed DNS, including RPZ for local network protection. At some point in the last couple of days, even though it’s still seeing the local DNS server, it no longer uses it at all…

image

So now none of my RPZ overwrites work, and none of my local DNS resolves. I now have to go through SMTP automations and rewrite them with hardcoded IPs because HA no longer resolves properly.

I’m struggling to come up with a reasonable idea on why someone thought this was a good idea.

image

2 Likes
85

In my old post about this I indicated how I reconfigured ha using

 ha dns option --servers dns://10.33.2.254 --servers dns://80.80.80.80 --servers dns://80.80.81.81

and also by adding a rule to my firewall.

86

Many thanks to @CentralCommand for implementing an option to disable the fallback in version 2022.05.0 of the supervisor. Its been a long road, but we finally got there.

SSH into your HA instance and simply type:

ha dns options --fallback=false

No more fallback…, job done :wink:

17 Likes
87

Yep, that’s it!

My one suggestion for those reading this, please run the following command first:

ha resolution info

I put in some checks which test user-provided DNS servers to ensure they don’t have issues. The check for the situation I described here in particular is not obvious. It’s entirely possible that your local DNS server has this issue and you’ve never noticed since it only affects musl systems.

So please run that command and make sure no dns server issues are in the list. If there are none then feel free to disable the fallback.

If there are then I would strongly advise fixing those first otherwise you may have unexpected issues. Particularly around updating and installing containers since queries for github.com and ghcr.io resolve on A queries but not AAAA. If you do have the ipv6 issue I linked and you disable the fallback anyway you likely will see all your HA containers suddenly start to think github.com and ghcr.io don’t exist and hit a lot of problems.

10 Likes
89

Because this feature request has been implemented, please make new posts for support on this. This FR is formally closed.

4 Likes