| <?xml version='1.0'?> |
| <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" |
| "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> |
| |
| <!-- |
| SPDX-License-Identifier: LGPL-2.1+ |
| --> |
| |
| <refentry id="resolved.conf" conditional='ENABLE_RESOLVE' |
| xmlns:xi="http://www.w3.org/2001/XInclude"> |
| <refentryinfo> |
| <title>resolved.conf</title> |
| <productname>systemd</productname> |
| </refentryinfo> |
| |
| <refmeta> |
| <refentrytitle>resolved.conf</refentrytitle> |
| <manvolnum>5</manvolnum> |
| </refmeta> |
| |
| <refnamediv> |
| <refname>resolved.conf</refname> |
| <refname>resolved.conf.d</refname> |
| <refpurpose>Network Name Resolution configuration files</refpurpose> |
| </refnamediv> |
| |
| <refsynopsisdiv> |
| <para><filename>/etc/systemd/resolved.conf</filename></para> |
| <para><filename>/etc/systemd/resolved.conf.d/*.conf</filename></para> |
| <para><filename>/run/systemd/resolved.conf.d/*.conf</filename></para> |
| <para><filename>/usr/lib/systemd/resolved.conf.d/*.conf</filename></para> |
| </refsynopsisdiv> |
| |
| <refsect1> |
| <title>Description</title> |
| |
| <para>These configuration files control local DNS and LLMNR |
| name resolution.</para> |
| |
| </refsect1> |
| |
| <xi:include href="standard-conf.xml" xpointer="main-conf" /> |
| |
| <refsect1> |
| <title>Options</title> |
| |
| <para>The following options are available in the <literal>[Resolve]</literal> section:</para> |
| |
| <variablelist class='network-directives'> |
| |
| <varlistentry> |
| <term><varname>DNS=</varname></term> |
| <listitem><para>A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers. DNS requests |
| are sent to one of the listed DNS servers in parallel to suitable per-link DNS servers acquired from |
| <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> or |
| set at runtime by external applications. For compatibility reasons, if this setting is not specified, the DNS |
| servers listed in <filename>/etc/resolv.conf</filename> are used instead, if that file exists and any servers |
| are configured in it. This setting defaults to the empty list.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>FallbackDNS=</varname></term> |
| <listitem><para>A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Any |
| per-link DNS servers obtained from |
| <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
| take precedence over this setting, as do any servers set via <varname>DNS=</varname> above or |
| <filename>/etc/resolv.conf</filename>. This setting is hence only used if no other DNS server information is |
| known. If this option is not given, a compiled-in list of DNS servers is used instead.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>Domains=</varname></term> |
| <listitem><para>A space-separated list of domains. These domains are used as search suffixes when resolving |
| single-label host names (domain names which contain no dot), in order to qualify them into fully-qualified |
| domain names (FQDNs). Search domains are strictly processed in the order they are specified, until the name |
| with the suffix appended is found. For compatibility reasons, if this setting is not specified, the search |
| domains listed in <filename>/etc/resolv.conf</filename> are used instead, if that file exists and any domains |
| are configured in it. This setting defaults to the empty list.</para> |
| |
| <para>Specified domain names may optionally be prefixed with <literal>~</literal>. In this case they do not |
| define a search path, but preferably direct DNS queries for the indicated domains to the DNS servers configured |
| with the system <varname>DNS=</varname> setting (see above), in case additional, suitable per-link DNS servers |
| are known. If no per-link DNS servers are known using the <literal>~</literal> syntax has no effect. Use the |
| construct <literal>~.</literal> (which is composed of <literal>~</literal> to indicate a routing domain and |
| <literal>.</literal> to indicate the DNS root domain that is the implied suffix of all DNS domains) to use the |
| system DNS server defined with <varname>DNS=</varname> preferably for all domains.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>LLMNR=</varname></term> |
| <listitem><para>Takes a boolean argument or |
| <literal>resolve</literal>. Controls Link-Local Multicast Name |
| Resolution support (<ulink |
| url="https://tools.ietf.org/html/rfc4795">RFC 4795</ulink>) on |
| the local host. If true, enables full LLMNR responder and |
| resolver support. If false, disables both. If set to |
| <literal>resolve</literal>, only resolution support is enabled, |
| but responding is disabled. Note that |
| <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
| also maintains per-link LLMNR settings. LLMNR will be |
| enabled on a link only if the per-link and the |
| global setting is on.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>MulticastDNS=</varname></term> |
| <listitem><para>Takes a boolean argument or |
| <literal>resolve</literal>. Controls Multicast DNS support (<ulink |
| url="https://tools.ietf.org/html/rfc6762">RFC 6762</ulink>) on |
| the local host. If true, enables full Multicast DNS responder and |
| resolver support. If false, disables both. If set to |
| <literal>resolve</literal>, only resolution support is enabled, |
| but responding is disabled. Note that |
| <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
| also maintains per-link Multicast DNS settings. Multicast DNS will be |
| enabled on a link only if the per-link and the |
| global setting is on.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>DNSSEC=</varname></term> |
| <listitem><para>Takes a boolean argument or |
| <literal>allow-downgrade</literal>. If true all DNS lookups are |
| DNSSEC-validated locally (excluding LLMNR and Multicast |
| DNS). If the response to a lookup request is detected to be invalid |
| a lookup failure is returned to applications. Note that |
| this mode requires a DNS server that supports DNSSEC. If the |
| DNS server does not properly support DNSSEC all validations |
| will fail. If set to <literal>allow-downgrade</literal> DNSSEC |
| validation is attempted, but if the server does not support |
| DNSSEC properly, DNSSEC mode is automatically disabled. Note |
| that this mode makes DNSSEC validation vulnerable to |
| "downgrade" attacks, where an attacker might be able to |
| trigger a downgrade to non-DNSSEC mode by synthesizing a DNS |
| response that suggests DNSSEC was not supported. If set to |
| false, DNS lookups are not DNSSEC validated.</para> |
| |
| <para>Note that DNSSEC validation requires retrieval of |
| additional DNS data, and thus results in a small DNS look-up |
| time penalty.</para> |
| |
| <para>DNSSEC requires knowledge of "trust anchors" to prove |
| data integrity. The trust anchor for the Internet root domain |
| is built into the resolver, additional trust anchors may be |
| defined with |
| <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>. |
| Trust anchors may change at regular intervals, and old trust |
| anchors may be revoked. In such a case DNSSEC validation is |
| not possible until new trust anchors are configured locally or |
| the resolver software package is updated with the new root |
| trust anchor. In effect, when the built-in trust anchor is |
| revoked and <varname>DNSSEC=</varname> is true, all further |
| lookups will fail, as it cannot be proved anymore whether |
| lookups are correctly signed, or validly unsigned. If |
| <varname>DNSSEC=</varname> is set to |
| <literal>allow-downgrade</literal> the resolver will |
| automatically turn off DNSSEC validation in such a case.</para> |
| |
| <para>Client programs looking up DNS data will be informed |
| whether lookups could be verified using DNSSEC, or whether the |
| returned data could not be verified (either because the data |
| was found unsigned in the DNS, or the DNS server did not |
| support DNSSEC or no appropriate trust anchors were known). In |
| the latter case it is assumed that client programs employ a |
| secondary scheme to validate the returned DNS data, should |
| this be required.</para> |
| |
| <para>It is recommended to set <varname>DNSSEC=</varname> to |
| true on systems where it is known that the DNS server supports |
| DNSSEC correctly, and where software or trust anchor updates |
| happen regularly. On other systems it is recommended to set |
| <varname>DNSSEC=</varname> to |
| <literal>allow-downgrade</literal>.</para> |
| |
| <para>In addition to this global DNSSEC setting |
| <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
| also maintains per-link DNSSEC settings. For system DNS |
| servers (see above), only the global DNSSEC setting is in |
| effect. For per-link DNS servers the per-link |
| setting is in effect, unless it is unset in which case the |
| global setting is used instead.</para> |
| |
| <para>Site-private DNS zones generally conflict with DNSSEC |
| operation, unless a negative (if the private zone is not |
| signed) or positive (if the private zone is signed) trust |
| anchor is configured for them. If |
| <literal>allow-downgrade</literal> mode is selected, it is |
| attempted to detect site-private DNS zones using top-level |
| domains (TLDs) that are not known by the DNS root server. This |
| logic does not work in all private zone setups.</para> |
| |
| <para>Defaults to <literal>allow-downgrade</literal></para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>DNSOverTLS=</varname></term> |
| <listitem> |
| <para>Takes false or |
| <literal>opportunistic</literal>. When set to <literal>opportunistic</literal> |
| DNS request are attempted to send encrypted with DNS-over-TLS. |
| If the DNS server does not support TLS, DNS-over-TLS is disabled. |
| Note that this mode makes DNS-over-TLS vulnerable to "downgrade" |
| attacks, where an attacker might be able to trigger a downgrade |
| to non-encrypted mode by synthesizing a response that suggests |
| DNS-over-TLS was not supported. If set to false, DNS lookups |
| are send over UDP.</para> |
| |
| <para>Note that DNS-over-TLS requires additional data to be |
| send for setting up an encrypted connection, and thus results |
| in a small DNS look-up time penalty.</para> |
| |
| <para>Note as the resolver is not capable of authenticating |
| the server, it is vulnerable for "man-in-the-middle" attacks.</para> |
| |
| <para>In addition to this global DNSOverTLS setting |
| <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> |
| also maintains per-link DNSOverTLS settings. For system DNS |
| servers (see above), only the global DNSOverTLS setting is in |
| effect. For per-link DNS servers the per-link |
| setting is in effect, unless it is unset in which case the |
| global setting is used instead.</para> |
| |
| <para>Defaults to off.</para> |
| </listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>Cache=</varname></term> |
| <listitem><para>Takes a boolean argument. If <literal>yes</literal> (the default), resolving a domain name |
| which already got queried earlier will return the previous result as long as it is still valid, and thus does |
| not result in a new network request. Be aware that turning off caching comes at a performance penalty, which |
| is particularly high when DNSSEC is used.</para> |
| |
| <para>Note that caching is turned off implicitly if the configured DNS server is on a host-local IP address |
| (such as 127.0.0.1 or ::1), in order to avoid duplicate local caching.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>DNSStubListener=</varname></term> |
| <listitem><para>Takes a boolean argument or one of <literal>udp</literal> and <literal>tcp</literal>. If |
| <literal>udp</literal>, a DNS stub resolver will listen for UDP requests on address 127.0.0.53 |
| port 53. If <literal>tcp</literal>, the stub will listen for TCP requests on the same address and port. If |
| <literal>yes</literal> (the default), the stub listens for both UDP and TCP requests. If <literal>no</literal>, the stub |
| listener is disabled.</para> |
| |
| <para>Note that the DNS stub listener is turned off implicitly when its listening address and port are already |
| in use.</para></listitem> |
| </varlistentry> |
| |
| <varlistentry> |
| <term><varname>ReadEtcHosts=</varname></term> |
| <listitem><para>Takes a boolean argument. If <literal>yes</literal> (the default), the DNS stub resolver will read |
| <filename>/etc/hosts</filename>, and try to resolve hosts or address by using the entries in the file before |
| sending query to DNS servers.</para></listitem> |
| </varlistentry> |
| |
| </variablelist> |
| </refsect1> |
| |
| <refsect1> |
| <title>See Also</title> |
| <para> |
| <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, |
| <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, |
| <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>4</manvolnum></citerefentry> |
| </para> |
| </refsect1> |
| |
| </refentry> |