[SOLVED] DNS Issues with systemd-resolved.service

When encountering DNS issues in Linux systems, particularly with systemd-resolved.service, it’s crucial to recognize the role of certain reserved domain names. These specifications are detailed in RFC 6761, which addresses special-use domain names.

Overview of RFC 6761

RFC 6761 identifies specific domain names as special-use, meaning they have unique behaviors or limitations to ensure proper functionality within various network environments. A prominent example of a special-use domain is .local.

Key Aspects of RFC 6761

• Reserved Names: RFC 6761 outlines domain names reserved for particular purposes, which should not be used as standard domain names. This helps prevent conflicts and ensures consistent behavior across different network configurations.
• .local Domain: The .local domain is intended for link-local addressing within a local network. It is designed for resolving hostnames within the local network segment and is not meant to be globally resolvable via standard DNS servers.
• DNSSEC and .local: DNSSEC (DNS Security Extensions) enforces stringent rules to ensure the authenticity and integrity of DNS data. Since .local is designated for local use only and not for global resolution, DNSSEC frequently flags it as problematic.

Practical Application

Understanding RFC 6761 helps to resolve DNS issues related to systemd-resolved.service, especially domains ending in .local. By configuring your DNS settings to handle .local domains correctly, you can ensure smooth local network resolution without clashing with DNSSEC rules.

Being aware of these special-use domain names and their intended functions helps avoid pitfalls.

For more in-depth information and guidance, consult the full RFC 6761 document.

I recently found a solution while setting up a new laptop for a colleague, which was installed with the latest Linux Mint (19.x,20.x,21.x,22.x) based on Ubuntu.

We encountered an issue with different domains, as some in-house domains ended with .local, which DNSSEC correctly flagged as problematic.

Here is our solution:

First, unlink /etc/resolv.conf or delete, or rename it.

Then link it to the dynamic systemd-resolved.serviceconfiguration.

$ unlink /etc/resolv.conf
$ ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

In the next step, we will disable DNSSEC. Therefore you need to edit your /etc/systemd/resolved.conf to something like that:

$ vim /etc/systemd/resolved.conf#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details[Resolve]
#DNS=
#FallbackDNS=
Domains=domain1.local domain2.local
#LLMNR=no
#MulticastDNS=true
DNSSEC=no
#Cache=yes
DNSStubListener=yes

Lastly, find in /etc/nsswitch.conf the hosts: line which tells the sequence in how your device should resolve.

Find the line and replace it with hosts: files dns . This will resolve your /etc/resolv.conf first and 2nd asking your specified DNS-Server.

$ vim /etc/nsswitch.conf
[...]
#hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
hosts:          files dns
[...]

Cheers!