Enabling and Configuring systemd‑resolved on Debian 12 for Local DNS Caching and DNSSEC

Desired Outcome

Activate systemd‑resolved on Debian 12, set up local DNS caching, enable DNSSEC validation, and ensure the system’s /etc/resolv.conf points to the stub listener without conflicts from other resolver services.

Prerequisites

• Debian 12 (Bookworm) installed with systemd 252+.
• Root or sudo privileges to edit system files and control services.
• Optional: NetworkManager installed; if so, it must be configured to use systemd‑resolved or left unchanged.

Focused Procedure

1. Verify systemd‑resolved is available

   systemctl list-unit-files | grep systemd-resolved
   

   Output should contain systemd-resolved.service with enabled or disabled status.

2. Enable and start the service

   sudo systemctl enable --now systemd-resolved
   

   Check the service is active:

   systemctl status systemd-resolved
   

3. Configure DNS servers and DNSSEC in /etc/systemd/resolved.conf

   [Resolve]
   DNS=8.8.8.8 8.8.4.4
   FallbackDNS=1.1.1.1 1.0.0.1
   Cache=yes
   DNSSEC=yes
   DNSSECTrustAnchorFile=/etc/systemd/resolved.dnssec-anchor
   

   Replace the IPs with your preferred upstream resolvers. The DNSSECTrustAnchorFile can be omitted if you rely on the built‑in anchors.

4. Link /etc/resolv.conf to the stub listener

   sudo rm -f /etc/resolv.conf
   sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
   

   This symlink ensures all DNS queries go through systemd‑resolved on 127.0.0.53.

5. Adjust NetworkManager (if present)
   • Open /etc/NetworkManager/NetworkManager.conf and add or modify:

   [main]
   dns=systemd-resolved
   

   • Restart NetworkManager:

   sudo systemctl restart NetworkManager
   

   Alternatively, set dns=none to let systemd‑resolved handle DNS entirely.

6. Reload systemd daemon to apply configuration changes

   sudo systemctl daemon-reload
   sudo systemctl restart systemd-resolved
   

Expected Checks

1. Service status

   systemctl status systemd-resolved
   

   Should show Active: active (running).

2. Verify stub listener

   systemd-resolve --status
   

   Look for DNS Servers: listing the addresses set in resolved.conf and DNSSEC: yes.

3. Test DNS resolution via stub

   dig @127.0.0.53 example.com
   

   The answer section should come from one of the configured upstream servers and include a AD flag if DNSSEC is validated.

4. Check /etc/resolv.conf symlink

   ls -l /etc/resolv.conf
   

   It must point to /run/systemd/resolve/stub-resolv.conf.

Recovery Options

• To disable systemd‑resolved and revert to the default resolver, remove the symlink and restore the original /etc/resolv.conf (e.g., sudo mv /etc/resolv.conf.bak /etc/resolv.conf if you backed it up).
• Disable the service:

  sudo systemctl disable --now systemd-resolved
  

• If NetworkManager was configured to use systemd‑resolved, change dns=none or dns=default and restart.

Limitations and Practical Verification

systemd‑resolved requires systemd 252+, which is present in Debian 12. Older Debian releases use dnsmasq or bind9 by default. If you run multiple resolver services simultaneously, the last one to write to /etc/resolv.conf will win, causing unpredictable behavior. Always keep only one active resolver.

To double‑check that no other resolver is running, list active services:

systemctl list-units --type=service | grep -E 'dns|bind|dnsmasq'

Any matching units should be stopped or disabled before relying on systemd‑resolved.

Concrete Example

Suppose you want to use Google’s public DNS with DNSSEC and a local caching layer. After following the steps above, a quick test:

dig @127.0.0.53 www.google.com

should return an answer with the AD flag set, indicating DNSSEC validation succeeded, and the query should be served from the local cache on subsequent queries.