<?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">

<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 a response for a lookup request is detected invalid

this is returned as lookup failure 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 in 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>

</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>