diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 8c65b41846..d2e9cb8f07 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -11638,65 +11638,58 @@ view "external" { - + - master + primary The server has a master copy of the data for the zone and will be able to provide authoritative - answers for it. Type primary is - a synonym for master. + answers for it. Type master is + a synonym for primary. - slave + secondary - A slave zone is a replica of a master - zone. Type secondary is a - synonym for slave. + A secondary zone is a replica of a master + zone. Type slave is a + synonym for secondary. The masters list specifies one or more IP addresses of master servers that the slave contacts to update - its copy of the zone. - Masters list elements can also be names of other - masters lists. - By default, transfers are made from port 53 on the - servers; this can - be changed for all servers by specifying a port number - before the - list of IP addresses, or on a per-server basis after - the IP address. + its copy of the zone. Masters list elements can + also be names of other masters lists. By default, + transfers are made from port 53 on the servers; + this can be changed for all servers by specifying + a port number before the list of IP addresses, + or on a per-server basis after the IP address. Authentication to the master can also be done with - per-server TSIG keys. - If a file is specified, then the + per-server TSIG keys. If a file is specified, then the replica will be written to this file whenever the zone - is changed, - and reloaded from this file on a server restart. Use - of a file is - recommended, since it often speeds server startup and - eliminates - a needless waste of bandwidth. Note that for large - numbers (in the - tens or hundreds of thousands) of zones per server, it - is best to - use a two-level naming scheme for zone filenames. For - example, - a slave server for the zone example.com might place + is changed, and reloaded from this file on a server + restart. Use of a file is recommended, since it + often speeds server startup and eliminates a + needless waste of bandwidth. Note that for large + numbers (in the tens or hundreds of thousands) of + zones per server, it is best to use a two-level + naming scheme for zone filenames. For example, + a slave server for the zone + example.com might place the zone contents into a file called - ex/example.com where ex/ is - just the first two letters of the zone name. (Most - operating systems + ex/example.com where + ex/ is just the first two + letters of the zone name. (Most operating systems behave very slowly if you put 100000 files into a single directory.) @@ -11768,87 +11761,23 @@ 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 (for both AXFR and IXFR), - and again when the zone file is loaded from disk - when named is restarted. If + A mirror zone is similar to a zone of type + secondary, except its data + is subject to DNSSEC validation before being used + in answers. Validation is applied to the entire + zone during the zone transfer process, 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 - 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 be specified in - trust-anchors. 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. + is used until it either expires or a newer version + validates correctly. If no usable zone data is + available for a mirror zone at all, either due to + transfer failure or expiration, traditional DNS + recursion is used to look up the answers instead. + Mirror zones cannot be used in a view that does + not have recursion enabled. Answers coming from a mirror zone look almost @@ -11859,33 +11788,57 @@ view "external" { 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. + Mirror zones are intended to be used to set up a + fast local copy of the root zone, similar to the + one described in RFC 7706. 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; +}; + + Other zones can be configured as mirror zones, + but this should be considered + experimental and may cause + performance issues, especially with zones that + are large and/or frequently updated. + Mirroring a zone other than root requires an + explicit list of primary servers to be provided + using the masters option + (see + for details), and a key-signing key (KSK) + for the specified zone to be explicitly + configured as a trust anchor. + + + To make mirror zone contents persist between + named restarts, use the + + option. 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 + used at the zone level. 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 + mirror zone. The global default for the + notify option is + yes, so mirror + zones are by default configured with notify explicit;. Outgoing transfers of mirror zones are disabled by default but may be enabled using - . + .