2018-07-03 05:15:39 +08:00
|
|
|
<?xml version='1.0'?>
|
2019-03-14 21:40:58 +08:00
|
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
2015-06-19 01:47:44 +08:00
|
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
2020-11-09 12:23:58 +08:00
|
|
|
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
2014-05-19 04:10:48 +08:00
|
|
|
|
2017-10-03 19:12:29 +08:00
|
|
|
<refentry id="resolved.conf" conditional='ENABLE_RESOLVE'
|
2015-02-04 10:14:13 +08:00
|
|
|
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>
|
2015-06-19 01:47:44 +08:00
|
|
|
<para><filename>/etc/systemd/resolved.conf</filename></para>
|
|
|
|
|
<para><filename>/etc/systemd/resolved.conf.d/*.conf</filename></para>
|
2015-02-04 10:14:13 +08:00
|
|
|
<para><filename>/run/systemd/resolved.conf.d/*.conf</filename></para>
|
2015-06-19 01:47:44 +08:00
|
|
|
<para><filename>/usr/lib/systemd/resolved.conf.d/*.conf</filename></para>
|
2015-02-04 10:14:13 +08:00
|
|
|
</refsynopsisdiv>
|
|
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
|
<title>Description</title>
|
|
|
|
|
|
|
|
|
|
<para>These configuration files control local DNS and LLMNR
|
2014-08-03 13:11:37 +08:00
|
|
|
name resolution.</para>
|
2015-02-04 10:14:13 +08:00
|
|
|
|
|
|
|
|
</refsect1>
|
|
|
|
|
|
2015-03-04 08:10:21 +08:00
|
|
|
<xi:include href="standard-conf.xml" xpointer="main-conf" />
|
2015-02-04 10:14:13 +08:00
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
|
<title>Options</title>
|
|
|
|
|
|
2020-07-06 17:00:06 +08:00
|
|
|
<para>The following options are available in the [Resolve] section:</para>
|
2016-01-29 21:46:06 +08:00
|
|
|
|
2015-02-04 10:14:13 +08:00
|
|
|
<variablelist class='network-directives'>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><varname>DNS=</varname></term>
|
2020-07-19 12:57:51 +08:00
|
|
|
<listitem><para>A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers. Each address can
|
|
|
|
|
optionally take a port number separated with <literal>:</literal>, a network interface name or index separated with
|
|
|
|
|
<literal>%</literal>, and a Server Name Indication (SNI) separated with <literal>#</literal>. When IPv6 address is
|
|
|
|
|
specified with a port number, then the address must be in the square brackets. That is, the acceptable full formats
|
|
|
|
|
are <literal>111.222.333.444:9953%ifname#example.com</literal> for IPv4 and
|
|
|
|
|
<literal>[1111:2222::3333]:9953%ifname#example.com</literal> for IPv6. DNS requests are sent to one of the listed
|
|
|
|
|
DNS servers in parallel to suitable per-link DNS servers acquired from
|
2016-01-26 06:40:02 +08:00
|
|
|
<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>
|
2015-02-04 10:14:13 +08:00
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><varname>FallbackDNS=</varname></term>
|
2020-07-19 12:57:51 +08:00
|
|
|
<listitem><para>A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Please see
|
2020-09-06 01:57:00 +08:00
|
|
|
<varname>DNS=</varname> for acceptable format of addresses. Any per-link DNS servers obtained from
|
2015-02-04 10:14:13 +08:00
|
|
|
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
2016-01-26 06:40:02 +08:00
|
|
|
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>
|
2015-02-04 10:14:13 +08:00
|
|
|
</varlistentry>
|
|
|
|
|
|
2015-11-25 04:12:51 +08:00
|
|
|
<varlistentry>
|
|
|
|
|
<term><varname>Domains=</varname></term>
|
2020-06-03 00:21:04 +08:00
|
|
|
<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
|
2020-06-27 03:30:04 +08:00
|
|
|
a search path that preferably directs DNS queries to this interface. This search path has an effect
|
2020-06-03 00:21:04 +08:00
|
|
|
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>
|
2015-11-25 04:12:51 +08:00
|
|
|
</varlistentry>
|
|
|
|
|
|
2015-02-04 10:14:13 +08:00
|
|
|
<varlistentry>
|
|
|
|
|
<term><varname>LLMNR=</varname></term>
|
|
|
|
|
<listitem><para>Takes a boolean argument or
|
|
|
|
|
<literal>resolve</literal>. Controls Link-Local Multicast Name
|
|
|
|
|
Resolution support (<ulink
|
2018-08-30 08:47:07 +08:00
|
|
|
url="https://tools.ietf.org/html/rfc4795">RFC 4795</ulink>) on
|
2014-08-03 13:11:12 +08:00
|
|
|
the local host. If true, enables full LLMNR responder and
|
2014-08-03 13:11:37 +08:00
|
|
|
resolver support. If false, disables both. If set to
|
|
|
|
|
<literal>resolve</literal>, only resolution support is enabled,
|
2015-02-04 10:14:13 +08:00
|
|
|
but responding is disabled. Note that
|
|
|
|
|
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
2016-01-26 06:40:02 +08:00
|
|
|
also maintains per-link LLMNR settings. LLMNR will be
|
|
|
|
|
enabled on a link only if the per-link and the
|
2015-02-04 10:14:13 +08:00
|
|
|
global setting is on.</para></listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2017-03-16 13:30:16 +08:00
|
|
|
<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>
|
|
|
|
|
|
2016-01-05 07:31:32 +08:00
|
|
|
<varlistentry>
|
|
|
|
|
<term><varname>DNSSEC=</varname></term>
|
|
|
|
|
<listitem><para>Takes a boolean argument or
|
2016-01-06 00:44:16 +08:00
|
|
|
<literal>allow-downgrade</literal>. If true all DNS lookups are
|
2016-01-06 00:37:09 +08:00
|
|
|
DNSSEC-validated locally (excluding LLMNR and Multicast
|
2016-01-29 07:24:27 +08:00
|
|
|
DNS). If the response to a lookup request is detected to be invalid
|
|
|
|
|
a lookup failure is returned to applications. Note that
|
2016-01-06 00:37:09 +08:00
|
|
|
this mode requires a DNS server that supports DNSSEC. If the
|
|
|
|
|
DNS server does not properly support DNSSEC all validations
|
2016-01-06 00:44:16 +08:00
|
|
|
will fail. If set to <literal>allow-downgrade</literal> DNSSEC
|
2016-01-06 00:37:09 +08:00
|
|
|
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>
|
2016-01-05 07:31:32 +08:00
|
|
|
|
|
|
|
|
<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
|
2016-01-05 21:20:27 +08:00
|
|
|
is built into the resolver, additional trust anchors may be
|
|
|
|
|
defined with
|
|
|
|
|
<citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
2016-01-29 07:24:27 +08:00
|
|
|
Trust anchors may change at regular intervals, and old trust
|
2016-01-05 21:20:27 +08:00
|
|
|
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
|
2016-01-05 07:31:32 +08:00
|
|
|
<varname>DNSSEC=</varname> is set to
|
2016-01-06 00:44:16 +08:00
|
|
|
<literal>allow-downgrade</literal> the resolver will
|
2016-01-05 23:42:40 +08:00
|
|
|
automatically turn off DNSSEC validation in such a case.</para>
|
2016-01-05 07:31:32 +08:00
|
|
|
|
|
|
|
|
<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
|
2016-01-05 23:42:40 +08:00
|
|
|
true on systems where it is known that the DNS server supports
|
2016-01-05 07:31:32 +08:00
|
|
|
DNSSEC correctly, and where software or trust anchor updates
|
|
|
|
|
happen regularly. On other systems it is recommended to set
|
|
|
|
|
<varname>DNSSEC=</varname> to
|
2016-01-06 00:44:16 +08:00
|
|
|
<literal>allow-downgrade</literal>.</para>
|
2016-01-06 02:57:33 +08:00
|
|
|
|
|
|
|
|
<para>In addition to this global DNSSEC setting
|
|
|
|
|
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
2016-01-26 06:40:02 +08:00
|
|
|
also maintains per-link DNSSEC settings. For system DNS
|
2016-01-06 02:57:33 +08:00
|
|
|
servers (see above), only the global DNSSEC setting is in
|
2016-01-26 06:40:02 +08:00
|
|
|
effect. For per-link DNS servers the per-link
|
2016-01-06 02:57:33 +08:00
|
|
|
setting is in effect, unless it is unset in which case the
|
|
|
|
|
global setting is used instead.</para>
|
|
|
|
|
|
2016-01-06 05:13:56 +08:00
|
|
|
<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>
|
|
|
|
|
|
2020-11-16 18:13:49 +08:00
|
|
|
<para>Defaults to <literal>allow-downgrade</literal>.</para>
|
2016-01-05 07:31:32 +08:00
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2018-06-12 03:33:57 +08:00
|
|
|
<varlistentry>
|
2018-06-14 02:26:24 +08:00
|
|
|
<term><varname>DNSOverTLS=</varname></term>
|
2018-06-12 03:33:57 +08:00
|
|
|
<listitem>
|
2020-03-04 07:31:25 +08:00
|
|
|
<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>
|
2018-06-12 03:33:57 +08:00
|
|
|
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>
|
|
|
|
|
|
2019-11-14 00:37:15 +08:00
|
|
|
<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>
|
2018-06-12 03:33:57 +08:00
|
|
|
|
2020-11-18 20:47:43 +08:00
|
|
|
<para>In addition to this global <varname>DNSOverTLS=</varname> setting
|
2018-06-12 03:33:57 +08:00
|
|
|
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
2020-11-18 20:47:43 +08:00
|
|
|
also maintains per-link <varname>DNSOverTLS=</varname> settings. For system DNS servers (see above), only the global
|
|
|
|
|
<varname>DNSOverTLS=</varname> 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>
|
2018-06-12 03:33:57 +08:00
|
|
|
|
|
|
|
|
<para>Defaults to off.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2016-06-24 13:54:28 +08:00
|
|
|
<varlistentry>
|
|
|
|
|
<term><varname>Cache=</varname></term>
|
2020-04-16 01:52:47 +08:00
|
|
|
<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>
|
2016-07-23 02:17:23 +08:00
|
|
|
|
2020-11-24 21:44:07 +08:00
|
|
|
<para>Note that caching is turned off by default for host-local DNS servers.
|
|
|
|
|
See <varname>CacheFromLocalhost=</varname> for details.</para></listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><varname>CacheFromLocalhost=</varname></term>
|
|
|
|
|
<listitem><para>Takes a boolean as argument. If <literal>no</literal> (the default), and response cames from
|
|
|
|
|
host-local IP address (such as 127.0.0.1 or ::1), the result wouldn't be cached in order to avoid
|
|
|
|
|
potential duplicate local caching.</para>
|
|
|
|
|
</listitem>
|
2016-06-24 13:54:28 +08:00
|
|
|
</varlistentry>
|
|
|
|
|
|
2016-09-01 06:34:29 +08:00
|
|
|
<varlistentry>
|
|
|
|
|
<term><varname>DNSStubListener=</varname></term>
|
|
|
|
|
<listitem><para>Takes a boolean argument or one of <literal>udp</literal> and <literal>tcp</literal>. If
|
2018-10-08 19:03:28 +08:00
|
|
|
<literal>udp</literal>, a DNS stub resolver will listen for UDP requests on address 127.0.0.53
|
2016-09-01 06:34:29 +08:00
|
|
|
port 53. If <literal>tcp</literal>, the stub will listen for TCP requests on the same address and port. If
|
2018-10-08 19:03:28 +08:00
|
|
|
<literal>yes</literal> (the default), the stub listens for both UDP and TCP requests. If <literal>no</literal>, the stub
|
2016-09-01 06:34:29 +08:00
|
|
|
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>
|
|
|
|
|
|
2020-08-29 15:12:10 +08:00
|
|
|
<varlistentry>
|
|
|
|
|
<term><varname>DNSStubListenerExtra=</varname></term>
|
2020-09-04 11:58:32 +08:00
|
|
|
<listitem><para>Takes an IPv4 or IPv6 address to listen on. The address may be optionally
|
|
|
|
|
prefixed with a protocol name (<literal>udp</literal> or <literal>tcp</literal>) separated with
|
|
|
|
|
<literal>:</literal>. If the protocol is not specified, the service will listen on both UDP and
|
|
|
|
|
TCP. It may be also optionally suffixed by a numeric port number with separator
|
|
|
|
|
<literal>:</literal>. When an IPv6 address is specified with a port number, then the address
|
|
|
|
|
must be in the square brackets. If the port is not specified, then the service uses port 53.
|
|
|
|
|
Note that this is independent of the primary DNS stub configured with
|
|
|
|
|
<varname>DNSStubListener=</varname>, and only configures <emphasis>additional</emphasis>
|
|
|
|
|
sockets to listen on. This option can be specified multiple times. If an empty string is
|
|
|
|
|
assigned, then the all previous assignments are cleared. Defaults to unset.</para>
|
|
|
|
|
|
|
|
|
|
<para>Examples:
|
|
|
|
|
<programlisting>DNSStubListenerExtra=192.168.10.10
|
|
|
|
|
DNSStubListenerExtra=2001:db8:0:f102::10
|
|
|
|
|
DNSStubListenerExtra=192.168.10.11:9953
|
|
|
|
|
DNSStubListenerExtra=[2001:db8:0:f102::11]:9953
|
|
|
|
|
DNSStubListenerExtra=tcp:192.168.10.12
|
|
|
|
|
DNSStubListenerExtra=udp:2001:db8:0:f102::12
|
|
|
|
|
DNSStubListenerExtra=tcp:192.168.10.13:9953
|
|
|
|
|
DNSStubListenerExtra=udp:[2001:db8:0:f102::13]:9953</programlisting>
|
|
|
|
|
</para></listitem>
|
2020-08-29 15:12:10 +08:00
|
|
|
</varlistentry>
|
|
|
|
|
|
2018-07-28 20:46:00 +08:00
|
|
|
<varlistentry>
|
|
|
|
|
<term><varname>ReadEtcHosts=</varname></term>
|
2020-06-03 23:01:34 +08:00
|
|
|
<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>
|
2018-07-28 20:46:00 +08:00
|
|
|
</varlistentry>
|
|
|
|
|
|
2020-06-03 23:01:34 +08:00
|
|
|
<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>
|
2015-02-04 10:14:13 +08:00
|
|
|
</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>,
|
2016-01-05 21:20:27 +08:00
|
|
|
<citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
2021-06-29 16:49:56 +08:00
|
|
|
<citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
2015-02-04 10:14:13 +08:00
|
|
|
</para>
|
|
|
|
|
</refsect1>
|
2014-05-19 04:10:48 +08:00
|
|
|
|
|
|
|
|
</refentry>
|
