summaryrefslogtreecommitdiff
path: root/man
diff options
context:
space:
mode:
authorLennart Poettering <lennart@poettering.net>2016-01-05 00:31:32 +0100
committerLennart Poettering <lennart@poettering.net>2016-01-05 00:31:32 +0100
commit519d39deeeec7121649f28e7287b7790e50d2979 (patch)
tree3bed67a014ac470e84845e815d1469ce719ec325 /man
parent6f8a2c6817e35ca3e76130b31624f7f30e596433 (diff)
man: add basic documentation for resolved.conf's DNSSEC= switch
Diffstat (limited to 'man')
-rw-r--r--man/resolved.conf.xml55
1 files changed, 55 insertions, 0 deletions
diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml
index 4680b6a4e5..857a93b653 100644
--- a/man/resolved.conf.xml
+++ b/man/resolved.conf.xml
@@ -124,6 +124,61 @@
global setting is on.</para></listitem>
</varlistentry>
+ <varlistentry>
+ <term><varname>DNSSEC=</varname></term>
+ <listitem><para>Takes a boolean argument or
+ <literal>downgrade-ok</literal>. If true all DNS lookups are
+ DNSSEC-validated locally. 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>downgrade-ok</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. However, 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>downgrade-ok</literal> the resolver will
+ automatically turn of 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 kown 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>missing-ok</literal>.</para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</refsect1>