diff options
Diffstat (limited to 'man/resolved.conf.xml')
-rw-r--r-- | man/resolved.conf.xml | 242 |
1 files changed, 0 insertions, 242 deletions
diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml deleted file mode 100644 index 4fc1ef1b33..0000000000 --- a/man/resolved.conf.xml +++ /dev/null @@ -1,242 +0,0 @@ -<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*--> -<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" - "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<!-- - This file is part of systemd. - - Copyright 2014 Tom Gundersen - - systemd is free software; you can redistribute it and/or modify it - under the terms of the GNU Lesser General Public License as published by - the Free Software Foundation; either version 2.1 of the License, or - (at your option) any later version. - - systemd is distributed in the hope that it will be useful, but - WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - Lesser General Public License for more details. - - You should have received a copy of the GNU Lesser General Public License - along with systemd; If not, see <http://www.gnu.org/licenses/>. ---> - -<refentry id="resolved.conf" conditional='ENABLE_RESOLVED' - xmlns:xi="http://www.w3.org/2001/XInclude"> - <refentryinfo> - <title>resolved.conf</title> - <productname>systemd</productname> - - <authorgroup> - <author> - <contrib>Developer</contrib> - <firstname>Tom</firstname> - <surname>Gundersen</surname> - <email>teg@jklm.no</email> - </author> - </authorgroup> - </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> - <para><filename>/etc/systemd/resolved.conf</filename></para> - <para><filename>/etc/systemd/resolved.conf.d/*.conf</filename></para> - <para><filename>/run/systemd/resolved.conf.d/*.conf</filename></para> - <para><filename>/usr/lib/systemd/resolved.conf.d/*.conf</filename></para> - </refsynopsisdiv> - - <refsect1> - <title>Description</title> - - <para>These configuration files control local DNS and LLMNR - name resolution.</para> - - </refsect1> - - <xi:include href="standard-conf.xml" xpointer="main-conf" /> - - <refsect1> - <title>Options</title> - - <para>The following options are available in the <literal>[Resolve]</literal> section:</para> - - <variablelist class='network-directives'> - - <varlistentry> - <term><varname>DNS=</varname></term> - <listitem><para>A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers. DNS requests - are sent to one of the listed DNS servers in parallel to suitable per-link DNS servers acquired from - <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> - </varlistentry> - - <varlistentry> - <term><varname>FallbackDNS=</varname></term> - <listitem><para>A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Any - per-link DNS servers obtained from - <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> - 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> - </varlistentry> - - <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> - </varlistentry> - - <varlistentry> - <term><varname>LLMNR=</varname></term> - <listitem><para>Takes a boolean argument or - <literal>resolve</literal>. Controls Link-Local Multicast Name - Resolution support (<ulink - url="https://tools.ietf.org/html/rfc4795">RFC 4794</ulink>) on - the local host. If true, enables full LLMNR 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 LLMNR settings. LLMNR will be - enabled on a link only if the per-link and the - global setting is on.</para></listitem> - </varlistentry> - - <varlistentry> - <term><varname>DNSSEC=</varname></term> - <listitem><para>Takes a boolean argument or - <literal>allow-downgrade</literal>. If true all DNS lookups are - DNSSEC-validated locally (excluding LLMNR and Multicast - DNS). If the response to a lookup request is detected to be invalid - a lookup failure is returned to applications. Note that - this mode requires a DNS server that supports DNSSEC. If the - DNS server does not properly support DNSSEC all validations - will fail. If set to <literal>allow-downgrade</literal> DNSSEC - 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> - - <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 - is built into the resolver, additional trust anchors may be - defined with - <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>. - Trust anchors may change at regular intervals, and old trust - 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 - <varname>DNSSEC=</varname> is set to - <literal>allow-downgrade</literal> the resolver will - automatically turn off DNSSEC validation in such a case.</para> - - <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 - true on systems where it is known that the DNS server supports - DNSSEC correctly, and where software or trust anchor updates - happen regularly. On other systems it is recommended to set - <varname>DNSSEC=</varname> to - <literal>allow-downgrade</literal>.</para> - - <para>In addition to this global DNSSEC setting - <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> - also maintains per-link DNSSEC settings. For system DNS - servers (see above), only the global DNSSEC 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> - - <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> - - <para>Defaults to off.</para> - </listitem> - </varlistentry> - - <varlistentry> - <term><varname>Cache=</varname></term> - <listitem><para>Takes a boolean argument. If "yes" (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> - - <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> - - <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 - 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 - 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> - - </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>, - <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, - <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>4</manvolnum></citerefentry> - </para> - </refsect1> - -</refentry> |