---
type: constraint
title: /etc/hosts alone loses to DNS over HTTPS
tags: [dns, chromium]
---

systemd-resolved is active here and reads `/etc/hosts`, so a hosts entry does
block a domain for anything using the system resolver.

Chromium does not necessarily use it. Secure DNS auto-upgrade sends resolution
to a DoH endpoint over 443, at which point a hosts entry is invisible.
SelfControl's FAQ records the same defeat for Firefox and its workaround is to
restart the browser after the block starts, which is a request rather than a
mechanism.

Hence the firewall half: reject tcp/udp 853 for DoT, and reject 443 to an
enumerated set of known DoH resolvers, which forces resolution back through the
local stub where the hosts entry means something.

The enumerated set is the weak point and is known to be so. It covers
Cloudflare, Google and Quad9. It does not cover a resolver nobody listed, and
it cannot cover a VPN.

The two halves are not independent. Resolving the blocked domains to fill the
firewall half goes through the same `/etc/hosts` the block writes, which
silently empties it from the second apply onward: see
[resolver-reads-the-hosts-file-it-writes](resolver-reads-the-hosts-file-it-writes.md).

`/etc/hosts` also cannot express `*.example.com`. Wildcard subdomains need
dnsmasq (`address=/example.com/0.0.0.0`), which is packaged in Arch `extra`.
Note that `omarchy-dns` already owns `/etc/systemd/resolved.conf` and
NetworkManager's `global-dns`, so a dnsmasq layer has to slot in beside it
rather than rewrite those files.