From ff5760e233f6ab75e33783b6dd48f961ce04d933 Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Mon, 30 Jul 2001 22:55:27 +0000 Subject: [PATCH] random reformatting --- doc/arm/Bv9ARM-book.xml | 96 +++++++++++++++++++++------------------- doc/arm/Bv9ARM.ch03.html | 52 +++++++++++----------- doc/arm/Bv9ARM.ch04.html | 11 ++--- doc/arm/Bv9ARM.ch06.html | 4 +- 4 files changed, 85 insertions(+), 78 deletions(-) diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 12bde7d926..b80966f61e 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ - + BIND 9 Administrator Reference Manual @@ -798,37 +798,37 @@ of a server. - In BIND 9.2, rndc - supports all the commands of the BIND 8 ndc - utility except ndc start, which was also - not supported in ndc's channel mode. - - A configuration file is required, since all - communication with the server is authenticated with - digital signatures that rely on a shared secret, and - there is no way to provide that secret other than with a - configuration file. The default location for the - rndc configuration file is - /etc/rndc.conf, but an alternate - location can be specified with the - option. If the configuration file is not found, - rndc will also look in - /var/run/named.key (or wherever - localstatedir was defined when - the BIND build was configured). - The named.key file is generated by - named as described in - . - - The format of the configuration file is similar to - that of named.conf, but limited to - only four statements, the options, - key, server and - include - statements. These statements are what associate the - secret keys to the servers with which they are meant to - be shared. The order of statements is not - significant. +In BIND 9.2, rndc +supports all the commands of the BIND 8 ndc +utility except ndc start, which was also +not supported in ndc's channel mode. + +A configuration file is required, since all +communication with the server is authenticated with +digital signatures that rely on a shared secret, and +there is no way to provide that secret other than with a +configuration file. The default location for the +rndc configuration file is +/etc/rndc.conf, but an alternate +location can be specified with the +option. If the configuration file is not found, +rndc will also look in +/var/run/named.key (or wherever +localstatedir was defined when +the BIND build was configured). +The named.key file is generated by +named as described in +. + +The format of the configuration file is similar to +that of named.conf, but limited to +only four statements, the options, +key, server and +include +statements. These statements are what associate the +secret keys to the servers with which they are meant to +be shared. The order of statements is not +significant. The options statement has three clauses: default-server, default-key, @@ -878,11 +878,13 @@ options { This file, if installed as /etc/rndc.conf, would allow the command: - $ rndc reload + +$ rndc reload + to connect to 127.0.0.1 port 953 and cause the nameserver to reload, if a nameserver on the local machine were running with following controls statements: - + controls { inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; @@ -895,8 +897,9 @@ controls { - - Signals + + +Signals Certain UNIX signals cause the name server to take specific actions, as described in the following table. These signals can be sent using the kill command. @@ -1529,18 +1532,21 @@ allow-update { key host1-host2. ;}; input file for the zone. - Configuring Servers - Unlike in BIND 8, data is not verified on load in BIND 9, - so zone keys for authoritative zones do not need to be specified - in the configuration file. +Configuring Servers - The public key for any security root must be present in - the configuration file's trusted-keys - statement, as described later in this document. +Unlike in BIND 8, +data is not verified on load in BIND 9, +so zone keys for authoritative zones do not need to be specified +in the configuration file. - - +The public key for any security root must be present in +the configuration file's trusted-keys +statement, as described later in this document. + + + + IPv6 Support in <acronym>BIND</acronym> 9 diff --git a/doc/arm/Bv9ARM.ch03.html b/doc/arm/Bv9ARM.ch03.html index 85d9b08a84..d380f7648c 100644 --- a/doc/arm/Bv9ARM.ch03.html +++ b/doc/arm/Bv9ARM.ch03.html @@ -1096,90 +1096,90 @@ CLASS="acronym" CLASS="command" >rndc - supports all the commands of the BIND 8 ndc - utility except ndc start, which was also - not supported in ndc's channel mode.

A configuration file is required, since all - communication with the server is authenticated with - digital signatures that rely on a shared secret, and - there is no way to provide that secret other than with a - configuration file. The default location for the - rndc configuration file is - /etc/rndc.conf, but an alternate - location can be specified with the -c - option. If the configuration file is not found, - rndc will also look in - /var/run/named.key (or wherever - localstatedir was defined when - the BIND build was configured). - The named.key file is generated by - named as described in - Section 6.2.4.

The format of the configuration file is similar to - that of named.conf, but limited to - only four statements, the options, - key, server and - include - statements. These statements are what associate the - secret keys to the servers with which they are meant to - be shared. The order of statements is not - significant.

The Unlike in BIND 8, data is not verified on load in 8, +data is not verified on load in BIND 9, - so zone keys for authoritative zones do not need to be specified - in the configuration file.

The public key for any security root must be present in - the configuration file's trusted-keys - statement, as described later in this document.

match-recursive-only, which means that only recursive -queries from matching clients will match that view. +requests from matching clients will match that view. The order of the view statements is significant — -a client query will be resolved in the context of the first +a client request will be resolved in the context of the first view