Troubleshooting DNS Resolution Issues in My Homelab with Unbound and systemd-resolved

Introduction to DNS Resolution Issues

I’ve been running my own homelab for years, and like many of you, I’ve had my fair share of DNS resolution issues. Last year, I decided to ditch my router as a DNS server and set up Unbound and systemd-resolved on my Linux machines instead. The goal was to improve DNS resolution speed and security, but as you can probably guess, it wasn’t all smooth sailing.

Understanding Unbound and systemd-resolved

Unbound is a great tool - it’s a validating, recursive, and caching DNS resolver that can be used as a local DNS server. It’s known for its high performance, security features, and flexibility. systemd-resolved, on the other hand, is part of the systemd suite and provides a system-wide DNS resolver service. I’ve found that using them together provides a robust DNS resolution system. To get started, I checked out the instructions on the systemd.io website, which were really helpful.

Troubleshooting DNS Resolution Issues

When things started going wrong, I used the resolvectl status command to check the DNS resolution status:

resolvectl status

This command gives you a quick overview of your DNS resolution configuration, including the upstream DNS servers and the DNSSEC validation status. I also used the dig command to perform DNS lookups:

dig example.com

This command shows you the DNS response for a given domain, which can be really useful for troubleshooting. And if you’re running Unbound, the unbound-control command is also super useful:

unbound-control stats

This command displays statistics about the Unbound DNS server, including the number of queries, responses, and errors.

Configuring Unbound and systemd-resolved

To get Unbound up and running, I edited the /etc/unbound/unbound.conf file and added the following lines:

server:
    interface: 127.0.0.1
    port: 53
    do-ip4: yes
    do-ip6: yes
    do-udp: yes
    do-tcp: yes

This tells Unbound to listen on the local IP address 127.0.0.1 and port 53, and to enable IPv4 and IPv6 support. For systemd-resolved, I edited the /etc/systemd/resolved.conf file and added the following lines:

[Resolve]
DNS=127.0.0.1

This tells systemd-resolved to use the local Unbound DNS server as its upstream DNS server.

Security Considerations

Security is a top priority when running a local DNS server. Unbound has built-in support for DNSSEC, which helps prevent DNS spoofing attacks. To enable DNSSEC, I added the following line to the /etc/unbound/unbound.conf file:

server:
    ...
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

This tells Unbound to use the root.key file as its trust anchor for DNSSEC validation. Don’t bother with DNSSEC if you’re not planning to run a local DNS server, but if you are, it’s definitely worth the extra configuration.

Practical Trade-Offs

Running a local DNS server isn’t without its trade-offs. One of the main downsides is the increased complexity of the system. You’ll need to configure and maintain the DNS server, which can be a pain. Another trade-off is the potential for increased latency - if the local DNS server is not properly configured or is experiencing issues, it can introduce latency into the system. However, for me, the benefits of running a local DNS server - including improved security and performance - outweigh the trade-offs.

Real-World Usage

In my homelab, I’ve found that running Unbound and systemd-resolved provides a robust and secure DNS resolution system. I’ve experienced fewer DNS resolution issues, and my overall system performance has improved. To keep an eye on things, I use the unbound-control command to check the Unbound statistics, and the resolvectl command to check the systemd-resolved status. If you’re interested in learning more, I recommend checking out the Unbound documentation and the systemd documentation.