Why is HomeAssistant reaching out to 1.1.1.1 via DNS over HTTPS

I run split DNS on my network, that way I can access my services internally/externally without any configuration changes or issues. DNS over HTTPS DNS over TLS (DoT) causes problems, since the DNS request doesn’t hit my DNS server.

So I just block all DNS over HTTPS DoT on my network (via pfBlockerng). I was looking through the logs, and I see home assistant (10.254.1.50) reaching out to 1.1.1.1 – I thought this was strange, so I went into the configuration settings and I didn’t see this in the settings anywhere to disable. I have a static IP address, and my own DNS server set.

Just not sure which service attempts to use DNS over HTTPS DoT, or if hass core is the culprit. Any thoughts?

Standalone Rpi4 installation

  • Home Assistant Core 2022.6.6
  • Home Assistant Supervisor 2022.05.3
  • Home Assistant OS 8.2

Add-ons:

  • Google Drive Backup
  • Mosquitto broker
  • Studio Code Server
  • Terminal & SSH
  • Z-Wave JS

Integrations enabled:

  • AndroidTV
  • Supervisor
  • Home
  • Mobile App
  • Mosquitto broker
  • MyQ
  • Google Nest configuration
  • Shopping List
  • Sonos
  • Sun
  • Tasmota
  • UniFi Protect
  • Z-Wave JS

Do you mean DNS over https or DNS over TLS? HA uses cloudflare DoT as a fallback DNS server by default if it fails to get an answer from any of the the configured ones:

But I’m not aware of any usage of cloudflare DoH by HA. I don’t know what that would be coming from.

Afaik only HAOS / supervised does that. See Improve Privacy, Stop using hardcoded DNS

and HA OS DNS Setting - Configuration not respected?

It’s DoT by the way, DoH uses 443

@CentralCommand @Recte @farmio

Ah, yes sorry I was getting the two mixed up. DoT

I guess my next question is, is there a way for me to determine what DNS queries are failing, and resorting to the fallback?

My internal DNS server, utilizes cloudflare for all but my local service names. So I’m a bit perplexed as to why any DNS queries are failing at all

It may not actually be failing. By default HA uses the fallback for SERVFAIL, REFUSED and NXDOMAIN responses. Falling back on REFUSED and NXDOMAIN in particular is (understandably) what people find confusing.

I explained the reason it uses the fallback for these here:

It does actually make sense since most users would prefer to simply not worry about DNS. So the fallback as configured ensures that people don’t hit strange issues around key hostnames like github.com and ghcr.io even if their ISP provided DNS server is misbehaving. And for users that do care and want to exert full control over DNS in their network they can simply disable the fallback with

ha dns options --fallback=false

Although for anyone looking to disable the fallback I strongly recommend running the following command first:

ha resolution info

Just to make sure your DNS server doesn’t have the musl-related issue I mention in that post. If you do it will show up under issues and should be fixed first. Otherwise the fallback can be disabled.