1RESOLVED.CONF(5) resolved.conf RESOLVED.CONF(5)
2
6 resolved.conf, resolved.conf.d - Network Name Resolution configuration
7 files
8
10 /etc/systemd/resolved.conf
11 /etc/systemd/resolved.conf.d/*.conf
13 /run/systemd/resolved.conf.d/*.conf
15 /usr/lib/systemd/resolved.conf.d/*.conf
17
19 These configuration files control local DNS and LLMNR name resolution.
20
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 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/. The main configuration file is read
31 before any of the configuration directories, and has the lowest
32 precedence; entries in a file in any configuration directory override
33 entries in the single configuration file. Files in the *.conf.d/
34 configuration subdirectories are sorted by their filename in
35 lexicographic order, regardless of in which of the subdirectories they
36 reside. When multiple files specify the same option, for options which
37 accept just a single value, the entry in the file with the
38 lexicographically latest name takes precedence. For options which
39 accept a list of values, entries are collected as they occur in files
40 sorted lexicographically.
41 Files in /etc/ are reserved for the local administrator, who may use
43 this logic to override the configuration files installed by vendor
44 packages. It is recommended to prefix all filenames in those
45 subdirectories with a two-digit number and a dash, to simplify the
46 ordering of the files.
47 To disable a configuration file supplied by the vendor, the recommended
49 way is to place a symlink to /dev/null in the configuration directory
50 in /etc/, with the same filename as the vendor configuration file.
51
53 The following options are available in the "[Resolve]" section:
54 DNS=
56 A space-separated list of IPv4 and IPv6 addresses to use as system
57 DNS servers. DNS requests are sent to one of the listed DNS servers
58 in parallel to suitable per-link DNS servers acquired from systemd-
59 networkd.service(8) or set at runtime by external applications. For
60 compatibility reasons, if this setting is not specified, the DNS
61 servers listed in /etc/resolv.conf are used instead, if that file
62 exists and any servers are configured in it. This setting defaults
63 to the empty list.
64 FallbackDNS=
66 A space-separated list of IPv4 and IPv6 addresses to use as the
67 fallback DNS servers. Any per-link DNS servers obtained from
68 systemd-networkd.service(8) take precedence over this setting, as
69 do any servers set via DNS= above or /etc/resolv.conf. This setting
70 is hence only used if no other DNS server information is known. If
71 this option is not given, a compiled-in list of DNS servers is used
72 instead.
73 Domains=
75 A space-separated list of domains. These domains are used as search
76 suffixes when resolving single-label host names (domain names which
77 contain no dot), in order to qualify them into fully-qualified
78 domain names (FQDNs). Search domains are strictly processed in the
79 order they are specified, until the name with the suffix appended
80 is found. For compatibility reasons, if this setting is not
81 specified, the search domains listed in /etc/resolv.conf are used
82 instead, if that file exists and any domains are configured in it.
83 This setting defaults to the empty list.
84 Specified domain names may optionally be prefixed with "~". In this
86 case they do not define a search path, but preferably direct DNS
87 queries for the indicated domains to the DNS servers configured
88 with the system DNS= setting (see above), in case additional,
89 suitable per-link DNS servers are known. If no per-link DNS servers
90 are known using the "~" syntax has no effect. Use the construct
91 "~." (which is composed of "~" to indicate a routing domain and
92 "." to indicate the DNS root domain that is the implied suffix of
93 all DNS domains) to use the system DNS server defined with DNS=
94 preferably for all domains.
95 LLMNR=
97 Takes a boolean argument or "resolve". Controls Link-Local
98 Multicast Name Resolution support (RFC 4795[1]) on the local host.
99 If true, enables full LLMNR responder and resolver support. If
100 false, disables both. If set to "resolve", only resolution support
101 is enabled, but responding is disabled. Note that systemd-
102 networkd.service(8) also maintains per-link LLMNR settings. LLMNR
103 will be enabled on a link only if the per-link and the global
104 setting is on.
105 MulticastDNS=
107 Takes a boolean argument or "resolve". Controls Multicast DNS
108 support (RFC 6762[2]) on the local host. If true, enables full
109 Multicast DNS responder and resolver support. If false, disables
110 both. If set to "resolve", only resolution support is enabled, but
111 responding is disabled. Note that systemd-networkd.service(8) also
112 maintains per-link Multicast DNS settings. Multicast DNS will be
113 enabled on a link only if the per-link and the global setting is
114 on.
115 DNSSEC=
117 Takes a boolean argument or "allow-downgrade". If true all DNS
118 lookups are DNSSEC-validated locally (excluding LLMNR and Multicast
119 DNS). If the response to a lookup request is detected to be invalid
120 a lookup failure is returned to applications. Note that this mode
121 requires a DNS server that supports DNSSEC. If the DNS server does
122 not properly support DNSSEC all validations will fail. If set to
123 "allow-downgrade" DNSSEC validation is attempted, but if the server
124 does not support DNSSEC properly, DNSSEC mode is automatically
125 disabled. Note that this mode makes DNSSEC validation vulnerable to
126 "downgrade" attacks, where an attacker might be able to trigger a
127 downgrade to non-DNSSEC mode by synthesizing a DNS response that
128 suggests DNSSEC was not supported. If set to false, DNS lookups are
129 not DNSSEC validated.
130 Note that DNSSEC validation requires retrieval of additional DNS
132 data, and thus results in a small DNS look-up time penalty.
133 DNSSEC requires knowledge of "trust anchors" to prove data
135 integrity. The trust anchor for the Internet root domain is built
136 into the resolver, additional trust anchors may be defined with
137 dnssec-trust-anchors.d(5). Trust anchors may change at regular
138 intervals, and old trust anchors may be revoked. In such a case
139 DNSSEC validation is not possible until new trust anchors are
140 configured locally or the resolver software package is updated with
141 the new root trust anchor. In effect, when the built-in trust
142 anchor is revoked and DNSSEC= is true, all further lookups will
143 fail, as it cannot be proved anymore whether lookups are correctly
144 signed, or validly unsigned. If DNSSEC= is set to "allow-downgrade"
145 the resolver will automatically turn off DNSSEC validation in such
146 a case.
147 Client programs looking up DNS data will be informed whether
149 lookups could be verified using DNSSEC, or whether the returned
150 data could not be verified (either because the data was found
151 unsigned in the DNS, or the DNS server did not support DNSSEC or no
152 appropriate trust anchors were known). In the latter case it is
153 assumed that client programs employ a secondary scheme to validate
154 the returned DNS data, should this be required.
155 It is recommended to set DNSSEC= to true on systems where it is
157 known that the DNS server supports DNSSEC correctly, and where
158 software or trust anchor updates happen regularly. On other systems
159 it is recommended to set DNSSEC= to "allow-downgrade".
160 In addition to this global DNSSEC setting systemd-
162 networkd.service(8) also maintains per-link DNSSEC settings. For
163 system DNS servers (see above), only the global DNSSEC setting is
164 in effect. For per-link DNS servers the per-link setting is in
165 effect, unless it is unset in which case the global setting is used
166 instead.
167 Site-private DNS zones generally conflict with DNSSEC operation,
169 unless a negative (if the private zone is not signed) or positive
170 (if the private zone is signed) trust anchor is configured for
171 them. If "allow-downgrade" mode is selected, it is attempted to
172 detect site-private DNS zones using top-level domains (TLDs) that
173 are not known by the DNS root server. This logic does not work in
174 all private zone setups.
175 Defaults to "allow-downgrade"
177 DNSOverTLS=
179 Takes a boolean argument or "opportunistic". If true all
180 connections to the server will be encrypted. Note that this mode
181 requires a DNS server that supports DNS-over-TLS and has a valid
182 certificate for it's IP. If the DNS server does not support
183 DNS-over-TLS all DNS requests will fail. When set to
184 "opportunistic" DNS request are attempted to send encrypted with
185 DNS-over-TLS. If the DNS server does not support TLS, DNS-over-TLS
186 is disabled. Note that this mode makes DNS-over-TLS vulnerable to
187 "downgrade" attacks, where an attacker might be able to trigger a
188 downgrade to non-encrypted mode by synthesizing a response that
189 suggests DNS-over-TLS was not supported. If set to false, DNS
190 lookups are send over UDP.
191 Note that DNS-over-TLS requires additional data to be send for
193 setting up an encrypted connection, and thus results in a small DNS
194 look-up time penalty.
195 Note that in "opportunistic" mode the resolver is not capable of
197 authenticating the server, so it is vulnerable to
198 "man-in-the-middle" attacks.
199 Server Name Indication (SNI) can be used when opening a TLS
201 connection. Entries in DNS= should be in format
202 "address#server_name".
203 In addition to this global DNSOverTLS setting systemd-
205 networkd.service(8) also maintains per-link DNSOverTLS settings.
206 For system DNS servers (see above), only the global DNSOverTLS
207 setting is in effect. For per-link DNS servers the per-link setting
208 is in effect, unless it is unset in which case the global setting
209 is used instead.
210 Defaults to off.
212 Cache=
214 Takes a boolean or "no-negative" as argument. If "yes" (the
215 default), resolving a domain name which already got queried earlier
216 will return the previous result as long as it is still valid, and
217 thus does not result in a new network request. Be aware that
218 turning off caching comes at a performance penalty, which is
219 particularly high when DNSSEC is used.
220 If "no-negative", only positive answers are cached.
222 Note that caching is turned off implicitly if the
224 configured DNS server is on a host-local IP address (such as
225 127.0.0.1 or ::1), in order to avoid duplicate local caching.
226 DNSStubListener=
228 Takes a boolean argument or one of "udp" and "tcp". If "udp", a DNS
229 stub resolver will listen for UDP requests on address 127.0.0.53
230 port 53. If "tcp", the stub will listen for TCP requests on the
231 same address and port. If "yes" (the default), the stub listens for
232 both UDP and TCP requests. If "no", the stub listener is disabled.
233 Note that the DNS stub listener is turned off implicitly when its
235 listening address and port are already in use.
236 ReadEtcHosts=
238 Takes a boolean argument. If "yes" (the default), the DNS stub
239 resolver will read /etc/hosts, and try to resolve hosts or address
240 by using the entries in the file before sending query to DNS
241 servers.
242
244 systemd(1), systemd-resolved.service(8), systemd-networkd.service(8),
245 dnssec-trust-anchors.d(5), resolv.conf(4)
246
248 1. RFC 4795
249 https://tools.ietf.org/html/rfc4795
250 2. RFC 6762
252 https://tools.ietf.org/html/rfc6762
253systemd 245 RESOLVED.CONF(5)