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