DNSSEC validation default in systemd‑resolved on Arch Linux: an unresolved decision

Short answer

There is no consensus default, and the shipped DNSSEC=no in /etc/systemd/resolved.conf is unlikely to change soon: Arch follows upstream systemd, and upstream keeps validation off because enabling it by default breaks resolution on enough real-world networks. The practical resolution is to leave the default alone on machines that roam across unknown networks, and opt into validation (DNSSEC=yes or allow-downgrade) only on machines where you control or trust the upstream resolver path.

What is confirmed vs. what is uncertain

Confirmed behavior: with DNSSEC=no, systemd-resolved performs no validation and is fully exposed to spoofing and cache-poisoning between the stub resolver and the upstream server. With DNSSEC=allow-downgrade, resolved attempts validation but falls back to unsigned answers when the upstream path cannot carry DNSSEC, which protects against some attacks but not against an active attacker who can simulate a downgrade. With DNSSEC=yes, unsigned or bogus answers fail hard, which is the only mode that actually delivers DNSSEC's security guarantee.

Uncertain and version-dependent: exact failure rates under allow-downgrade vary by systemd version, upstream resolver, and network middleboxes. Claims of a specific percentage of broken domains should be treated as estimates, not measurements. Some captive portals, ISP resolvers, and corporate middleboxes strip EDNS(0) DNSSEC options, producing SERVFAIL or stalls with little user-visible explanation. Verify on your own workloads before committing.

Measurable compatibility problems

The realistic failure modes under allow-downgrade are: domains behind misconfigured signed zones failing intermittently, resolvers that drop DNSSEC OK (DO) bit queries, and added latency from validation round-trips. To measure impact on your own machine rather than relying on published estimates:

# Check current mode per link
resolvectl status

# Test a known-signed domain; look for the AD flag
dig +dnssec example.com

# Test a deliberately broken domain; expect SERVFAIL under strict mode
dig +dnssec dnssec-failed.org

If dnssec-failed.org resolves, validation is not actually enforced regardless of the config line.

Security posture comparison

DNSSEC=no means any attacker on the path between you and your resolver (or who poisons the resolver's cache) can forge answers; DNSSEC is the specific mitigation for that. However, validation at the stub resolver only protects the last hop if the upstream also validates, and much real-world protection today comes from DoT/DoH to a validating resolver instead. That is why the trade-off is genuinely unresolved: strict local validation gives strong guarantees but breaks on hostile or broken networks, while opportunistic modes give weak guarantees.

Why Arch will not pick a default for you

Arch policy is to ship upstream defaults with minimal patching, so any change would have to happen in systemd itself. Upstream's stated criteria have been resolution reliability across arbitrary networks — a default that breaks DNS for even a small fraction of users is considered worse than an opt-in security feature. Until DNSSEC deployment among zones and middlebox behavior improve measurably, expect no to remain the shipped value.

Recommendation

For a desktop that roams: keep DNSSEC=no and instead use DNS-over-TLS to a validating resolver (DNSOverTLS=yes with a resolver you trust), which protects the path you actually control. For a server on a fixed network: test DNSSEC=allow-downgrade first, monitor for SERVFAIL in journalctl -u systemd-resolved, and only then consider strict mode. Persist any change in a drop-in under /etc/systemd/resolved.conf.d/ rather than editing the shipped file, since package upgrades may replace it.