diff --git a/CHANGES b/CHANGES index 91c9942b296ace0549cb4daa6c7e14d78fb43c01..bd627ce1c4947c1c193b61ee0444d1e1fd210631 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 diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 25df01340dd6776bfe7737aa43722610382eee99..0096850ba242a3f4241121c801d8a872729b8ca1 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 582f928139a7e85b47747165639c54b64da5aa15..6ef43626f8e89630098084b8683cb3cb1f3305e9 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. -