From c0fe24753fceb4186417cfa34fa838560d733fbb Mon Sep 17 00:00:00 2001 From: "Jeremy C. Reed" Date: Thu, 12 Jul 2012 20:21:07 -0500 Subject: [PATCH] [master] many guide cleanups changed or added some docbook formatting tags slight grammar or punctuation changes some clarifications or rewording; minor explanations. removed some superfluous content or examples or simplified. This was not reviewed. --- doc/guide/bind10-guide.xml | 99 +++++++++++++++++++++----------------- 1 file changed, 54 insertions(+), 45 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 1ad9b41b64..040b109799 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -1307,7 +1307,8 @@ TODO The b10-auth is the authoritative DNS server. - It supports EDNS0 and DNSSEC. It supports IPv6. + It supports EDNS0, DNSSEC, IPv6, and SQLite3 and in-memory zone + data backends. Normally it is started by the bind10 master process. @@ -1332,8 +1333,8 @@ since we used bind10 --> This is an optional string to define the path to find the SQLite3 database file. -Note: Later the DNS server will use various data source backends. -This may be a temporary setting until then. +Note: This may be a temporary setting because the DNS server +can use various data source backends. @@ -1354,7 +1355,9 @@ This may be a temporary setting until then. and zones to define the file path name, - the filetype (e.g., sqlite3), + the filetype (sqlite3 to load + from a SQLite3 database file or text to + load from a master text file), and the origin (default domain). By default, this is empty. @@ -1526,13 +1529,13 @@ This may be a temporary setting until then. > config commit The authoritative server will begin serving it immediately - after it is loaded. + after the zone data is loaded from the master text file.
- In-memory Data Source With SQLite3 Backend + In-memory Data Source with SQLite3 Backend @@ -1554,7 +1557,7 @@ This may be a temporary setting until then. > config commit The authoritative server will begin serving it immediately - after it is loaded. + after the zone data is loaded from the database file.
@@ -1705,7 +1708,7 @@ TODO b10-auth. In combination with b10-zonemgr (for automated SOA checks), this allows the BIND 10 server to - provide secondary service. + provide secondary service. @@ -1843,6 +1846,9 @@ what if a NOTIFY is sent? automatically sent a loadzone command to reload the corresponding zone into memory from the backend. + The administrator doesn't have to do anything for @@ -1865,7 +1871,7 @@ what if a NOTIFY is sent? When the b10-auth authoritative DNS server receives an AXFR or IXFR request, b10-auth internally forwards the request to b10-xfrout, - which handles the rest of request processing. + which handles the rest of this request processing. This is used to provide primary DNS service to share zones to secondary name servers. The b10-xfrout is also used to send @@ -1914,8 +1920,9 @@ Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default) > config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "192.0.2.1", "key": "key.example"}] > config commit - Both Xfrout and Auth will use the system wide keyring to check - TSIGs in the incoming messages and to sign responses. + Both b10-xfrout and b10-auth + will use the system wide keyring to check + TSIGs in the incoming messages and to sign responses. The way to specify zone specific configuration (ACLs, etc) is @@ -1949,14 +1956,14 @@ what is XfroutClient xfr_client?? When the b10-auth authoritative DNS server receives an UPDATE request, it internally forwards the request to b10-ddns, which handles the rest of - request processing. - When the processing is completed b10-ddns - will send a response to the client with the RCODE set to the - value as specified in RFC 2136 (NOERROR for successful update, - REFUSED if rejected due to ACL check, etc). + this request processing. + When the processing is completed, b10-ddns + will send a response to the client as specified in RFC 2136 + (NOERROR for successful update, REFUSED if rejected due to + ACL check, etc). If the zone has been changed as a result, it will internally notify b10-xfrout so that other secondary - servers will be notified via the DNS notify protocol. + servers will be notified via the DNS NOTIFY protocol. In addition, if b10-auth serves the updated zone from its in-memory cache (as described in ), @@ -1982,10 +1989,10 @@ what is XfroutClient xfr_client?? As of this writing b10-ddns does not support update forwarding for secondary zones. If it receives an update request for a secondary zone, it will - immediately return a response with an RCODE of NOTIMP. + immediately return a not implemented response. - For feature completeness update forwarding should be - eventually supported. But right now it's considered a lower + For feature completeness, update forwarding should be + eventually supported. But currently it's considered a lower priority task and there is no specific plan of implementing this feature. @@ -2015,9 +2022,9 @@ what is XfroutClient xfr_client?? underlying data source storing the zone data be writable. In the current implementation this means the zone must be stored in an SQLite3-based data source. - Also, right now, the b10-ddns component - configures itself with the data source referring to the - database_file configuration parameter of + Also, in this development version, the b10-ddns + component configures itself with the data source referring to the + database_file configuration parameter of b10-auth. So this information must be configured correctly before starting b10-ddns. @@ -2051,14 +2058,16 @@ what is XfroutClient xfr_client?? > config commit - In theory "kind" could be omitted because "dispensable" is its - default. But there's some peculiar behavior (which should - be a bug and should be fixed eventually; see Trac ticket - #2064) with bindctl and you'll still need to specify that explicitly. - Likewise, "address" may look unnecessary because - b10-ddns would start and work without - specifying it. But for it to shutdown gracefully this - parameter should also be specified. + In theory kind could be omitted because + "dispensable" is its default. + But there's some peculiar behavior (which should be a + bug and should be fixed eventually; see Trac ticket #2064) + with bindctl and you'll still need to + specify that explicitly. Likewise, address + may look unnecessary because b10-ddns + would start and work without specifying it. But for it + to shutdown gracefully this parameter should also be + specified. @@ -2066,14 +2075,13 @@ what is XfroutClient xfr_client??
Access Control - By default b10-ddns rejects any update - requests from any clients by returning a response with an RCODE - of REFUSED. + By default, b10-ddns rejects any update + requests from any clients by returning a REFUSED response. To allow updates to take effect, an access control rule (called update ACL) with a policy allowing updates must explicitly be configured. Update ACL must be configured per zone basis in the - zones configuration parameter of + zones configuration parameter of b10-ddns. This is a list of per-zone configurations regarding DDNS. Each list element consists of the following parameters: @@ -2108,14 +2116,12 @@ what is XfroutClient xfr_client?? In general, an update ACL rule that allows an update request should be configured with a TSIG key. This is an example update ACL that allows updates to the zone - named example.org of RR class IN + named example.org (of default RR class IN) from clients that send requests signed with a TSIG whose key name is "key.example.org" (and refuses all others): > config add DDNS/zones > config set DDNS/zones[0]/origin example.org -> config set DDNS/zones[0]/class IN -(Note: "class" can be omitted) > config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "key": "key.example.org"} > config commit @@ -2140,11 +2146,13 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. > config commit (Note the "add" in the first line. Before this sequence, we - have had only entry in zones[0]/update_acl. The "add" command - with a value (rule) adds a new entry and sets it to the given rule. + have had only entry in zones[0]/update_acl. + The add command with a value (rule) adds + a new entry and sets it to the given rule. + Due to a limitation of the current implementation, it doesn't work if you first try to just add a new entry and then set it to - a given rule). + a given rule.) @@ -2166,6 +2174,7 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. which is rejecting any requests in the case of b10-ddns. + Other actions than "ACCEPT", namely "REJECT" and "DROP", can be @@ -2204,8 +2213,8 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. Miscellaneous Operational Issues Unlike BIND 9, BIND 10 currently does not support automatic - resigning of DNSSEC-signed zone when it's updated via DDNS. - It could be possible to resign the updated zone afterwards + re-signing of DNSSEC-signed zone when it's updated via DDNS. + It could be possible to re-sign the updated zone afterwards or make sure the update request also updates related DNSSEC records, but that will be pretty error-prone operation. In general, it's not advisable to allow DDNS for a signed zone @@ -2229,8 +2238,8 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. b10-zonemgr. Zones listed in secondary_zones will never be updated via DDNS regardless of the update ACL configuration; - b10-ddns will return a response with an - RCODE of NOTAUTH as specified in RFC 2136. + b10-ddns will return a NOTAUTH (server + not authoritative for the zone) response. If you have a "conceptual" secondary zone whose content is a copy of some external source but is not updated via the standard zone transfers and therefore not listed in