| 1 |
# Alloy DNS posture: encrypted where the network offers it, and never at the |
| 2 |
# cost of MagicDNS. |
| 3 |
# |
| 4 |
# The Containerfile has a note beside systemd-resolved saying Alloy leaves it |
| 5 |
# alone. This is the first opinion Alloy has about it. |
| 6 |
# |
| 7 |
# MEASURED 2026-09-08 on fw12, a tailnet-joined Alloy install, which is what |
| 8 |
# GoingsOn alloy `f4806a35` was open for. The measurement moved the reason for |
| 9 |
# this setting without moving the setting, so what follows is what was seen |
| 10 |
# rather than what was expected. |
| 11 |
# |
| 12 |
# MAGICDNS IS NOT THE CONSTRAINT, and an earlier version of this comment said |
| 13 |
# it was. Tailscale does not rely on the global default: it sets DNS over TLS |
| 14 |
# off on its own link through resolved's per-link API, and `resolvectl status` |
| 15 |
# shows `-DNSOverTLS` on tailscale0 while the global reads whatever is set |
| 16 |
# here. Per-link wins, so a global `DNSOverTLS=yes` leaves the 100.100.100.100 |
| 17 |
# stub alone. Under `yes`, `astra` and `fw13` both resolved and a TCP |
| 18 |
# connection to astra:22 opened. Nothing here needs to protect MagicDNS from |
| 19 |
# this file. |
| 20 |
# |
| 21 |
# THE CONSTRAINT IS THE UPLINK. Under `DNSOverTLS=yes` every ordinary name |
| 22 |
# failed: `makenot.work` and `fedoraproject.org` both stopped resolving, |
| 23 |
# because `yes` refuses a server that cannot do DoT and neither uplink can. |
| 24 |
# Port 853 was closed on the LAN router and on the ISP resolver behind it, |
| 25 |
# while 53 answered. A home router that does not speak DoT is the normal case, |
| 26 |
# not this network being unusual, so `yes` shipped as a default is a machine |
| 27 |
# that cannot resolve anything off the tailnet. |
| 28 |
# |
| 29 |
# WHAT `opportunistic` IS WORTH, stated plainly because the setting reads |
| 30 |
# stronger than it is. It uses DoT when the server offers it and falls back |
| 31 |
# when it does not, which an active attacker can downgrade. On the network |
| 32 |
# measured above it buys nothing at all: with 853 closed, every lookup is |
| 33 |
# plaintext, and `resolvectl status` still reports `DNSOverTLS=opportunistic`, |
| 34 |
# because that line is the setting and not evidence of encryption. Read it as |
| 35 |
# a statement of intent that pays off on a network whose resolver offers DoT, |
| 36 |
# and not as a guarantee about any particular one. |
| 37 |
# |
| 38 |
# UPGRADING THIS IS NO LONGER A MEASUREMENT. It now needs a DoT-capable |
| 39 |
# resolver named explicitly for the non-tailnet routes, which is choosing a |
| 40 |
# DNS provider on every user's behalf. That is a policy question of the same |
| 41 |
# shape as the flatpak remote, which Alloy answered by configuring none |
| 42 |
# (GoingsOn alloy `e10e0e40`), so it wants the same kind of ruling rather than |
| 43 |
# a default picked here. |
| 44 |
# |
| 45 |
# DNSSEC=allow-downgrade for a related reason: full `yes` breaks on networks |
| 46 |
# whose resolver mangles or strips DNSSEC records, which includes a lot of |
| 47 |
# hotel and airport DNS, and the failure mode is total rather than degraded. |
| 48 |
[Resolve] |
| 49 |
DNSOverTLS=opportunistic |
| 50 |
DNSSEC=allow-downgrade |
| 51 |
|