BIND 10 trac2005, updated. abe48da05aa1625a942ff093058889fb7e822169 [2005] updated date and history
BIND 10 source code commits
bind10-changes at lists.isc.org
Mon Jun 18 23:34:30 UTC 2012
The branch, trac2005 has been updated
via abe48da05aa1625a942ff093058889fb7e822169 (commit)
via dac5152826d9bdd56252d70228880a9108255455 (commit)
via 03f10b9d6ba493489d68e0652749b1dc0a74d492 (commit)
via d0dba48458ac80578538a4ca234a43ba21f1e992 (commit)
via 5b2f4e7ba0a8c0967719cc9f3e840950ffc7048e (commit)
via 54baeb376adb8518e7cf60cf15c3d0dbdf945d29 (commit)
via 1f195b1c22296d159cd39de24ff32334d22a0f9a (commit)
via c0fa5a1b01ac6a86b96160f3b669fe3509ed0976 (commit)
via 887ba8b3bd14b45d4eccde8f55a69d16fb6495c6 (commit)
via f50985476336a7a41dd30de96d7ed6d3c5313d0e (commit)
via af892b5382f052891aaa94f056e8c337f4f9ec06 (commit)
via fb7423508e86f8e938f129c9d4406ecf7ec75e35 (commit)
via feca3314862c72dca95f993310d56f07911ef008 (commit)
via 32751469f3c21db28a5f922423962f2394102248 (commit)
via aab679cd7faf500112dbcab789899b45b5b63eca (commit)
via f9771a16778f1ecfae1eccded1db9b0b61b09038 (commit)
via 03871e57d90245cca56b2fd438aa081f270e9e7a (commit)
from 2fad24672daed63e82dbb92234cedea9fe28ca67 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit abe48da05aa1625a942ff093058889fb7e822169
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 16:17:16 2012 -0700
[2005] updated date and history
commit dac5152826d9bdd56252d70228880a9108255455
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 16:14:24 2012 -0700
[2005] clarified RCODE of NOTAUTH case.
commit 03f10b9d6ba493489d68e0652749b1dc0a74d492
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 16:08:27 2012 -0700
[2005] wording clarification on ACL order
commit d0dba48458ac80578538a4ca234a43ba21f1e992
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 16:06:14 2012 -0700
[2005] on REJECT and DROP acl actions.
commit 5b2f4e7ba0a8c0967719cc9f3e840950ffc7048e
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 16:01:16 2012 -0700
[2005] explain how ACL rules apply
commit 54baeb376adb8518e7cf60cf15c3d0dbdf945d29
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 15:57:01 2012 -0700
[2005] some clarification on a config param
commit 1f195b1c22296d159cd39de24ff32334d22a0f9a
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 15:55:41 2012 -0700
[2005] clarify "config add" for adding a new ACL rule with a value
commit c0fa5a1b01ac6a86b96160f3b669fe3509ed0976
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 15:47:43 2012 -0700
[2005] trac ticket number for "update-policy" ACL
commit 887ba8b3bd14b45d4eccde8f55a69d16fb6495c6
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 15:45:11 2012 -0700
[2005] about omittable "IN" default.
commit f50985476336a7a41dd30de96d7ed6d3c5313d0e
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 15:37:07 2012 -0700
[2005] a minor wording clarification on ACL
commit af892b5382f052891aaa94f056e8c337f4f9ec06
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 15:27:43 2012 -0700
[2005] on peculiar behavior with bindctl and boss components config.
commit fb7423508e86f8e938f129c9d4406ecf7ec75e35
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 15:09:50 2012 -0700
[2005] on log messages regarding dependencies
commit feca3314862c72dca95f993310d56f07911ef008
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 15:05:19 2012 -0700
[2005] updated the DDNS_UPDATE_NOTIFY_FAIL case
commit 32751469f3c21db28a5f922423962f2394102248
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 15:04:43 2012 -0700
[2005] revised DDNS_UPDATE_NOTIFY_FAIL desc about likely cause and effects.
commit aab679cd7faf500112dbcab789899b45b5b63eca
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 13:08:40 2012 -0700
[2005] clarified about reusing TCP connection.
commit f9771a16778f1ecfae1eccded1db9b0b61b09038
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 12:58:26 2012 -0700
[2005] use "component" instead of "process" more consistently.
commit 03871e57d90245cca56b2fd438aa081f270e9e7a
Author: JINMEI Tatuya <jinmei at isc.org>
Date: Mon Jun 18 12:57:51 2012 -0700
[2005] clarified the meaning of "processing result".
-----------------------------------------------------------------------
Summary of changes:
doc/guide/bind10-guide.xml | 107 ++++++++++++++++++++++++++++++++--------
src/bin/ddns/b10-ddns.xml | 6 ++-
src/bin/ddns/ddns_messages.mes | 41 ++++++++++-----
3 files changed, 118 insertions(+), 36 deletions(-)
-----------------------------------------------------------------------
diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml
index 1647e69..568b517 100644
--- a/doc/guide/bind10-guide.xml
+++ b/doc/guide/bind10-guide.xml
@@ -1924,7 +1924,7 @@ what is XfroutClient xfr_client??
BIND 10 supports the server side of the Dynamic DNS Update
(DDNS) protocol as defined in RFC 2136.
This service is provided by the <command>b10-ddns</command>
- process, which is started by the <command>bind10</command>
+ component, which is started by the <command>bind10</command>
process if configured so.
</para>
@@ -1934,20 +1934,31 @@ what is XfroutClient xfr_client??
to <command>b10-ddns</command>, which handles the rest of
request processing.
When the processing is completed <command>b10-ddns</command>
- will send a response to the client with the processing result.
+ 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).
If the zone has been changed as a result, it will internally
- notify <command>b10-auth</command> and
- <command>b10-xfrout</command> so the new version of the zone will
- be served, and other secondary servers will be notified via the
- DNS notify protocol.
+ notify <command>b10-xfrout</command> so that other secondary
+ servers will be notified via the DNS notify protocol.
+ In addition, if <command>b10-auth</command> serves the updated
+ zone from its in-memory cache (as described in
+ <xref linkend="in-memory-datasource-with-sqlite3-backend" />),
+ <command>b10-ddns</command> will also
+ notify <command>b10-auth</command> so that <command>b10-auth</command>
+ will re-cache the updated zone content.
</para>
<para>
- The <command>b10-ddns</command> process supports requests over
+ The <command>b10-ddns</command> component supports requests over
both UDP and TCP, and both IPv6 and IPv4; for TCP requests,
however, it terminates the TCP connection immediately after
each single request has been processed. Clients cannot reuse the
- same TCP connection for multiple requests.
+ same TCP connection for multiple requests (This is a current
+ implementation limitation of <command>b10-ddns</command>;
+ while RFC 2136 doesn't specify anything about such reuse of TCP
+ connection, there is no reason for disallowing it as RFC 1035
+ generally allows multiple requests sent over a single TCP
+ connection. BIND 9 supports such reuse).
</para>
<para>
@@ -1955,6 +1966,13 @@ what is XfroutClient xfr_client??
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.
+ <note><simpara>
+ For feature completeness update forwarding should be
+ eventually supported. But right now it's considered a lower
+ priority task and there is no specific plan of implementing
+ this feature.
+ <!-- See Trac #2063 -->
+ </simpara></note>
</para>
<section>
@@ -1967,7 +1985,9 @@ what is XfroutClient xfr_client??
In addition, <command>b10-xfrout</command> should also be
configured to run; otherwise the notification after an update
(see above) will fail with a timeout, suspending the DDNS
- service while <command>b10-ddns</command> waits for the response.
+ service while <command>b10-ddns</command> waits for the
+ response (see the description of the DDNS_UPDATE_NOTIFY_FAIL
+ for further details).
If BIND 10 is already configured to provide authoritative DNS
service they should normally be configured to run already.
</para>
@@ -1977,7 +1997,7 @@ 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 <command>b10-ddns</command> process
+ Also, right now, the <command>b10-ddns</command> component
configures itself with the data source referring to the
<quote>database_file</quote> configuration parameter of
<command>b10-auth</command>.
@@ -1993,6 +2013,15 @@ what is XfroutClient xfr_client??
</para>
<para>
+ In general, if something goes wrong regarding the dependency
+ described above, <command>b10-ddns</command> will log the
+ related event at the warning or error level.
+ It's advisable to check the log message when you first enable
+ DDNS or if it doesn't work as you expect to see if there's any
+ warning or error log message.
+ </para>
+
+ <para>
Next, to enable the DDNS service, <command>b10-ddns</command>
needs to be explicitly configured to run.
It can be done by using the <command>bindctl</command>
@@ -2003,6 +2032,16 @@ what is XfroutClient xfr_client??
> <userinput>config set Boss/components/b10-ddns/kind dispensable</userinput>
> <userinput>config commit</userinput>
</screen>
+ <note><simpara>
+ 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
+ <command>b10-ddns</command> would start and work without
+ specifying it. But for it to shutdown gracefully this
+ parameter should also be specified.
+ </simpara></note>
</para>
</section>
@@ -2013,7 +2052,7 @@ what is XfroutClient xfr_client??
requests from any clients by returning a response with an RCODE
of REFUSED.
To allow updates to take effect, an access control rule
- (called update ACL) with that policy must explicitly be
+ (called update ACL) with a policy allowing updates must explicitly be
configured.
Update ACL must be configured per zone basis in the
<quote>zones</quote> configuration parameter of
@@ -2031,7 +2070,8 @@ what is XfroutClient xfr_client??
<term>class</term>
<listitem>
<simpara>The RR class of the zone
- (normally <quote>IN</quote>)</simpara>
+ (normally <quote>IN</quote>, and in that case
+ can be omitted in configuration)</simpara>
</listitem>
</varlistentry>
<varlistentry>
@@ -2057,10 +2097,10 @@ what is XfroutClient xfr_client??
> <userinput>config add DDNS/zones</userinput>
> <userinput>config set DDNS/zones[0]/origin example.org</userinput>
> <userinput>config set DDNS/zones[0]/class IN</userinput>
+(Note: "class" can be omitted)
> <userinput>config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "key": "key.example.org"}</userinput>
> <userinput>config commit</userinput>
- </screen>
- (The <quote>class</quote> can be omitted).
+</screen>
The TSIG key must be configured system wide
(see <xref linkend="xfrout"/>.)
</para>
@@ -2069,9 +2109,11 @@ what is XfroutClient xfr_client??
Multiple rules can be specified in the ACL, and an ACL rule
can consist of multiple constraints, such as a combination of
IP address and TSIG.
- The following configuration sequence will add to the previous
- ACL a rule that allows update requests sent from a client
- using TSIG key name of "key.example" and has an IPv6 address of ::1.
+ The following configuration sequence will add a new rule to
+ ACL created in the above example. This additional rule
+ allows update requests sent from a client
+ using TSIG key name of "key.example" (different from the
+ key used in the previous example) and has an IPv6 address of ::1.
<screen>
> <userinput>config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "from": "::1", "key": "key.example"}</userinput>
> <userinput>config show DDNS/zones[0]/update_acl</userinput>
@@ -2079,10 +2121,16 @@ DDNS/zones[0]/update_acl[0] {"action": "ACCEPT", "key": "key.example.org"} a
DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key.example"} any (modified)
> <userinput>config commit</userinput>
</screen>
+ (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.
+ 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).
</para>
<note><simpara>
- The <command>b10-ddns</command> process accepts an ACL
+ The <command>b10-ddns</command> component accepts an ACL
rule that just allows updates from a specific IP address
(i.e., without requiring TSIG), but this is highly
discouraged (remember that requests can be made over UDP and
@@ -2094,10 +2142,25 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key.
</simpara></note>
<para>
+ The ACL rules will be checked in the listed order, and the
+ first matching one will apply.
+ If none of the rules matches, the default rule will apply,
+ which is rejecting any requests in the case of
+ <command>b10-ddns</command>.
+ </para>
+
+ <para>
+ Other actions than "ACCEPT", namely "REJECT" and "DROP", can be
+ used, too.
+ See <xref linkend="resolverserver"/> about their effects.
+ </para>
+
+ <para>
Currently update ACL can only control updates per zone basis;
it's not possible to specify access control with higher
granularity such as for particular domain names or specific
types of RRs.
+ <!-- See Trac ticket #2065 -->
</para>
<note><simpara>
@@ -2109,8 +2172,8 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key.
discussed among implementers and in the IETF, and it is now
widely agreed that it does not make sense to strictly follow
that part of RFC.
- One known specific bad result of this is that it could leak
- information about which name or record exists or does not
+ One known specific bad result of following the RFC is that it
+ could leak information about which name or record exists or does not
exist in the zone as a result of prerequisite checks even if a
zone is somehow configured to reject normal queries from
arbitrary clients.
@@ -2147,7 +2210,9 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key.
<quote>secondary_zones</quote> configuration of
<command>b10-zonemgr</command>. Zones listed in
<quote>secondary_zones</quote> will never be updated via DDNS
- regardless of the update ACL configuration.
+ regardless of the update ACL configuration;
+ <command>b10-ddns</command> will return a response with an
+ RCODE of NOTAUTH as specified in RFC 2136.
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
diff --git a/src/bin/ddns/b10-ddns.xml b/src/bin/ddns/b10-ddns.xml
index b8c5815..02879f4 100644
--- a/src/bin/ddns/b10-ddns.xml
+++ b/src/bin/ddns/b10-ddns.xml
@@ -20,7 +20,7 @@
<refentry>
<refentryinfo>
- <date>February 28, 2012</date>
+ <date>June 18, 2012</date>
</refentryinfo>
<refmeta>
@@ -66,7 +66,8 @@
to <command>b10-ddns</command>, which handles the rest of
request processing.
When the processing is completed <command>b10-ddns</command>
- will send a response to the client with the processing result.
+ will send a response to the client with the the RCODE set to the
+ value as specified in RFC 2136.
If the zone has been changed as a result, it will internally
notify <command>b10-auth</command> and
<command>b10-xfrout</command> so the new version of the zone will
@@ -190,6 +191,7 @@
<para>
The <command>b10-ddns</command> daemon was first implemented
in December 2011 for the ISC BIND 10 project.
+ The first functional version was released in June 2012.
</para>
</refsect1>
</refentry><!--
diff --git a/src/bin/ddns/ddns_messages.mes b/src/bin/ddns/ddns_messages.mes
index 61311bc..c30cf6e 100644
--- a/src/bin/ddns/ddns_messages.mes
+++ b/src/bin/ddns/ddns_messages.mes
@@ -214,16 +214,31 @@ notify messages to secondary servers.
% DDNS_UPDATE_NOTIFY_FAIL failed to notify %1 of updates to %2: %3
b10-ddns has made updates to a zone based on an update request and
-tried to notify an external module of the updates, but the
-notification fails. Severity of this effect depends on the type of
-the module. If it's b10-xfrout, this means DNS notify messages won't
-be sent to secondary servers of the zone. It's suboptimal, but not
-necessarily critical as the secondary servers will try to check the
-zone's status periodically. If it's b10-auth and the notification was
-needed to have it reload the corresponding zone, it's more serious
-because b10-auth won't be able to serve the new version of the zone
-unless some explicit recovery action is taken. So the administrator
-needs to examine this message and takes an appropriate action. In
-either case, this notification is generally expected to succeed; so
-the fact it fails itself means there's something wrong in the BIND 10
-system, and it would be advisable to check other log messages.
+tried to notify an external component of the updates, but the
+notification fails. One possible cause of this is that the external
+component is not really running and it times out in waiting for the
+response, although it will be less likely to happen in practice
+because these components will normally be configured to run when the
+server provides the authoritative DNS service; ddns is rather optional
+among them. If this happens, however, it will suspend b10-ddns for a
+few seconds during which it cannot handle new requests (some may be
+delayed, some may be dropped, depending on the volume of the incoming
+requests). This is obviously bad, and if this error happens due to
+this reason, the administrator should make sure the component in
+question should be configured to run. For a longer term, b10-ddns
+should be more robust about this case such as by making this
+notification asynchronously and/or detecting the existence of the
+external components to avoid hopeless notification in the first place.
+Severity of this error for the receiving components depends on the
+type of the component. If it's b10-xfrout, this means DNS notify
+messages won't be sent to secondary servers of the zone. It's
+suboptimal, but not necessarily critical as the secondary servers will
+try to check the zone's status periodically. If it's b10-auth and the
+notification was needed to have it reload the corresponding zone, it's
+more serious because b10-auth won't be able to serve the new version
+of the zone unless some explicit recovery action is taken. So the
+administrator needs to examine this message and takes an appropriate
+action. In either case, this notification is generally expected to
+succeed; so the fact it fails itself means there's something wrong in
+the BIND 10 system, and it would be advisable to check other log
+messages.
More information about the bind10-changes
mailing list