Taming systemd-resolved: Avoiding DNS Leaks and Surprises on Multi-Homed Linux Systems

Introduction to systemd-resolved

I’ve seen systemd-resolved become a crucial part of many Linux distributions, including Ubuntu, Debian, and Fedora, as of 2026. While it’s designed to provide a flexible and secure way to resolve domain names, its behavior can sometimes lead to unexpected DNS leaks and surprises, especially on multi-homed systems. Don’t bother with trying to disable it, though - it’s usually a better idea to learn how to configure it correctly.

Understanding DNS Leaks

A DNS leak occurs when your system sends DNS queries to an unintended DNS server, potentially revealing your browsing history and other sensitive information. This can happen when your system is configured to use multiple network interfaces, each with its own DNS settings. The real trick is to use a single, unified DNS resolver like systemd-resolved to handle queries from multiple interfaces. I’ve seen this go wrong when people don’t take the time to properly configure their DNS settings.

Configuring systemd-resolved

To avoid DNS leaks and surprises, you need to configure systemd-resolved correctly. This is where people usually get burned - they don’t take the time to edit the /etc/systemd/resolved.conf file. For example, to set the DNS server for a specific interface, you can add the following lines:

[Match]
Name=eth0

[Resolve]
DNS=192.168.1.1

This configuration tells systemd-resolved to use the DNS server at 192.168.1.1 for the eth0 interface. In practice, you’ll probably want to use a combination of DNS servers, so you can add multiple IP addresses to the DNS parameter.

Using Multiple DNS Servers

In some cases, you may need to use multiple DNS servers for different interfaces. systemd-resolved supports this scenario through the DNS parameter in the [Resolve] section. For example:

[Match]
Name=eth0

[Resolve]
DNS=192.168.1.1 8.8.8.8

This configuration tells systemd-resolved to use both the DNS server at 192.168.1.1 and the Google public DNS server at 8.8.8.8 for the eth0 interface. I usually start with a simple configuration like this and then add more complexity as needed.

DNSSEC and DNS Over TLS

To further enhance DNS security, systemd-resolved supports DNSSEC (Domain Name System Security Extensions) and DNS over TLS (DoT). DNSSEC ensures the authenticity and integrity of DNS responses, while DoT encrypts DNS queries and responses. You can enable these features by adding the following lines to the /etc/systemd/resolved.conf file:

[Resolve]
DNSSEC=yes
DNSOverTLS=yes

For more information on DNSSEC and DoT, you can visit the systemd.io website. Don’t skip this step - enabling DNSSEC and DoT can make a big difference in the security of your DNS queries.

Troubleshooting

If you encounter issues with systemd-resolved, you can use the resolvectl command to troubleshoot. For example, to check the current DNS settings, you can run:

resolvectl status

This command displays the current DNS settings, including the DNS servers and search domains. I’ve found this command to be really useful when debugging DNS issues.

Best Practices

To avoid DNS leaks and surprises, follow these best practices:

Use a single, unified DNS resolver like systemd-resolved.
Configure DNS settings for each interface separately.
Use DNSSEC and DNS over TLS to enhance DNS security.
Regularly update your system and DNS resolver to ensure you have the latest security patches.

Additional Resources

For more information on systemd-resolved and DNS security, you can visit the freedesktop.org website. Additionally, the debian.org website provides detailed documentation on configuring and troubleshooting systemd-resolved.