mirror of
https://github.com/systemd/systemd.git
synced 2024-12-22 17:35:35 +03:00
man/systemd-resolved: reword the description of query a bit
The phrase "routing domains" is used to mean both route-only domains and search domains. Route-only domains are always called like that, and not just "route domains". Some paragraphs are reordered to describe synthetisized records first, then LLMNR, then various ways quries are routed. Fixes #8928, hopefully.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek
parent
60de93e744
commit
9e1804b24c
@ -87,17 +87,17 @@
|
||||
<refsect1>
|
||||
<title>Synthetic Records</title>
|
||||
|
||||
<para><command>systemd-resolved</command> synthesizes DNS resource records (RRs) for the following
|
||||
<para><command>systemd-resolved</command> synthetizes DNS resource records (RRs) for the following
|
||||
cases:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>The local, configured hostname is resolved to all locally configured IP addresses
|
||||
ordered by their scope, or — if none are configured — the IPv4 address 127.0.0.2 (which is on the local
|
||||
loopback) and the IPv6 address ::1 (which is the local host).</para></listitem>
|
||||
loopback interface) and the IPv6 address ::1 (which is the local host).</para></listitem>
|
||||
|
||||
<listitem><para>The hostnames <literal>localhost</literal> and <literal>localhost.localdomain</literal>
|
||||
(as well as any hostname ending in <literal>.localhost</literal> or
|
||||
<literal>.localhost.localdomain</literal>) are resolved to the IP addresses 127.0.0.1 and ::1.
|
||||
as well as any hostname ending in <literal>.localhost</literal> or
|
||||
<literal>.localhost.localdomain</literal> are resolved to the IP addresses 127.0.0.1 and ::1.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>The hostname <literal>_gateway</literal> is resolved to all current default routing
|
||||
@ -119,98 +119,97 @@
|
||||
according to the following rules:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Names for which synthetic records are generated (as listed in the previous section) are
|
||||
never routed to the network and a reply is sent immediately. In particular this means that lookups for
|
||||
<literal>localhost</literal> are never routed to the network.</para></listitem>
|
||||
<listitem><para>Names for which synthetic records are generated (the local hostname,
|
||||
<literal>localhost</literal> and <literal>localdomain</literal>, local gateway, as listed in the
|
||||
previous section) and addresses configured in <filename>/etc/hosts</filename> are never routed to the
|
||||
network and a reply is sent immediately.</para></listitem>
|
||||
|
||||
<listitem><para>Single-label names are routed to all local interfaces capable of IP multicasting, where
|
||||
LLMNR is not disabled, using the LLMNR protocol. Lookups for IPv4 addresses are only sent via LLMNR on
|
||||
IPv4, and lookups for IPv6 addresses are only sent via LLMNR on IPv6. Lookups for the locally
|
||||
configured hostname and the <literal>_gateway</literal> hostname are never routed to LLMNR.
|
||||
</para></listitem>
|
||||
<listitem><para>Single-label names are resolved using LLMNR on all local interfaces where LLMNR is
|
||||
enabled. Lookups for IPv4 addresses are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are
|
||||
only sent via LLMNR on IPv6. Note that lookups for single-label synthetized names are not routed to
|
||||
LLMNR, MulticastDNS or unicast DNS.</para></listitem>
|
||||
|
||||
<listitem><para>Multi-label names with the domain suffix <literal>.local</literal> are routed to all
|
||||
local interfaces capable of IP multicasting, where MulticastDNS is not disabled, using the MulticastDNS
|
||||
protocol. As with LLMNR, IPv4 address lookups are sent via IPv4 and IPv6 address lookups are sent via
|
||||
IPv6.</para></listitem>
|
||||
<listitem><para>Queries for the address records (A and AAAA) of single-label non-synthetized names are
|
||||
resolved via unicast DNS using search domains. For any interface which defines search domains, such
|
||||
look-ups are routed to that interface, suffixed with each of the search domains defined on that
|
||||
interface in turn. When global search domains are defined, such look-ups are routed to all interfaces,
|
||||
suffixed by each of the global search domains in turn. Additionally, lookup of single-label names via
|
||||
unicast DNS may be enabled with the <varname>ResolveUnicastSingleLabel=yes</varname> setting. The
|
||||
details of which servers are queried and how the final reply is chosen are described below. Note that
|
||||
this means that address queries for single-label names are never sent out to remote DNS servers by
|
||||
default, and resoulution is only possible if search domains are defined.</para></listitem>
|
||||
|
||||
<listitem><para>Resolution of address records (A and AAAA) via unicast DNS (i.e. not LLMNR or
|
||||
MulticastDNS) for non-synthesized single-label names is allowed for non-top-level domains. This means
|
||||
that such records can be resolved when search domains are defined. For any interface which defines
|
||||
search domains, such look-ups are routed to that interface, suffixed with each of the search domains
|
||||
defined on that interface in turn. When global search domains are defined, such look-ups are routed to
|
||||
all interfaces, suffixed by each of the global search domains in turn. Additionally, lookup of
|
||||
single-label names via unicast DNS may be enabled with the
|
||||
<varname>ResolveUnicastSingleLabel=yes</varname> setting. The details of which servers are queried and
|
||||
how the final reply is chosen are described below. Note that this means that address queries for
|
||||
single-label names are never sent out to remote DNS servers by default, and if no search domains are
|
||||
defined, resolution will fail.</para></listitem>
|
||||
<listitem><para>Multi-label names with the domain suffix <literal>.local</literal> are resolved using
|
||||
MulticastDNS on all local interfaces where MulticastDNS is enabled. As with LLMNR, IPv4 address lookups
|
||||
are sent via IPv4 and IPv6 address lookups are sent via IPv6.</para></listitem>
|
||||
|
||||
<listitem><para>Other multi-label names are routed to all local interfaces that have a DNS server
|
||||
configured, plus the globally configured DNS servers if there are any. Note that by default, lookups for
|
||||
domains with the <literal>.local</literal> suffix are not routed to DNS servers, unless the domain is
|
||||
specified explicitly as routing or search domain for the DNS server and interface. This means that on
|
||||
networks where the <literal>.local</literal> domain is defined in a site-specific DNS server, explicit
|
||||
search or routing domains need to be configured to make lookups within this DNS domain work. Note that
|
||||
these days, it's generally recommended to avoid defining <literal>.local</literal> in a DNS server, as
|
||||
<ulink url="https://tools.ietf.org/html/rfc6762">RFC6762</ulink> reserves this domain for exclusive
|
||||
<listitem><para>Queries for multi-label names are routed via unicast DNS on local interfaces that have
|
||||
a DNS server configured, plus the globally configured DNS servers if there are any. Which interfaces
|
||||
are used is determined by the routing logic based on search and route-only domains, described below.
|
||||
Note that by default, lookups for domains with the <literal>.local</literal> suffix are not routed to
|
||||
DNS servers, unless the domain is specified explicitly as routing or search domain for the DNS server
|
||||
and interface. This means that on networks where the <literal>.local</literal> domain is defined in a
|
||||
site-specific DNS server, explicit search or routing domains need to be configured to make lookups work
|
||||
within this DNS domain. Note that these days, it's generally recommended to avoid defining
|
||||
<literal>.local</literal> in a DNS server, as <ulink
|
||||
url="https://tools.ietf.org/html/rfc6762">RFC6762</ulink> reserves this domain for exclusive
|
||||
MulticastDNS use.</para></listitem>
|
||||
|
||||
<listitem><para>Address lookups are routed similarly to multi-label names, with the exception that
|
||||
addresses from the link-local address range are never routed to unicast DNS and are only resolved using
|
||||
LLMNR and MulticastDNS (when enabled).</para></listitem>
|
||||
<listitem><para>Address lookups (reverse lookups) are routed similarly to multi-label names, with the
|
||||
exception that addresses from the link-local address range are never routed to unicast DNS and are only
|
||||
resolved using LLMNR and MulticastDNS (when enabled).</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>If lookups are routed to multiple interfaces, the first successful response is returned (thus
|
||||
effectively merging the lookup zones on all matching interfaces). If the lookup failed on all interfaces,
|
||||
the last failing response is returned.</para>
|
||||
|
||||
<para>Routing of lookups may be influenced by configuring per-interface domain names and other
|
||||
settings. See
|
||||
<para>Routing of lookups is determined by the per-interface routing domains (search and route-only) and
|
||||
global search domains. See
|
||||
<citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> and
|
||||
<citerefentry><refentrytitle>resolvectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
|
||||
details. The following query routing logic applies for unicast DNS traffic:</para>
|
||||
<citerefentry><refentrytitle>resolvectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for a
|
||||
description how those settings are set dynamically and the discussion of <varname>Domains=</varname> in
|
||||
<citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
|
||||
description of globally configured DNS settings.</para>
|
||||
|
||||
<para>The following query routing logic applies for unicast DNS traffic:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>If a name to look up matches (that is: is equal to or has as suffix) any of the
|
||||
configured search or route-only domains of any link (see
|
||||
<citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
|
||||
or the globally configured DNS settings (see the discussion of <varname>Domains=</varname> in
|
||||
<citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
|
||||
"best matching" search/route-only domain is determined: the matching one with the most labels. The
|
||||
query is then sent to all DNS servers of any links or the globally configured DNS servers associated
|
||||
with this "best matching" search/route-only domain. (Note that more than one link might have this same
|
||||
"best matching" search/route-only domain configured, in which case the query is sent to all of them in
|
||||
parallel).</para>
|
||||
configured routing domains (search or route-only) of any link, or the globally configured DNS settings,
|
||||
"best matching" routing domain is determined: the matching one with the most labels. The query is then
|
||||
sent to all DNS servers of any links or the globally configured DNS servers associated with this "best
|
||||
matching" routing domain. (Note that more than one link might have this same "best matching" routing
|
||||
domain configured, in which case the query is sent to all of them in parallel).</para>
|
||||
|
||||
<para>In case of single-label names, when search domains are defined, the same logic applies, except
|
||||
that the name is first suffixed by the search domain.</para></listitem>
|
||||
that the name is first suffixed by each of the search domains in turn.</para></listitem>
|
||||
|
||||
<listitem><para>If a query does not match any configured search/route-only domain (neither per-link nor
|
||||
global), it is sent to all DNS servers that are configured on links with the "DNS default route" option
|
||||
set, as well as the globally configured DNS server.</para></listitem>
|
||||
<listitem><para>If a query does not match any configured routing domain (either per-link or global), it
|
||||
is sent to all DNS servers that are configured on links with the <varname>DefaultRoute=</varname>
|
||||
option set, as well as the globally configured DNS server.</para></listitem>
|
||||
|
||||
<listitem><para>If there is no link configured as "DNS default route" and no global DNS server
|
||||
configured, the compiled-in fallback DNS server is used.</para></listitem>
|
||||
<listitem><para>If there is no link configured as <varname>DefaultRoute=</varname> and no global DNS
|
||||
server configured, one of the compiled-in fallback DNS servers is used.</para></listitem>
|
||||
|
||||
<listitem><para>Otherwise the query is failed as no suitable DNS servers could be determined.
|
||||
<listitem><para>Otherwise the unicast DNS query fails, as no suitable DNS servers can be determined.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>The "DNS default route" option is a boolean setting configurable with <command>resolvectl</command>
|
||||
or in <filename>.network</filename> files. If not set, it is implicitly determined based on the
|
||||
configured DNS domains for a link: if there's any route-only domain (not matching <literal>~.</literal>)
|
||||
it defaults to false, otherwise to true.</para>
|
||||
<para>The <varname>DefaultRoute=</varname> option is a boolean setting configurable with
|
||||
<command>resolvectl</command> or in <filename>.network</filename> files. If not set, it is implicitly
|
||||
determined based on the configured DNS domains for a link: if there's a route-only domain other than
|
||||
<literal>~.</literal>, it defaults to false, otherwise to true.</para>
|
||||
|
||||
<para>Effectively this means: in order to support single-label non-synthetized names, define appropriate
|
||||
search domains. In order to preferably route all DNS queries not explicitly matched by search/route-only
|
||||
domain configuration to a specific link, configure a <literal>~.</literal> route-only domain on it. This
|
||||
will ensure that other links will not be considered for these queries (unless they too carry such a
|
||||
route-only domain). In order to route all such DNS queries to a specific link only if no other link
|
||||
is preferable, set the "DNS default route" option for the link to true and do not configure a
|
||||
search domains. In order to preferably route all DNS queries not explicitly matched by routing domain
|
||||
configuration to a specific link, configure a <literal>~.</literal> route-only domain on it. This will
|
||||
ensure that other links will not be considered for these queries (unless they too carry such a routing
|
||||
domain). In order to route all such DNS queries to a specific link only if no other link is preferred,
|
||||
set the <varname>DefaultRoute=</varname> option for the link to true and do not configure a
|
||||
<literal>~.</literal> route-only domain on it. Finally, in order to ensure that a specific link never
|
||||
receives any DNS traffic not matching any of its configured search/route-only domains, set the "DNS
|
||||
default route" option for it to false.</para>
|
||||
receives any DNS traffic not matching any of its configured routing domains, set the
|
||||
<varname>DefaultRoute=</varname> option for it to false.</para>
|
||||
|
||||
<para>See
|
||||
<citerefentry><refentrytitle>org.freedesktop.resolve1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user