Enhancing DNS Privacy on Linux with systemd-resolved
Secure your Linux DNS queries with systemd-resolved's DNS-over-TLS and DNSSEC features for ultimate privacy protection.
The Domain Name System (DNS) serves as the internet’s directory service, translating human-readable domain names into IP addresses. However, traditional DNS operates over unencrypted UDP/TCP port 53, exposing queries to eavesdropping, manipulation, and censorship. Modern Linux distributions address these vulnerabilities through systemd-resolved, a local DNS stub resolver that supports DNS-over-TLS (DoT) and DNSSEC validation.
This comprehensive guide explores configuring systemd-resolved for maximum privacy and security. We’ll cover its architecture, step-by-step DoT setup, DNSSEC integration, troubleshooting common issues, and best practices for production environments. Whether you’re securing a desktop, server, or containerized workload, these techniques will harden your DNS infrastructure against surveillance and attacks.
Understanding systemd-resolved Architecture
Introduced in systemd version 230 (2016), systemd-resolved provides a unified DNS resolution service for Linux systems. Unlike traditional /etc/resolv.conf management, it acts as a caching stub resolver listening on 127.0.0.53:53, forwarding queries to upstream servers while implementing advanced features:
- Local caching: Reduces latency and upstream traffic
- Split DNS: Per-interface resolution policies
- Multiprotocol support: DoT, DoH (experimental), mDNS, LLMNR
- DNSSEC validation: Cryptographic verification of responses
- Privacy-focused transports: Encrypted channels preventing ISP surveillance
Most major distributions ship systemd-resolved enabled by default:
| Distribution | Default Status | Version Support |
|---|---|---|
| Ubuntu 18.04+ | Enabled | DoT since 242 |
| Fedora 33+ | Enabled | Full DoT/DNSSEC |
| Debian 11+ | Optional | DoT since 246 |
| Arch Linux | Enabled | Latest features |
The service intercepts all DNS queries system-wide, ensuring consistent policy enforcement regardless of application or network interface.
Why DNS Privacy Matters in 2026
ISP surveillance remains pervasive. According to EFF research, 85% of residential connections expose DNS queries to providers. Corporate networks often log queries for compliance, while nation-state actors exploit DNS for censorship and surveillance.
DNS-over-TLS addresses these threats by:
- Encrypting the entire query/response exchange
- Authenticating server identity via TLS certificates
- Preventing query injection and tampering
- Eliminating domain surveillance
Combined with DNSSEC, it provides end-to-end integrity verification, rejecting forged responses even if encryption fails.
Step-by-Step DNS-over-TLS Configuration
1. Verify systemd-resolved Status
systemctl status systemd-resolvedsudo ss -tulpn | grep :53Ensure the service runs and binds to 127.0.0.53:53. If disabled:
sudo systemctl enable --now systemd-resolvedsudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf2. Select Privacy-Focused Upstream Servers
Choose resolvers supporting DoT with strong privacy policies:
| Provider | IPv4 DoT | IPv6 DoT | Privacy Policy |
|---|---|---|---|
| Cloudflare | 1.1.1.1 | 2606:4700:4700::1111 | Zero logging |
| Quad9 | 9.9.9.9 | 2620:fe::fe | Malware blocking |
| Mullvad | 194.58.192.32 | 2a07:bc80::32 | No-logs VPN |
3. Configure /etc/systemd/resolved.conf
Create a drop-in configuration:
sudo mkdir -p /etc/systemd/resolved.conf.dsudo tee /etc/systemd/resolved.conf.d/privacy.conf <Key directives explained:
DNSOverTLS=yes: Strict mode (fails closed on DoT failure)Domains=~.: Route all queries through configured serversDNSSEC=yes: Enable strict validationFallbackDNS: Secondary servers (used only on primary failure)
4. Apply and Test Configuration
sudo systemctl restart systemd-resolvedresolvectl statusVerify DoT usage with packet capture:
sudo tcpdump -i any port 853Expected output shows TLS handshakes to port 853, no port 53 traffic.
Enabling DNSSEC Validation
DNSSEC cryptographically signs DNS records, preventing spoofing and cache poisoning. systemd-resolved supports strict validation since version 239.
Configuration
Add to /etc/systemd/resolved.conf.d/security.conf:
[Resolve]DNSSEC=yesDNSSECNegativeTrustAnchors=.Monitor validation statistics:
resolvectl statisticsLook for DNSSEC supported: yes and low DNSSEC validation failures.
Troubleshooting Common Issues
| Issue | Symptom | Solution |
|---|---|---|
| No DoT traffic | Queries on port 53 | Check Domains=~. setting |
| DNSSEC failures | resolvectl SERVFAIL | Verify upstream supports DNSSEC |
| NetworkManager conflict | Inconsistent /etc/resolv.conf | sudo systemctl disable --now systemd-resolved then re-enable |
| IPv6 resolution fails | Slow fallback | Add IPv6 DoT endpoints |
Advanced: Split DNS and Container Integration
systemd-resolved excels at per-interface policies. Configure VPN-specific resolvers:
resolvectl dns vpn0 10.0.0.1resolvectl domain vpn0 ~private.example.comFor containers, expose the stub resolver:
docker run --dns=127.0.0.53 --network=host alpine nslookup example.comPerformance Optimization
- Cache tuning:
Cache=yes,CacheFromLocalhost=no - Disable unused protocols:
MulticastDNS=no LLMNR=no - EDNS buffer size:
DNSSEC=allow-downgrade(testing only)
Security Hardening Checklist
- ☐ Enable strict
DNSOverTLS=yes - ☐ Configure
DNSSEC=yes - ☐ Set
Domains=~.for global routing - ☐ Use multiple upstreams with fallbacks
- ☐ Monitor
journalctl -u systemd-resolved - ☐ Verify no port 53 leaks via
tcpdump - ☐ Test with
drill @127.0.0.53 example.com +tls
FAQ
Does DNS-over-TLS slow down resolution?
Initial TLS handshake adds ~50ms latency, but caching eliminates this for repeat queries. Real-world impact: <5% degradation.
What if my upstream doesn’t support DoT?
Use DNSOverTLS=opportunistic for fallback, but prefer strict mode with privacy-focused providers.
Is systemd-resolved safe for servers?
Yes, with proper configuration. Disable multicast protocols and monitor logs. Production deployments power major cloud providers.
Can I use DNS-over-HTTPS instead?
Experimental support exists via dnscrypt-proxy or stubby, but native DoT remains most reliable.
Future Directions
systemd 256+ introduces Encrypted Client Hello (ECH) support and DoH 1.1. Distribution vendors increasingly default to privacy resolvers, with Fedora Workstation 41 shipping Quad9 DoT out-of-box.
References
- Cloudflare DNS Resolver Documentation — Cloudflare. 2025-03-15. https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-tls/
- systemd-resolved Man Page — systemd project (freedesktop.org). 2026-04-01. https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
- DNS Privacy Considerations — IETF RFC 7816. 2016-05-01 (authoritative standard). https://datatracker.ietf.org/doc/html/rfc7816
- Quad9 DNS Security Features — Quad9. 2025-11-20. https://www.quad9.net/service/service-addresses-v4-v6-ipv6-only/
- Fedora systemd-resolved Configuration — Fedora Project Documentation. 2025-08-10. https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/networking/Configuring_the_network/#sect-Configuring_the_network-DNS_resolution
Similar Articles
Read full bio of medha deb
