man/systemd-resolved.service.xml

   1 <?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
   2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
   3   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
   4
   5 <!--
   6   This file is part of systemd.
   7
   8   Copyright 2014 Tom Gundersen
   9
  10   systemd is free software; you can redistribute it and/or modify it
  11   under the terms of the GNU Lesser General Public License as published by
  12   the Free Software Foundation; either version 2.1 of the License, or
  13   (at your option) any later version.
  14
  15   systemd is distributed in the hope that it will be useful, but
  16   WITHOUT ANY WARRANTY; without even the implied warranty of
  17   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
  18   Lesser General Public License for more details.
  19
  20   You should have received a copy of the GNU Lesser General Public License
  21   along with systemd; If not, see <http://www.gnu.org/licenses/>.
  22 -->
  23
  24 <refentry id="systemd-resolved.service" conditional='ENABLE_RESOLVE'>
  25
  26   <refentryinfo>
  27     <title>systemd-resolved.service</title>
  28     <productname>systemd</productname>
  29
  30     <authorgroup>
  31       <author>
  32         <contrib>Developer</contrib>
  33         <firstname>Tom</firstname>
  34         <surname>Gundersen</surname>
  35         <email>teg@jklm.no</email>
  36       </author>
  37     </authorgroup>
  38   </refentryinfo>
  39
  40   <refmeta>
  41     <refentrytitle>systemd-resolved.service</refentrytitle>
  42     <manvolnum>8</manvolnum>
  43   </refmeta>
  44
  45   <refnamediv>
  46     <refname>systemd-resolved.service</refname>
  47     <refname>systemd-resolved</refname>
  48     <refpurpose>Network Name Resolution manager</refpurpose>
  49   </refnamediv>
  50
  51   <refsynopsisdiv>
  52     <para><filename>systemd-resolved.service</filename></para>
  53     <para><filename>/usr/lib/systemd/systemd-resolved</filename></para>
  54   </refsynopsisdiv>
  55
  56   <refsect1>
  57     <title>Description</title>
  58
  59     <para><command>systemd-resolved</command> is a system service that provides network name resolution to local
  60     applications. It implements a caching and validating DNS/DNSSEC stub resolver, as well as an LLMNR resolver and
  61     responder. Local applications may submit network name resolution requests via three interfaces:</para>
  62
  63     <itemizedlist>
  64       <listitem><para>The native, fully-featured API <command>systemd-resolved</command> exposes on the bus. See the
  65       <ulink url="https://www.freedesktop.org/wiki/Software/systemd/resolved">API Documentation</ulink> for
  66       details. Usage of this API is generally recommended to clients as it is asynchronous and fully featured (for
  67       example, properly returns DNSSEC validation status and interface scope for addresses as necessary for supporting
  68       link-local networking).</para></listitem>
  69
  70       <listitem><para>The glibc
  71       <citerefentry project='man-pages'><refentrytitle>getaddrinfo</refentrytitle><manvolnum>3</manvolnum></citerefentry> API as defined
  72       by <ulink url="https://tools.ietf.org/html/rfc3493">RFC3493</ulink> and its related resolver functions,
  73       including <citerefentry project='man-pages'><refentrytitle>gethostbyname</refentrytitle><manvolnum>3</manvolnum></citerefentry>. This
  74       API is widely supported, including beyond the Linux platform. In its current form it does not expose DNSSEC
  75       validation status information however, and is synchronous only. This API is backed by the glibc Name Service
  76       Switch (<citerefentry project='man-pages'><refentrytitle>nss</refentrytitle><manvolnum>5</manvolnum></citerefentry>). Usage of the
  77       glibc NSS module <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>
  78       is required in order to allow glibc's NSS resolver functions to resolve host names via
  79       <command>systemd-resolved</command>.</para></listitem>
  80
  81       <listitem><para>Additionally, <command>systemd-resolved</command> provides a local DNS stub listener on IP
  82       address 127.0.0.53 on the local loopback interface. Programs issuing DNS requests directly, bypassing any local
  83       API may be directed to this stub, in order to connect them to <command>systemd-resolved</command>. Note however
  84       that it is strongly recommended that local programs use the glibc NSS or bus APIs instead (as described above),
  85       as various network resolution concepts (such as link-local addressing, or LLMNR Unicode domains) cannot be mapped
  86       to the unicast DNS protocol.</para></listitem>
  87     </itemizedlist>
  88
  89     <para>The DNS servers contacted are determined from the global settings in
  90     <filename>/etc/systemd/resolved.conf</filename>, the per-link static settings in
  91     <filename>/etc/systemd/network/*.network</filename> files, the per-link dynamic settings received over DHCP and any
  92     DNS server information made available by other system services. See
  93     <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> and
  94     <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details
  95     about systemd's own configuration files for DNS servers. To improve compatibility,
  96     <filename>/etc/resolv.conf</filename> is read in order to discover configured system DNS servers, but only if it is
  97     not a symlink to <filename>/run/systemd/resolve/resolv.conf</filename> (see below).</para>
  98
  99     <para><command>systemd-resolved</command> synthesizes DNS resource records (RRs) for the following cases:</para>
 100
 101     <itemizedlist>
 102       <listitem><para>The local, configured hostname is resolved to
 103       all locally configured IP addresses ordered by their scope, or
 104       — if none are configured — the IPv4 address 127.0.0.2 (which
 105       is on the local loopback) and the IPv6 address ::1 (which is the
 106       local host).</para></listitem>
 107
 108       <listitem><para>The hostnames <literal>localhost</literal> and
 109       <literal>localhost.localdomain</literal> (as well as any hostname
 110       ending in <literal>.localhost</literal> or <literal>.localhost.localdomain</literal>)
 111       are resolved to the IP addresses 127.0.0.1 and ::1.</para></listitem>
 112
 113       <listitem><para>The hostname <literal>gateway</literal> is
 114       resolved to all current default routing gateway addresses,
 115       ordered by their metric. This assigns a stable hostname to the
 116       current gateway, useful for referencing it independently of the
 117       current network configuration state.</para></listitem>
 118
 119       <listitem><para>The mappings defined in <filename>/etc/hosts</filename> are resolved
 120       to their configured addresses and back, but they will not affect lookups for
 121       non-address types (like MX).</para></listitem>
 122     </itemizedlist>
 123
 124     <para>Lookup requests are routed to the available DNS servers
 125     and LLMNR interfaces according to the following rules:</para>
 126
 127     <itemizedlist>
 128       <listitem><para>Lookups for the special hostname
 129       <literal>localhost</literal> are never routed to the
 130       network. (A few other, special domains are handled the same way.)</para></listitem>
 131
 132       <listitem><para>Single-label names are routed to all local
 133       interfaces capable of IP multicasting, using the LLMNR
 134       protocol. Lookups for IPv4 addresses are only sent via LLMNR on
 135       IPv4, and lookups for IPv6 addresses are only sent via LLMNR on
 136       IPv6. Lookups for the locally configured host name and the
 137       <literal>gateway</literal> host name are never routed to
 138       LLMNR.</para></listitem>
 139
 140       <listitem><para>Multi-label names are routed to all local
 141       interfaces that have a DNS server configured, plus the globally
 142       configured DNS server if there is one. Address lookups from the
 143       link-local address range are never routed to
 144       DNS.</para></listitem>
 145     </itemizedlist>
 146
 147     <para>If lookups are routed to multiple interfaces, the first
 148     successful response is returned (thus effectively merging the
 149     lookup zones on all matching interfaces). If the lookup failed on
 150     all interfaces, the last failing response is returned.</para>
 151
 152     <para>Routing of lookups may be influenced by configuring
 153     per-interface domain names. See
 154     <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 155     for details. Lookups for a hostname ending in one of the
 156     per-interface domains are exclusively routed to the matching
 157     interfaces.</para>
 158
 159     <para>See the <ulink url="https://www.freedesktop.org/wiki/Software/systemd/resolved"> resolved D-Bus API
 160     Documentation</ulink> for information about the APIs <filename>systemd-resolved</filename> provides.</para>
 161
 162   </refsect1>
 163
 164   <refsect1>
 165     <title><filename>/etc/resolv.conf</filename></title>
 166
 167     <para>Three modes of handling <filename>/etc/resolv.conf</filename> (see
 168     <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>) are
 169     supported:</para>
 170
 171     <itemizedlist>
 172       <listitem><para>A static file <filename>/usr/lib/systemd/resolv.conf</filename> is provided that lists
 173       the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from
 174       <filename>/etc/resolv.conf</filename> in order to connect all local clients that bypass local DNS APIs to
 175       <command>systemd-resolved</command>. This mode of operation is recommended.</para></listitem>
 176
 177       <listitem><para><command>systemd-resolved</command> maintains the
 178       <filename>/run/systemd/resolve/resolv.conf</filename> file for compatibility with traditional Linux
 179       programs. This file may be symlinked from <filename>/etc/resolv.conf</filename> and is always kept up-to-date,
 180       containing information about all known DNS servers. Note the file format's limitations: it does not know a
 181       concept of per-interface DNS servers and hence only contains system-wide DNS server definitions. Note that
 182       <filename>/run/systemd/resolve/resolv.conf</filename> should not be used directly by applications, but only
 183       through a symlink from <filename>/etc/resolv.conf</filename>. If this mode of operation is used local clients
 184       that bypass any local DNS API will also bypass <command>systemd-resolved</command> and will talk directly to the
 185       known DNS servers.</para> </listitem>
 186
 187       <listitem><para>Alternatively, <filename>/etc/resolv.conf</filename> may be managed by other packages, in which
 188       case <command>systemd-resolved</command> will read it for DNS configuration data. In this mode of operation
 189       <command>systemd-resolved</command> is consumer rather than provider of this configuration
 190       file. </para></listitem>
 191     </itemizedlist>
 192
 193     <para>Note that the selected mode of operation for this file is detected fully automatically, depending on whether
 194     <filename>/etc/resolv.conf</filename> is a symlink to <filename>/run/systemd/resolve/resolv.conf</filename> or
 195     lists 127.0.0.53 as DNS server.</para>
 196   </refsect1>
 197
 198   <refsect1>
 199     <title>Signals</title>
 200
 201     <variablelist>
 202       <varlistentry>
 203         <term><constant>SIGUSR1</constant></term>
 204
 205         <listitem><para>Upon reception of the SIGUSR1 process signal <command>systemd-resolved</command> will dump the
 206         contents of all DNS resource record caches it maintains into the system logs.</para></listitem>
 207       </varlistentry>
 208
 209       <varlistentry>
 210         <term><constant>SIGUSR2</constant></term>
 211
 212         <listitem><para>Upon reception of the SIGUSR2 process signal <command>systemd-resolved</command> will flush all
 213         caches it maintains. Note that it should normally not be necessary to request this explicitly – except for
 214         debugging purposes – as <command>systemd-resolved</command> flushes the caches automatically anyway any time
 215         the host's network configuration changes.</para></listitem>
 216       </varlistentry>
 217     </variablelist>
 218   </refsect1>
 219
 220   <refsect1>
 221     <title>See Also</title>
 222     <para>
 223       <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 224       <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 225       <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 226       <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
 227       <citerefentry><refentrytitle>systemd-resolve</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 228       <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 229       <citerefentry project='man-pages'><refentrytitle>hosts</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 230       <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 231       <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
 232     </para>
 233   </refsect1>
 234
 235 </refentry>