Skip to content

Security Tools Release (main)

Choose a tag to compare

feat: choose who answers your DNS, and encrypt the queries

Every site you visit starts with a DNS lookup, and by default that goes to
whoever DHCP nominated — usually the ISP — as plaintext on port 53. HTTPS does
not help: the encryption starts after the name has been resolved. So the ISP,
and anyone watching the connection, sees every domain you ask for.

The generator had a *caching resolver* choice (systemd-resolved / unbound /
dnscrypt-proxy) but neither front end let you pick the upstream. Now there is a
`dns_provider` question offering Quad9, Mullvad, Cloudflare, dns0.eu, AdGuard,
or whatever DHCP hands out, with each provider's addresses and DoT hostname
taken from its own documentation.

Two things this got right only after being checked:

**The certificate hostname is actually pinned now.** The first version wrote
`DNS=9.9.9.9` with `DNSOverTLS=yes` and a comment claiming the hostname was
pinned. It was not — that needs `9.9.9.9#dns.quad9.net`, and without it the
query is encrypted but *not authenticated*, so anyone able to answer on port 853
is trusted. On a hostile network that is the network, which is most of the
threat this is meant to remove. A comment describing protection the config does
not provide is worse than no comment.

**`FallbackDNS=` is set empty on purpose.** systemd's compiled-in fallbacks are
other providers, so leaving the default silently leaks a share of queries to
whoever those are — defeating the point of choosing one.

The option descriptions say what each provider *claims* rather than asserting
it: "states it does not log" is a published policy, not something verifiable
from the machine. Cloudflare carries a note that one very large company seeing a
large share of the internet's DNS is a centralisation trade-off, not a technical
fault. And the guide closes by saying what this does not do — it does nothing
about the IP you then connect to, or about SNI without ECH, so an observer can
often still infer the site. A real improvement over plaintext; not anonymity.

New wiki section `#encrypted-dns` covering the providers, why the `#hostname`
suffix matters, and the same limits, citing the Arch Wiki's systemd-resolved and
Domain name resolution pages as the authority.

Caught by tests/wiki-targets.mjs: the question first pointed at
`wiki:'network-hardening'`, which is a *document* in docs/, not an anchor in
wiki.html — so right-clicking it would have gone nowhere.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>