Clarifying four modes of handling /etc/resolv.conf in systemd-resolved

systemdsystemd-resolved

I have read about systemd-resolved.service https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html and learnt four modes of handling /etc/resolv.conf.

/run/systemd/resolve/stub-resolv.conf
/usr/lib/systemd/resolv.conf
/run/systemd/resolve/resolv.conf
/etc/resolv.conf may be managed by other package

I have read it for several times, but still feel confused about how to determine which mode of /etc/resolv.conf I should choose as a normal user.

For example, I try to add some custom dns servers, so,

Add DNS=8.8.8.8 8.8.4.4 in /etc/systemd/resolved.conf and check /run/systemd/resolve/resolv.conf, 8.8.8.8 and 8.8.4.4 exist in it.

If symlinking /run/systemd/resolve/resolv.conf to /etc/resolv.conf, 8.8.8.8 and 8.8.4.4 are gone in
/run/systemd/resolve/resolv.conf.

Update 1:

test@instance-1:~$ cat /run/systemd/resolve/resolv.conf 
...
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 8.8.8.8
nameserver 8.8.4.4

test@instance-1:/etc$ sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf 
test@instance-1:/etc$ ls -alh /etc/resolv.conf 
lrwxrwxrwx 1 root root 32 Mar 18 07:22 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
test@instance-1:/etc$ sudo reboot

test@instance-1:~$ cat /etc/resolv.conf 
domain c.prime-poetry-197705.internal
search c.prime-poetry-197705.internal. google.internal.
nameserver 169.254.169.254

test@instance-1:~$ cat /run/systemd/resolve/resolv.conf 
domain c.prime-poetry-197705.internal
search c.prime-poetry-197705.internal. google.internal.
nameserver 169.254.169.254

test@instance-1:~$ ls -alh /etc/resolv.conf 
lrwxrwxrwx 1 root root 32 Mar 18 07:22 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

Update 2:
symlinking from /etc/resolv.conf

test@instance-1:~$ sudo ln -sf /etc/resolv.conf /run/systemd/resolve/resolv.conf 
test@instance-1:~$ ls -alh /run/systemd/resolve/resolv.conf 
lrwxrwxrwx 1 root root 16 Mar 18 07:51 /run/systemd/resolve/resolv.conf -> /etc/resolv.conf
test@instance-1:~$ sudo reboot

test@instance-1:~$ ls -alh /run/systemd/resolve/resolv.conf 
-rw-r--r-- 1 systemd-resolve systemd-resolve 603 Mar 18 07:52 /run/systemd/resolve/resolv.conf

Best Answer

My guess is that you are getting your IP configuration from DHCP, which overrides the DNS information in your resolved.conf file (from systemd.network(5)):

[DHCP] SECTION OPTIONS

[...]

UseDNS= When true (the default), the DNS servers received from the DHCP server will be used and take precedence over any statically configured ones.

This corresponds to the nameserver option in resolv.conf(5).

Try adding the following to your {networkname}.network file (in /etc/systemd/network):

[DHCP]
UseDNS=false

Related Solutions

Systemd-resolved block a domain name

Adding an entry to /etc/hosts is supposed to work and in my tests it worked as expected. My tests are on Fedora Rawhide, with version systemd-239-9.git9f3aed1.fc30.x86_64, so that's a pretty recent snapshot of systemd, maybe older versions will not work the same as expected...

Before adding the entry to /etc/hosts:

1) resolvectl query:

$ resolvectl query google.com
google.com: 172.217.6.78

-- Information acquired via protocol DNS in 1.4ms.
-- Data is authenticated: no

2) ping:

$ ping -c1 google.com
PING google.com (172.217.6.78) 56(84) bytes of data.
64 bytes from sfo07s17-in-f78.1e100.net (172.217.6.78): icmp_seq=1 ttl=54 time=12.4 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 12.435/12.435/12.435/0.000 ms

3) curl:

$ curl http://google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

After adding the entry, in which case /etc/hosts looks like this:

$ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

127.0.0.1 google.com
::1 google.com

Tests showed the blocking is working:

1) resolvectl query:

$ resolvectl query google.com
google.com: 127.0.0.1
            ::1

-- Information acquired via protocol DNS in 1.8ms.
-- Data is authenticated: yes

2) ping:

$ ping -c1 google.com
PING google.com(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.613 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.613/0.613/0.613/0.000 ms

3) curl:

$ curl http://google.com
curl: (7) Failed to connect to google.com port 80: Connection refused

So the block seems to be working.

I expected this would work, since this was brought up recently in an issue filed against systemd. Issue #9718 talked about adding millions of entries to /etc/hosts, which has one usecase and that's blacklisting domains, such as here.

Please note that there are quite a few moving parts here, so it's important to consider those while troubleshooting this.

My /etc/systemd/resolved.conf has no overridden configuration, all entries are commented out, network setup is using systemd-networkd with DHCP and no overrides either.

Output of resolvectl status includes:

Global
       LLMNR setting: yes
MulticastDNS setting: yes
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: no
Fallback DNS Servers: 8.8.8.8
                      8.8.4.4
                      2001:4860:4860::8888
                      2001:4860:4860::8844

Link 2 (ens33)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
  DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
    DNSSEC supported: no

Configuration of /etc/resolv.conf is using the stub resolver:

$ ls -l /etc/resolv.conf
lrwxrwxrwx. 1 root root 39 Nov  7 22:08 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
$ grep '^[^#]' /etc/resolv.conf
nameserver 127.0.0.53

And nsswitch.conf is configured to use nss-resolve(8) according to the recommendation from its man page:

$ grep ^hosts: /etc/nsswitch.conf
hosts:      files resolve [!UNAVAIL=return] dns myhostname

If you still can't make it work, you might want to check these settings in your system and confirm they are all configured correctly. Or, at least, post your current configuration here (together with Linux distro and systemd version) to help diagnose why it might not be working for you.

What’s the difference between /run/systemd/resolve/stub-resolv.conf and /run/systemd/resolve/resolv.conf

Using resolv.conf instead of stub-resolv.conf will bypass a lot of systemd-resolved configuration, such as DNS answer caching, per-interface DNS configuration, DNSSec enforcement, etc.

Explanations:

When using stub-resolv.conf, applications will make DNS requests to the DNS stub resolver provided by systemd on address 127.0.0.53. This stub resolver will proxy the DNS requests to the upstream DNS resolvers configured in systemd-resolved, applying whatever logic it wants to those requests and answers, like caching them.

When using resolv.conf, applications will directly make DNS requests to the "real" (aka. upstream) DNS resolvers configured in systemd-resolved. In this case, systemd-resolved only acts as a "resolv.conf manager", not as a DNS resolver itself.

Source: systemd-resolved manpage

Clarifying four modes of handling /etc/resolv.conf in systemd-resolved

Best Answer

`[DHCP]` SECTION OPTIONS

Related Question

Best Answer

[DHCP] SECTION OPTIONS

Related Solutions

Systemd-resolved block a domain name

What’s the difference between /run/systemd/resolve/stub-resolv.conf and /run/systemd/resolve/resolv.conf

Related Question

`[DHCP]` SECTION OPTIONS