1RESOLVED.CONF(5)                 resolved.conf                RESOLVED.CONF(5)
2
3
4

NAME

6       resolved.conf, resolved.conf.d - Network Name Resolution configuration
7       files
8

SYNOPSIS

10       /etc/systemd/resolved.conf
11
12       /etc/systemd/resolved.conf.d/*.conf
13
14       /run/systemd/resolved.conf.d/*.conf
15
16       /usr/lib/systemd/resolved.conf.d/*.conf
17

DESCRIPTION

19       These configuration files control local DNS and LLMNR name resolution.
20

CONFIGURATION DIRECTORIES AND PRECEDENCE

22       The default configuration is defined during compilation, so a
23       configuration file is only needed when it is necessary to deviate from
24       those defaults. By default, the configuration file in /etc/systemd/
25       contains commented out entries showing the defaults as a guide to the
26       administrator. This file can be edited to create local overrides.
27
28       When packages need to customize the configuration, they can install
29       configuration snippets in /usr/lib/systemd/*.conf.d/ or
30       /usr/local/lib/systemd/*.conf.d/. Files in /etc/ are reserved for the
31       local administrator, who may use this logic to override the
32       configuration files installed by vendor packages. The main
33       configuration file is read before any of the configuration directories,
34       and has the lowest precedence; entries in a file in any configuration
35       directory override entries in the single configuration file. Files in
36       the *.conf.d/ configuration subdirectories are sorted by their filename
37       in lexicographic order, regardless of which of the subdirectories they
38       reside in. When multiple files specify the same option, for options
39       which accept just a single value, the entry in the file with the
40       lexicographically latest name takes precedence. For options which
41       accept a list of values, entries are collected as they occur in files
42       sorted lexicographically. It is recommended to prefix all filenames in
43       those subdirectories with a two-digit number and a dash, to simplify
44       the ordering of the files.
45
46       To disable a configuration file supplied by the vendor, the recommended
47       way is to place a symlink to /dev/null in the configuration directory
48       in /etc/, with the same filename as the vendor configuration file.
49

OPTIONS

51       The following options are available in the "[Resolve]" section:
52
53       DNS=
54           A space-separated list of IPv4 and IPv6 addresses to use as system
55           DNS servers. DNS requests are sent to one of the listed DNS servers
56           in parallel to suitable per-link DNS servers acquired from systemd-
57           networkd.service(8) or set at runtime by external applications. For
58           compatibility reasons, if this setting is not specified, the DNS
59           servers listed in /etc/resolv.conf are used instead, if that file
60           exists and any servers are configured in it. This setting defaults
61           to the empty list.
62
63       FallbackDNS=
64           A space-separated list of IPv4 and IPv6 addresses to use as the
65           fallback DNS servers. Any per-link DNS servers obtained from
66           systemd-networkd.service(8) take precedence over this setting, as
67           do any servers set via DNS= above or /etc/resolv.conf. This setting
68           is hence only used if no other DNS server information is known. If
69           this option is not given, a compiled-in list of DNS servers is used
70           instead.
71
72       Domains=
73           A space-separated list of domains. These domains are used as search
74           suffixes when resolving single-label host names (domain names which
75           contain no dot), in order to qualify them into fully-qualified
76           domain names (FQDNs). Search domains are strictly processed in the
77           order they are specified, until the name with the suffix appended
78           is found. For compatibility reasons, if this setting is not
79           specified, the search domains listed in /etc/resolv.conf are used
80           instead, if that file exists and any domains are configured in it.
81           This setting defaults to the empty list.
82
83           Specified domain names may optionally be prefixed with "~". In this
84           case they do not define a search path, but preferably direct DNS
85           queries for the indicated domains to the DNS servers configured
86           with the system DNS= setting (see above), in case additional,
87           suitable per-link DNS servers are known. If no per-link DNS servers
88           are known using the "~" syntax has no effect. Use the construct
89           "~."  (which is composed of "~" to indicate a routing domain and
90           "."  to indicate the DNS root domain that is the implied suffix of
91           all DNS domains) to use the system DNS server defined with DNS=
92           preferably for all domains.
93
94       LLMNR=
95           Takes a boolean argument or "resolve". Controls Link-Local
96           Multicast Name Resolution support (RFC 4795[1]) on the local host.
97           If true, enables full LLMNR responder and resolver support. If
98           false, disables both. If set to "resolve", only resolution support
99           is enabled, but responding is disabled. Note that systemd-
100           networkd.service(8) also maintains per-link LLMNR settings. LLMNR
101           will be enabled on a link only if the per-link and the global
102           setting is on.
103
104       MulticastDNS=
105           Takes a boolean argument or "resolve". Controls Multicast DNS
106           support (RFC 6762[2]) on the local host. If true, enables full
107           Multicast DNS responder and resolver support. If false, disables
108           both. If set to "resolve", only resolution support is enabled, but
109           responding is disabled. Note that systemd-networkd.service(8) also
110           maintains per-link Multicast DNS settings. Multicast DNS will be
111           enabled on a link only if the per-link and the global setting is
112           on.
113
114       DNSSEC=
115           Takes a boolean argument or "allow-downgrade". If true all DNS
116           lookups are DNSSEC-validated locally (excluding LLMNR and Multicast
117           DNS). If the response to a lookup request is detected to be invalid
118           a lookup failure is returned to applications. Note that this mode
119           requires a DNS server that supports DNSSEC. If the DNS server does
120           not properly support DNSSEC all validations will fail. If set to
121           "allow-downgrade" DNSSEC validation is attempted, but if the server
122           does not support DNSSEC properly, DNSSEC mode is automatically
123           disabled. Note that this mode makes DNSSEC validation vulnerable to
124           "downgrade" attacks, where an attacker might be able to trigger a
125           downgrade to non-DNSSEC mode by synthesizing a DNS response that
126           suggests DNSSEC was not supported. If set to false, DNS lookups are
127           not DNSSEC validated.
128
129           Note that DNSSEC validation requires retrieval of additional DNS
130           data, and thus results in a small DNS look-up time penalty.
131
132           DNSSEC requires knowledge of "trust anchors" to prove data
133           integrity. The trust anchor for the Internet root domain is built
134           into the resolver, additional trust anchors may be defined with
135           dnssec-trust-anchors.d(5). Trust anchors may change at regular
136           intervals, and old trust anchors may be revoked. In such a case
137           DNSSEC validation is not possible until new trust anchors are
138           configured locally or the resolver software package is updated with
139           the new root trust anchor. In effect, when the built-in trust
140           anchor is revoked and DNSSEC= is true, all further lookups will
141           fail, as it cannot be proved anymore whether lookups are correctly
142           signed, or validly unsigned. If DNSSEC= is set to "allow-downgrade"
143           the resolver will automatically turn off DNSSEC validation in such
144           a case.
145
146           Client programs looking up DNS data will be informed whether
147           lookups could be verified using DNSSEC, or whether the returned
148           data could not be verified (either because the data was found
149           unsigned in the DNS, or the DNS server did not support DNSSEC or no
150           appropriate trust anchors were known). In the latter case it is
151           assumed that client programs employ a secondary scheme to validate
152           the returned DNS data, should this be required.
153
154           It is recommended to set DNSSEC= to true on systems where it is
155           known that the DNS server supports DNSSEC correctly, and where
156           software or trust anchor updates happen regularly. On other systems
157           it is recommended to set DNSSEC= to "allow-downgrade".
158
159           In addition to this global DNSSEC setting systemd-
160           networkd.service(8) also maintains per-link DNSSEC settings. For
161           system DNS servers (see above), only the global DNSSEC setting is
162           in effect. For per-link DNS servers the per-link setting is in
163           effect, unless it is unset in which case the global setting is used
164           instead.
165
166           Site-private DNS zones generally conflict with DNSSEC operation,
167           unless a negative (if the private zone is not signed) or positive
168           (if the private zone is signed) trust anchor is configured for
169           them. If "allow-downgrade" mode is selected, it is attempted to
170           detect site-private DNS zones using top-level domains (TLDs) that
171           are not known by the DNS root server. This logic does not work in
172           all private zone setups.
173
174           Defaults to "allow-downgrade"
175
176       DNSOverTLS=
177           Takes a boolean argument or "opportunistic". If true all
178           connections to the server will be encrypted. Note that this mode
179           requires a DNS server that supports DNS-over-TLS and has a valid
180           certificate for it's IP. If the DNS server does not support
181           DNS-over-TLS all DNS requests will fail. When set to
182           "opportunistic" DNS request are attempted to send encrypted with
183           DNS-over-TLS. If the DNS server does not support TLS, DNS-over-TLS
184           is disabled. Note that this mode makes DNS-over-TLS vulnerable to
185           "downgrade" attacks, where an attacker might be able to trigger a
186           downgrade to non-encrypted mode by synthesizing a response that
187           suggests DNS-over-TLS was not supported. If set to false, DNS
188           lookups are send over UDP.
189
190           Note that DNS-over-TLS requires additional data to be send for
191           setting up an encrypted connection, and thus results in a small DNS
192           look-up time penalty.
193
194           Note as the resolver is not capable of authenticating the server,
195           it is vulnerable for "man-in-the-middle" attacks.
196
197           In addition to this global DNSOverTLS setting systemd-
198           networkd.service(8) also maintains per-link DNSOverTLS settings.
199           For system DNS servers (see above), only the global DNSOverTLS
200           setting is in effect. For per-link DNS servers the per-link setting
201           is in effect, unless it is unset in which case the global setting
202           is used instead.
203
204           Defaults to off.
205
206       Cache=
207           Takes a boolean or "no-negative" as argument. If "yes" (the
208           default), resolving a domain name which already got queried earlier
209           will return the previous result as long as it is still valid, and
210           thus does not result in a new network request. Be aware that
211           turning off caching comes at a performance penalty, which is
212           particularly high when DNSSEC is used.
213
214                   If "no-negative", only positive answers are cached.
215
216                   Note that caching is turned off implicitly if the
217           configured DNS server is on a host-local IP address (such as
218           127.0.0.1 or ::1), in order to avoid duplicate local caching.
219
220       DNSStubListener=
221           Takes a boolean argument or one of "udp" and "tcp". If "udp", a DNS
222           stub resolver will listen for UDP requests on address 127.0.0.53
223           port 53. If "tcp", the stub will listen for TCP requests on the
224           same address and port. If "yes" (the default), the stub listens for
225           both UDP and TCP requests. If "no", the stub listener is disabled.
226
227           Note that the DNS stub listener is turned off implicitly when its
228           listening address and port are already in use.
229
230       ReadEtcHosts=
231           Takes a boolean argument. If "yes" (the default), the DNS stub
232           resolver will read /etc/hosts, and try to resolve hosts or address
233           by using the entries in the file before sending query to DNS
234           servers.
235

SEE ALSO

237       systemd(1), systemd-resolved.service(8), systemd-networkd.service(8),
238       dnssec-trust-anchors.d(5), resolv.conf(4)
239

NOTES

241        1. RFC 4795
242           https://tools.ietf.org/html/rfc4795
243
244        2. RFC 6762
245           https://tools.ietf.org/html/rfc6762
246
247
248
249systemd 243                                                   RESOLVED.CONF(5)
Impressum