summaryrefslogtreecommitdiff
path: root/man/resolved.conf.xml
diff options
context:
space:
mode:
Diffstat (limited to 'man/resolved.conf.xml')
-rw-r--r--man/resolved.conf.xml93
1 files changed, 93 insertions, 0 deletions
diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml
index 4680b6a4e5..5da2d5488e 100644
--- a/man/resolved.conf.xml
+++ b/man/resolved.conf.xml
@@ -124,6 +124,98 @@
global setting is on.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>MulticastDNS=</varname></term>
+ <listitem><para>Takes a boolean argument or
+ <literal>resolve</literal>. Controls Multicast DNS support
+ (<ulink url="https://tools.ietf.org/html/rfc6762">RFC
+ 6762</ulink>) on the local host. If true, enables full
+ Multicast DNS 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-interface Multicast DNS settings. Multicast
+ DNS will be enabled on an interface only if the per-interface
+ 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-interface DNSSEC settings. For system DNS
+ servers (see above), only the global DNSSEC setting is in
+ effect. For per-interface DNS servers the per-interface
+ 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>
@@ -133,6 +225,7 @@
<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><refentrytitle>resolv.conf</refentrytitle><manvolnum>4</manvolnum></citerefentry>
</para>
</refsect1>