Ctrl.blog

How to tell if your system is already using systemd-resolved?

Ubuntu 16.04 and later as well as any derivative Linux distributions use systemd-resolved by default. If you’re not sure whether you’re using systemd-resolved or not then we can quickly establish that by running the following command:

systemctl -n0 status systemd-resolved && \
  head -n1 /etc/resolv.conf

The command should return: “# This file is managed by man:systemd-resolved(8). Do not edit.” This means that your system is indeed using systemd-resolved.

If you do want to edit this file, then the configuration example in the bottom of this article will show you how to set the DNS server to something else. You can also read How to take back control of /etc/resolv.conf if you want to configure this file manually.

Improving DNS responsiveness with caching

systemd-resolved caches DNS query responses by default. This means that it can quickly respond to repeated queries for the same domains even when they come from different programs on your system. But is this useful to you on your system?

Before performing the next step, either let your system do its thing for a little while or otherwise use the system as normal for some minutes. Afterward, you can run the following command to determine whether systemd-resolved’s DNS cache is doing you any good:

resolvectl statistics

This will return some statistics that should help prove the worth of systemd-resolved. The cache can store up to 4096 DNS responses for up to 2 hours, so don’t expect to see a massive number listed as the current cache size. You need not be afraid that the cache will bog down your system memory either. A quick calculation shows that the DNS cache can’t grow to more than 420 kB when used to its fullest.

What is more interesting is the next two numbers: cache hits and cache misses. The last number is the number of DNS queries that had to be forwarded to an external recursive DNS server, whereas the first number is the number of queries that were resolved immediately without the need to reach out to an external server. Every cache hit is an instance where systemd-resolved made your system just a little faster.

Your cache hit ratio will vary greatly depending on how you use your system and the software you use. You’re more likely to see a higher cache hit if you use GNOME Web or Chrome and less likely when using Firefox.

Firefox’s has its own internal one–two minutes DNS cache that means its cache will handle a lot of queries that would be handled by systemd-resolved if you’re using a browser with a shorter internal DNS cache (anything built on Chromium) or no internal DNS cache (anything built on WebKit.)

Enhancing DNS privacy and security

DNS queries and responses have traditionally been unencrypted, but more and more resolvers now support DNS over an encrypted TLS connection (DNS over TLS.) TLS can help ensure that no parties between the DNS server and the resolver can see or modify the DNS responses.

This means that someone on the same public network at a café can’t see what you’re doing through your DNS request, and also means that your internet service provider nor your local government can see into your traffic either.

systemd-resolved only supports opportunistic DNS over an encrypted channel. Opportunistic here means that it will reach out and connect over TLS when available, but it won’t verify that it’s connecting to the correct server; make it susceptible to the attacker-in-the-middle interception as described in Actually secure DNS over TLS in Unbound. Attempting to use encryption is still a step up from no encryption at all, however!

You can enable this option (make sure you use a DNS provider that supports DNS over TLS and DNSSEC) by adding the following options to the /etc/systemd/resolved.conf file:

[Resolve]
# Use Quad9.net DNS, and Cloudflare DNS.
# Both supports DNS over TLS and DNSSEC,
# and promises not to log DNS queries.
DNS=2620:fe::fe 9.9.9.9 \
    2606:4700:4700::1111 1.1.1.1
FallbackDNS=2620:fe::9 149.112.112.112 \
            2606:4700:4700::1001 1.0.0.1
# Attempt to use DNS over TLS.
DNSOverTLS=opportunistic
# Enforce DNSSEC validation.
DNSSEC=true

You must restart the systemd-resolved service (the command is systemctl restart systemd-resolved.service) for these options to take effect. You can learn more details about the available configuration options in the resolved.conf manual.

The statistics command, shown above, also output some statistics over the effects of DNSSEC enforcement. DNSSEC helps prevent a potential attacker from modifying your DNS responses, but systemd-resolved doesn’t enforce this by default. The intricacies of DNSSEC is out of scope for this article, however.