Furkan İkkan Türkçe
Back to posts
Post

· Network & System Administrator

Configuring DNS-over-TLS and DNSSEC with systemd-resolved: Setup and Troubleshooting

Learn how to enable DoT and DNSSEC in systemd-resolved, verify with resolvedctl and journalctl, and fix common validation failures.

Sistemsystemd-resolvedDNS-over-TLSDNSSECresolvedctl

I’ve been running systemd-resolved as the local stub resolver on my Ubuntu servers for a while now. It handles DNS-over-TLS (DoT) and DNSSEC validation out of the box, which makes it a clean alternative to running unbound or dnsmasq locally. Recently I had to troubleshoot a validation failure on a new DNSSEC-signed zone, and the combination of resolvedctl and journalctl gave me exactly what I needed. Here’s how I configure and validate DoT and DNSSEC with systemd-resolved in my environment.

Enabling DNS-over-TLS and DNSSEC in resolved.conf

The main config file is /etc/systemd/resolved.conf. I set DNSOverTLS to opportunistic mode so it tries TLS but falls back to plain UDP if the upstream doesn’t support it. For DNSSEC, I enable validation and require DNSSEC for trusted domains. Here’s my typical configuration:

[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=9.9.9.9 149.112.112.112
DNSOverTLS=opportunistic
DNSSEC=allow-downgrade
DNSSEC=true

After editing, I restart the service: sudo systemctl restart systemd-resolved. Opportunistic mode is safe for most networks — if the upstream doesn’t support TLS, it won’t break resolution. But if you want strict enforcement, use DNSOverTLS=yes and make sure your upstreams actually support port 853.

Verifying TLS and DNSSEC Status with resolvedctl

Once resolved is running, I use resolvedctl status to check if TLS is active and DNSSEC is validating. This command shows the current DNS servers, protocol used, and validation state:

$ resolvedctl status
Global
       DNS Servers: 1.1.1.1#cloudflare-dns.com 8.8.8.8#google-dns.com
    DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa ...

Look for the line that says DNS Over TLS: YES or DNS Over TLS: opportunistic (yes) under each server. If it says no, TLS isn’t being used. For DNSSEC, the output shows whether validation is active and if any NTAs (Negative Trust Anchors) are in place. NTAs are used to disable validation for zones that are broken or not fully signed — common during rollouts.

Checking Logs with journalctl for Validation Failures

When DNSSEC validation fails, systemd-resolved logs the reason to the journal. I use journalctl -u systemd-resolved -f to follow logs in real time while testing with dig or host. A common failure looks like this:

systemd-resolved[1234]: Using feature UDP fallback for DNS server 9.9.9.9
systemd-resolved[1234]: DNSSEC validation failed: data does not validate

The first line means TLS wasn’t available or was dropped — useful if you’re expecting strict TLS. The second line indicates a DNSSEC problem: missing signature, expired key, or clock skew. I’ve seen this happen when a zone’s KSK was rolled but the DS record at the parent wasn’t updated yet.

To dig deeper, I query the AD (Authenticated Data) flag with dig +dnssec example.com @127.0.0.53. If the AD flag is not set, validation failed. If it is set, resolved believes the data is authentic.

Troubleshooting Common Issues

Here’s what I check when DoT or DNSSEC isn’t working as expected:

  • TCP/UDP 853 blocked: Use ss -tuln | grep 853 or nmap -p 853 <resolver-ip> to confirm the port is open. Some ISPs or cloud firewalls block it.
  • Clock skew: DNSSEC relies on valid timestamps. If the system clock is off by more than a few minutes, validation will fail. Check with timedatectl status.
  • Broken trust chain: Use dig +trace +dnssec example.com to see where the chain breaks. Often it’s a missing DS record or incorrect key tag.
  • StubResolver not updating: After changing resolved.conf, I sometimes need to sudo systemctl restart systemd-resolved and then resolvectl flush-caches to clear old state.

When to Use systemd-resolved vs a Full Resolver

I stick with systemd-resolved on desktops, laptops, and lightweight servers because it’s simple, integrated, and does what I need: encrypted DNS and basic validation. For recursive caching, DNS firewalling, or advanced logging, I still run unbound or AdGuard Home. But as a stub resolver with DoT and DNSSEC? It’s reliable and low-maintenance.

As I mentioned before in my post about systemd timers (https://furkanikkan.com/urun/systemd-zamanlayicilariyla-alt-dakikada-calisan-gorevler-accuracysec-ve-onunitactivesec-125), the journal is your first stop for debugging — and with resolved, that’s especially true for DNS validation.

Cover image: USDAgov · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/41284017@N08/52288971213