upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-04-22 23:01:43 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

clarify documentation of the 'mirror' option

Browse source
This commit is contained in:
Evan Hunt 2018-07-02 23:07:38 -07:00 committed by Michał Kępień
parent 51161526a4
commit 3245eb98f4
2 changed files with 40 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

46
doc/arm/Bv9ARM-book.xml
View file

@ -12459,19 +12459,41 @@ example.com. NS ns2.example.net.
<term><command>mirror</command></term>
<listitem>
<para>
If set to <userinput>yes</userinput>, causes the
If set to <userinput>yes</userinput>, this causes the
zone to become a mirror zone. A mirror zone is a
<userinput>slave</userinput> zone whose every
version is subject to DNSSEC validation before being
used. In order for zone validation to succeed, its
KSK must be configured as a trust anchor. Answers
coming from a mirror zone look almost exactly like
answers from a regular <userinput>slave</userinput>
zone, with the notable exception of the AA bit not
being set. The default is <userinput>no</userinput>.
This option is meant to be used for deploying an RFC
7706-style local copy of the root zone, e.g. using a
configuration like this:
<userinput>secondary</userinput> zone whose data
is subject to DNSSEC validation before being
used in answers. The default is
<userinput>no</userinput>.
</para>
<para>
A mirror zone's contents are validated during the transfer
process, and again when the zone file is loaded from disk
when <command>named</command> is restarted. If validation
fails, a retransfer of the zone is scheduled; if the mirror
zone had not previously been loaded or if the previous
version has expired, traditional DNS recursion will be used
to look up the answers instead.
</para>
<para>
For validation to succeed, a key-signing key (KSK) for
the zone must be configured as a trust anchor in
<filename>named.conf</filename>:
that is, a key for the zone must either be specified in
<command>managed-keys</command> or
<command>trusted-keys</command>, or in the case of
the root zone, <command>dnssec-validation</command>
must be set to <userinput>auto</userinput>.
Answers coming from a mirror zone look almost exactly like
answers from a normal slave zone, with the notable
exceptions that the AA bit ("authoritative answer") is
not set, and the AD bit ("authenticated data") is.
</para>
<para>
Though this option can be used for other zones, it
is intended to be used to set up a fast local copy of
the root zone, as described in RFC 7706.
This can be done by using the following configuration:
</para>
<programlisting>zone "." {
type slave;

11
doc/arm/notes.xml
View file

@ -82,11 +82,12 @@
A new secondary zone option, <command>mirror</command>,
enables <command>named</command> to serve a transferred copy
of a zone's contents without acting as an authority for the
zone. DNS responses from mirror zones do not set the AA
("authoritative answer") bit, and are subject to DNSSEC
validation. This is meant to facilitate deployment
of a local copy of the root zone as described in RFC 7706.
[GL #33]
zone. A zone must be fully validated against an active trust
anchor before it can be used as a mirror zone. DNS responses
from mirror zones do not set the AA bit ("authoritative answer"),
but do set the AD bit ("authenticated data"). This feature is
meant to facilitate deployment of a local copy of the root zone,
as described in RFC 7706. [GL #33]
</para>
</listitem>
<listitem>