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/. 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 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
51 The following options are available in the "[Resolve]" section:
52 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 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 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 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 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 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 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 Note that DNSSEC validation requires retrieval of additional DNS
130 data, and thus results in a small DNS look-up time penalty.
131 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 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 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 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 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 Defaults to "allow-downgrade"
175 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 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 Note as the resolver is not capable of authenticating the server,
195 it is vulnerable for "man-in-the-middle" attacks.
196 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 Defaults to off.
205 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 If "no-negative", only positive answers are cached.
215 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 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 Note that the DNS stub listener is turned off implicitly when its
228 listening address and port are already in use.
229 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
237 systemd(1), systemd-resolved.service(8), systemd-networkd.service(8),
238 dnssec-trust-anchors.d(5), resolv.conf(4)
239
241 1. RFC 4795
242 https://tools.ietf.org/html/rfc4795
243 2. RFC 6762
245 https://tools.ietf.org/html/rfc6762
246systemd 243 RESOLVED.CONF(5)