From 141a60f3a84f35dc20c482f86271301a3b934647 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20K=C4=99pie=C5=84?= Date: Wed, 6 Feb 2019 12:46:10 +0100 Subject: [PATCH 1/2] Extend and refine mirror zone documentation Add a warning about potential performance implications of configuring a non-root zone as a mirror zone. Explain in more detail how each mirror zone version is validated and how validation failures are handled. Move the paragraphs describing how to set up IANA root zone mirroring higher up, so that they can be more easily found by the reader. Explicitly state that the "masters" option needs to be present for any mirror zone which is not the root zone. Tweak the description of the interaction between the "dnssec-validation" setting and root zone mirroring to make it less ambiguous. Specify what the default "notify" setting is for mirror zones. --- doc/arm/Bv9ARM-book.xml | 193 +++++++++++++++++++++++---------------- doc/arm/Bv9ARM.ch05.html | 120 +++++++++++++++--------- 2 files changed, 194 insertions(+), 119 deletions(-) diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 25df01340dd..0096850ba24 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -6389,8 +6389,8 @@ options { - - dnssec-validation + + dnssec-validation This enables DNSSEC validation in named. @@ -11291,86 +11291,125 @@ view "external" { - - - A mirror zone acts like a zone of type - secondary whose data is - subject to DNSSEC validation before being used - in answers. Validation is performed during the - zone transfer process, and again when the zone - file is loaded from disk when - named 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. - - - For validation to succeed, a key-signing key - (KSK) for the zone must be configured as a trust - anchor in named.conf: that - is, a key for the zone must either be specified - in managed-keys or - trusted-keys, or in the case - of the root zone, - dnssec-validation must be set - to auto. Answers coming - from a mirror zone look almost exactly like - answers from a zone of type - secondary, with the - notable exceptions that the AA bit - ("authoritative answer") is not set, and the AD - bit ("authenticated data") is. - - - Since mirror zones are intended to be used by - recursive resolvers, adding one to a view with - recursion disabled is considered to be a - configuration error. - - - When configuring NOTIFY for a mirror zone, only - notify no; and - notify explicit; can be - used. Using any other - notify setting at the - zone level is a configuration error. Using any - other notify setting at - the options or - view level will cause - that setting to be overridden with - notify explicit; for the - mirror zone in question. - - - Outgoing transfers of mirror zones are disabled - by default but may be enabled using - . - - - While any zone may be configured with this type, - it is intended to be used to set up a fast local - copy of the root zone, similar to the one - described in RFC 7706. Note, however, that - mirror zones are not supposed to augment the - example configuration provided by RFC 7706 but - rather to replace it altogether. - - - A default list of primary servers for the root - zone is built into named and - thus IANA root zone mirroring can be enabled - using the following configuration: + Note: using + this zone type with any zone other than the root + zone should be considered + experimental and may cause + performance issues, especially for zones which + are large and/or frequently updated. + + + A mirror zone acts like a zone of type + secondary whose data is + subject to DNSSEC validation before being used + in answers. Validation is performed during the + zone transfer process (for both AXFR and IXFR), + and again when the zone file is loaded from disk + when named is restarted. If + validation of a new version of a mirror zone + fails, a retransfer is scheduled and the most + recent correctly validated version of that zone + is used until it expires; if a newer version of + that zone is later correctly validated, it + replaces the previously used version. If no + usable zone data is available for a mirror zone + (either because it was never loaded from disk + and has not yet been transferred from a primary + server or because its most recent correctly + validated version expired), traditional DNS + recursion will be used to look up the answers + instead. + + + While any zone may be configured with this type, + it is intended to be used to set up a fast local + copy of the root zone, similar to the one + described in RFC 7706. Note, however, that + mirror zones are not supposed to augment the + example configuration provided by RFC 7706 but + rather to replace it altogether. + + + A default list of primary servers for the IANA + root zone is built into named + and thus its mirroring can be enabled using the + following configuration: zone "." { type mirror; }; - To make mirror zone contents persist between - named restarts, use the - - option. + In order to set up mirroring of any other zone, + an explicit list of primary servers needs to be + provided using the masters + option (see + for details). + + + To make mirror zone contents persist between + named restarts, use the + + option. + + + Mirror zone validation always happens for the + entire zone contents, i.e. no "incremental + validation" takes place, even for IXFRs. This + is required to ensure that each version of the + zone used by the resolver is fully + self-consistent with respect to DNSSEC. Other, + more efficient zone verification methods may be + added in the future. + + + For validation to succeed, a key-signing key + (KSK) for the zone must be configured as a trust + anchor in named.conf: that + is, a key for the zone must either be specified + in managed-keys or + trusted-keys. In the case + of the root zone, you may also rely on the + built-in root trust anchor, which is enabled + when is set to the + default value auto. + + + Answers coming from a mirror zone look almost + exactly like answers from a zone of type + secondary, with the + notable exceptions that the AA bit + ("authoritative answer") is not set, and the AD + bit ("authenticated data") is. + + + Since mirror zones are intended to be used by + recursive resolvers, adding one to a view with + recursion disabled is considered to be a + configuration error. + + + When configuring NOTIFY for a mirror zone, only + notify no; and + notify explicit; can be + used. Using any other notify + setting at the zone level is a configuration + error. Using any other + notify setting at the + options or + view level will cause + that setting to be overridden with + notify explicit; for the + mirror zone in question. Since the global + default for the notify option + is yes, mirror zones are + by default configured with + notify explicit;. + + + Outgoing transfers of mirror zones are disabled + by default but may be enabled using + . diff --git a/doc/arm/Bv9ARM.ch05.html b/doc/arm/Bv9ARM.ch05.html index 582f928139a..6ef43626f8e 100644 --- a/doc/arm/Bv9ARM.ch05.html +++ b/doc/arm/Bv9ARM.ch05.html @@ -9695,20 +9695,75 @@ view "external" {

+ Note: using + this zone type with any zone other than the root + zone should be considered + experimental and may cause + performance issues, especially for zones which + are large and/or frequently updated.

A mirror zone acts like a zone of type secondary whose data is subject to DNSSEC validation before being used in answers. Validation is performed during the - zone transfer process, and again when the zone - file is loaded from disk when - named 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. + zone transfer process (for both AXFR and IXFR), + and again when the zone file is loaded from disk + when named is restarted. If + validation of a new version of a mirror zone + fails, a retransfer is scheduled and the most + recent correctly validated version of that zone + is used until it expires; if a newer version of + that zone is later correctly validated, it + replaces the previously used version. If no + usable zone data is available for a mirror zone + (either because it was never loaded from disk + and has not yet been transferred from a primary + server or because its most recent correctly + validated version expired), traditional DNS + recursion will be used to look up the answers + instead. +

+

+ While any zone may be configured with this type, + it is intended to be used to set up a fast local + copy of the root zone, similar to the one + described in RFC 7706. Note, however, that + mirror zones are not supposed to augment the + example configuration provided by RFC 7706 but + rather to replace it altogether. +

+

+ A default list of primary servers for the IANA + root zone is built into named + and thus its mirroring can be enabled using the + following configuration: +

+
zone "." {
+        type mirror;
+};
+

+ In order to set up mirroring of any other zone, + an explicit list of primary servers needs to be + provided using the masters + option (see the section called “masters Statement Grammar” + for details). +

+

+ To make mirror zone contents persist between + named restarts, use the + file + option. +

+

+ Mirror zone validation always happens for the + entire zone contents, i.e. no "incremental + validation" takes place, even for IXFRs. This + is required to ensure that each version of the + zone used by the resolver is fully + self-consistent with respect to DNSSEC. Other, + more efficient zone verification methods may be + added in the future.

For validation to succeed, a key-signing key @@ -9716,9 +9771,10 @@ view "external" { anchor in named.conf: that is, a key for the zone must either be specified in managed-keys or - trusted-keys, or in the case - of the root zone, - dnssec-validation must be set + trusted-keys. In the case + of the root zone, you may also rely on the + built-in root trust anchor, which can be enabled + by setting dnssec-validation to auto. Answers coming from a mirror zone look almost exactly like answers from a zone of type @@ -9737,45 +9793,25 @@ view "external" { When configuring NOTIFY for a mirror zone, only notify no; and notify explicit; can be - used. Using any other - notify setting at the - zone level is a configuration error. Using any - other notify setting at - the options or - view level will cause + used. Using any other notify + setting at the zone level is a configuration + error. Using any other + notify setting at the + options or + view level will cause that setting to be overridden with notify explicit; for the - mirror zone in question. + mirror zone in question. Since the global + default for the notify option + is yes, mirror zones are + by default configured with + notify explicit;.

Outgoing transfers of mirror zones are disabled by default but may be enabled using allow-transfer.

-

- While any zone may be configured with this type, - it is intended to be used to set up a fast local - copy of the root zone, similar to the one - described in RFC 7706. Note, however, that - mirror zones are not supposed to augment the - example configuration provided by RFC 7706 but - rather to replace it altogether. -

-

- A default list of primary servers for the root - zone is built into named and - thus IANA root zone mirroring can be enabled - using the following configuration: -

-
zone "." {
-        type mirror;
-};
-

- To make mirror zone contents persist between - named restarts, use the - file - option. -

-- GitLab From c33e1c98db941af7230445f04d4cd2b88d43d4dd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C5=82=20K=C4=99pie=C5=84?= Date: Wed, 6 Feb 2019 12:46:10 +0100 Subject: [PATCH 2/2] Add CHANGES entry 5156. [doc] Extended and refined the section of the ARM describing mirror zones. [GL #774] --- CHANGES | 3 +++ 1 file changed, 3 insertions(+) diff --git a/CHANGES b/CHANGES index 91c9942b296..bd627ce1c49 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +5156. [doc] Extended and refined the section of the ARM describing + mirror zones. [GL #774] + 5155. [func] "named -V" now outputs the default paths to named.conf, rndc.conf, bind.keys, and other files used or created by named and other tools, so -- GitLab