<?xml version='1.0'?>
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<!--
- SPDX-License-Identifier: LGPL-2.1+
--->
+<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="resolved.conf" conditional='ENABLE_RESOLVE'
xmlns:xi="http://www.w3.org/2001/XInclude">
<refsect1>
<title>Options</title>
- <para>The following options are available in the <literal>[Resolve]</literal> section:</para>
+ <para>The following options are available in the [Resolve] section:</para>
<variablelist class='network-directives'>
<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>
+ <listitem><para>A space-separated list of domains optionally prefixed with <literal>~</literal>,
+ used for two distinct purposes described below. Defaults to the empty list.</para>
+
+ <para>Any domains <emphasis>not</emphasis> prefixed with <literal>~</literal> are used as search
+ suffixes when resolving single-label hostnames (domain names which contain no dot), in order to
+ qualify them into fully-qualified domain names (FQDNs). These "search domains" are strictly processed
+ in the order they are specified in, 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> with the <varname>search</varname> keyword are used instead, if
+ that file exists and any domains are configured in it.</para>
+
+ <para>The domains prefixed with <literal>~</literal> are called "routing domains". All domains listed
+ here (both search domains and routing domains after removing the <literal>~</literal> prefix) define
+ a search path that preferably directs DNS queries to this interface. This search path has an effect
+ only when suitable per-link DNS servers are known. Such servers may be defined through the
+ <varname>DNS=</varname> setting (see above) and dynamically at run time, for example from DHCP
+ leases. If no per-link DNS servers are known, routing domains have no effect.</para>
+
+ <para>Use the construct <literal>~.</literal> (which is composed from <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 DNS servers defined for this link preferably for all
+ domains.</para></listitem>
</varlistentry>
<varlistentry>
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 off.</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>
+ <para>Takes a boolean argument or <literal>opportunistic</literal>. If
+ true all connections to the server will be encrypted. Note that this
+ mode requires a DNS server that supports DNS-over-TLS and has a valid
+ certificate. If the hostname was specified in <varname>DNS=</varname>
+ by using the format format <literal>address#server_name</literal> it
+ is used to validate its certificate and also to enable Server Name
+ Indication (SNI) when opening a TLS connection. Otherwise
+ the certificate is checked against the server's IP.
+ If the DNS server does not support DNS-over-TLS all DNS requests will fail.</para>
+
+ <para>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"
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>Note that in <literal>opportunistic</literal> mode the
+ resolver is not capable of authenticating the server, so it is
+ vulnerable to "man-in-the-middle" attacks.</para>
<para>In addition to this global DNSOverTLS setting
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
<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>
+ <listitem><para>Takes a boolean or <literal>no-negative</literal> as 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. If <literal>no-negative</literal>, only positive answers are cached.</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>
<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> (the default), a DNS stub resolver will listen for UDP requests on address 127.0.0.53
+ <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 stub listens for both UDP and TCP requests. If <literal>no</literal>, the stub
+ <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
<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>
+ <listitem><para>Takes a boolean argument. If <literal>yes</literal> (the default),
+ <command>systemd-resolved</command> 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>
+ <varlistentry>
+ <term><varname>ResolveUnicastSingleLabel=</varname></term>
+ <listitem><para>Takes a boolean argument. When false (the default),
+ <command>systemd-resolved</command> will not resolve A and AAAA queries for single-label names over
+ classic DNS. Note that such names may still be resolved if search domains are specified (see
+ <varname>Domains=</varname> above), or using other mechanisms, in particular via LLMNR or from
+ <filename>/etc/hosts</filename>. When true, queries for single-label names will be forwarded to
+ global DNS servers even if no search domains are defined.
+ </para>
+
+ <para>This option is provided for compatibility with configurations where <emphasis>public DNS
+ servers are not used</emphasis>. Forwarding single-label names to servers not under your control is
+ not standard-conformant, see <ulink
+ url="https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/">IAB
+ Statement</ulink>, and may create a privacy and security risk.</para></listitem>
+ </varlistentry>
</variablelist>
</refsect1>
projects / thirdparty / systemd.git / blobdiff