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_RESOLVED'>
  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="http://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><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><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><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 to their configured
 120       addresses and back.</para></listitem>
 121     </itemizedlist>
 122
 123     <para>Lookup requests are routed to the available DNS servers
 124     and LLMNR interfaces according to the following rules:</para>
 125
 126     <itemizedlist>
 127       <listitem><para>Lookups for the special hostname
 128       <literal>localhost</literal> are never routed to the
 129       network. (A few other, special domains are handled the same way.)</para></listitem>
 130
 131       <listitem><para>Single-label names are routed to all local
 132       interfaces capable of IP multicasting, using the LLMNR
 133       protocol. Lookups for IPv4 addresses are only sent via LLMNR on
 134       IPv4, and lookups for IPv6 addresses are only sent via LLMNR on
 135       IPv6. Lookups for the locally configured host name and the
 136       <literal>gateway</literal> host name are never routed to
 137       LLMNR.</para></listitem>
 138
 139       <listitem><para>Multi-label names are routed to all local
 140       interfaces that have a DNS sever configured, plus the globally
 141       configured DNS server if there is one. Address lookups from the
 142       link-local address range are never routed to
 143       DNS.</para></listitem>
 144     </itemizedlist>
 145
 146     <para>If lookups are routed to multiple interfaces, the first
 147     successful response is returned (thus effectively merging the
 148     lookup zones on all matching interfaces). If the lookup failed on
 149     all interfaces, the last failing response is returned.</para>
 150
 151     <para>Routing of lookups may be influenced by configuring
 152     per-interface domain names. See
 153     <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 154     for details. Lookups for a hostname ending in one of the
 155     per-interface domains are exclusively routed to the matching
 156     interfaces.</para>
 157
 158     <para>See the <ulink url="http://www.freedesktop.org/wiki/Software/systemd/resolved"> resolved D-Bus API
 159     Documentation</ulink> for information about the APIs <filename>systemd-resolved</filename> provides.</para>
 160
 161   </refsect1>
 162
 163   <refsect1>
 164     <title><filename>/etc/resolv.conf</filename></title>
 165
 166     <para>Three modes of handling <filename>/etc/resolv.conf</filename> (see
 167     <citerefentry><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>) are
 168     supported:</para>
 169
 170     <itemizedlist>
 171       <listitem><para>A static file <filename>/usr/lib/systemd/resolv.conf</filename> is provided that lists
 172       the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from
 173       <filename>/etc/resolv.conf</filename> in order to connect all local clients that bypass local DNS APIs to
 174       <command>systemd-resolved</command>. This mode of operation is recommended.</para></listitem>
 175
 176       <listitem><para><command>systemd-resolved</command> maintains the
 177       <filename>/run/systemd/resolve/resolv.conf</filename> file for compatibility with traditional Linux
 178       programs. This file may be symlinked from <filename>/etc/resolv.conf</filename> and is always kept up-to-date,
 179       containing information about all known DNS servers. Note the file format's limitations: it does not know a
 180       concept of per-interface DNS servers and hence only contains system-wide DNS server definitions. Note that
 181       <filename>/run/systemd/resolve/resolv.conf</filename> should not be used directly by applications, but only
 182       through a symlink from <filename>/etc/resolv.conf</filename>. If this mode of operation is used local clients
 183       that bypass any local DNS API will also bypass <command>systemd-resolved</command> and will talk directly to the
 184       known DNS servers.</para> </listitem>
 185
 186       <listitem><para>Alternatively, <filename>/etc/resolv.conf</filename> may be managed by other packages, in which
 187       case <command>systemd-resolved</command> will read it for DNS configuration data. In this mode of operation
 188       <command>systemd-resolved</command> is consumer rather than provider of this configuration
 189       file. </para></listitem>
 190     </itemizedlist>
 191
 192     <para>Note that the selected mode of operation for this file is detected fully automatically, depending on whether
 193     <filename>/etc/resolv.conf</filename> is a symlink to <filename>/run/systemd/resolve/resolv.conf</filename> or
 194     lists 127.0.0.53 as DNS server.</para>
 195   </refsect1>
 196
 197   <refsect1>
 198     <title>Signals</title>
 199
 200     <variablelist>
 201       <varlistentry>
 202         <term><constant>SIGUSR1</constant></term>
 203
 204         <listitem><para>Upon reception of the SIGUSR1 process signal <command>systemd-resolved</command> will dump the
 205         contents of all DNS resource record caches it maintains into the system logs.</para></listitem>
 206       </varlistentry>
 207
 208       <varlistentry>
 209         <term><constant>SIGUSR2</constant></term>
 210
 211         <listitem><para>Upon reception of the SIGUSR2 process signal <command>systemd-resolved</command> will flush all
 212         caches it maintains. Note that it should normally not be necessary to request this explicitly – except for
 213         debugging purposes – as <command>systemd-resolved</command> flushes the caches automatically anyway any time
 214         the host's network configuration changes.</para></listitem>
 215       </varlistentry>
 216     </variablelist>
 217   </refsect1>
 218
 219   <refsect1>
 220     <title>See Also</title>
 221     <para>
 222       <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 223       <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 224       <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 225       <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
 226       <citerefentry><refentrytitle>systemd-resolve</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
 227       <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 228       <citerefentry project='man-pages'><refentrytitle>hosts</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 229       <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 230       <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
 231     </para>
 232   </refsect1>
 233
 234 </refentry>