From fb03a64781c661a06242741378592c59f45f432f Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Thu, 14 Jun 2012 15:17:07 -0700 Subject: [PATCH 01/30] [2005] updated the list of tested OSes. not related to the task, but noticed. --- doc/guide/bind10-guide.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index e5adb0cf8e..7f7d0206f2 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -87,9 +87,10 @@
Supported Platforms - BIND 10 builds have been tested on Debian GNU/Linux 5 and unstable, - Ubuntu 9.10, NetBSD 5, Solaris 10, FreeBSD 7 and 8, CentOS - Linux 5.3, and MacOS 10.6. + BIND 10 builds have been tested on (in no particular order) + Debian GNU/Linux 5 and unstable, Ubuntu 9.10, NetBSD 5, + Solaris 10 and 11, FreeBSD 7 and 8, CentOS Linux 5.3, + MacOS 10.6 and 10.7, and OpenBSD 5.1. It has been tested on Sparc, i386, and amd64 hardware platforms. From 35eab8559632ab2cd0f1f32cb1c2db594b050e24 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Thu, 14 Jun 2012 23:02:58 -0700 Subject: [PATCH 02/30] [2005] added a chapter for DDNS to BIND 10 guide. --- doc/guide/bind10-guide.xml | 264 ++++++++++++++++++++++++++++++++++++- 1 file changed, 259 insertions(+), 5 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 7f7d0206f2..20914af9b8 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -128,10 +128,10 @@ - The b10-xfrin, b10-xfrout, - and b10-zonemgr components require the - libpython3 library and the Python _sqlite3.so module - (which is included with Python). + The b10-ddns, b10-xfrin, + b10-xfrout, and b10-zonemgr + components require the libpython3 library and the Python + _sqlite3.so module (which is included with Python). The Python module needs to be built for the corresponding Python 3. @@ -195,6 +195,16 @@ + + + b10-ddns — + Dynamic DNS update service. + This process is used to handle incoming DNS update + requests to allow granted clients to update zones + for which BIND 10 is serving as a primary server. + + + b10-msgq — @@ -1832,7 +1842,6 @@ what if a NOTIFY is sent? Outbound Zone Transfers - The b10-xfrout process is started by bind10. @@ -1908,6 +1917,251 @@ what is XfroutClient xfr_client?? + + Dynamic DNS Update + + + BIND 10 supports the server side of the Dynamic DNS Update + (DDNS) protocol as defined in RFC 2136. + This service is provided by the b10-ddns + process, which is started by the bind10 + process if configured so. + + + + 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 process is completed b10-ddns + will send a response to the client with the processing result. + If the zone has been changed as a result, it will internally + notify b10-auth and + b10-xfrout so the new version of zone will + be served, and other secondary servers will be notified via the + DNS notify protocol. + + + + The b10-ddns process 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. + + + + 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. + + +
+ Enabling Dynamic Update + + First off, it must be made sure that a few components on which + b10-ddns depends are configured to run, + which are b10-auth + and b10-zonemgr. + If BIND 10 is already configured to provide authoritative DNS + service they should normally be configured to run already. + + + + Second, for the obvious reason dynamic update requires that the + 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 process + 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. + + + The way to configure data sources is now being revised. + Configuration on the data source for DDNS will be very + likely to be changed in a backward incompatible manner in + a near future version. + + + + + Next, to enable the DDNS service, b10-ddns + needs to be explicitly configured to run. + It can be done by using the bindctl + utility. For example: + +> config add Boss/components b10-ddns +> config set Boss/components/b10-ddns/address DDNS +> config set Boss/components/b10-ddns/kind dispensable +> config commit + + +
+ +
+ Access Control + + By default b10-ddns rejects any update + 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 + configured. + Update ACL must be configured per zone basis in the + zones configuration parameter of + b10-ddns. + This is a list of per-zone configuration regarding DDNS. + Each list element consists of the following parameters: + + + origin + + The zone's origin name + + + + class + + The RR class of the zone + (normally IN) + + + + update_acl + + List of access control rules (ACL) for the zone + + + + The syntax of the ACL is the same as ACLs for other + components. + Specific examples are given below. + + + + 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 + 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 +> config set DDNS/zones[0]/update_acl [{"action": "ACCEPT", "key": "key.example.org"}] +> config commit + + The TSIG key must be configured system wide + (see .) + + + + 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 ACL is to allow update requests that meet the + above condition, or requests sent from a client using TSIG key + name of "key.example" and has an IPv6 address of ::1. + +> config set DDNS/zones[0]/update_acl [{"action": "ACCEPT", "key": "key.example.org"}, {"action": "ACCEPT", "from": "::1", "key": "key.example"}] +> config commit + + (Right now, ACL cannot be updated incrementally; you need to + specify the entire new list of rules at once.) + + + + The b10-ddns process 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 + spoofing the source address of a UDP packet is often pretty + easy). + Unless you know what you are doing and that you can accept + its consequence, any update ACL rule that allows updates + should have a TSIG key in its constraints. + + + + 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. + + + + Contrary to what RFC 2136 (literally) specifies, + b10-ddns checks the update ACL before + checking the prerequisites of the update request. + This is a deliberate implementation decision. + This counter intuitive specification has been repeatedly + 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 + exist in the zone as a result of prerequisite checks even if a + zone is somehow configured to reject normal queries from + arbitrary clients. + There have been other troubles that could have been avoided if + the ACL could be checked before the prerequisite check. + +
+ +
+ 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 + 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 + at this moment. + + + + Also unlike BIND 9, it's currently not possible + to freeze a zone temporarily in order to + suspend DDNS while you manually update the zone. + If you need to make manual updates to a dynamic zone, + you'll need to temporarily reject any updates to the zone via + the update ACLs. + + + + Dynamic updates are only applicable to primary zones. + In order to avoid updating secondary zones via DDNS requests, + b10-ddns refers to the + secondary_zones configuration of + b10-zonemgr. Zones listed in + secondary_zones will never be updated via DDNS + regardless of the update ACL configuration. + 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 + secondary_zones, be careful not to allow DDNS + for the zone; it would be quite likely to lead to inconsistent + state between different servers. + Normally this should not be a problem because the default + update ACL rejects any update requests, but you may want to + take an extra care about the configuration if you have such + type of secondary zones. + + + The difference of two versions of a zone, before and after a + DDNS transaction is automatically recorded in the underlying + data source, and can be retrieved in the form of outbound IXFR. + There has to be no configuration to make this possible. + +
+ + Recursive Name Server From a897869e543b1bc56558adccc5ca67d1d0a1aeaf Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Thu, 14 Jun 2012 23:20:12 -0700 Subject: [PATCH 03/30] [2005] updated b10-ddns(8); some editorial updates to the guide too --- doc/guide/bind10-guide.xml | 4 +-- src/bin/ddns/b10-ddns.8 | 55 +++++++++++++++++++++++++------------- 2 files changed, 38 insertions(+), 21 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 20914af9b8..a8e77501fc 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -1933,11 +1933,11 @@ what is XfroutClient xfr_client?? receives an UPDATE request, it internally forwards the request to b10-ddns, which handles the rest of request processing. - When the process is completed b10-ddns + When the processing is completed b10-ddns will send a response to the client with the processing result. If the zone has been changed as a result, it will internally notify b10-auth and - b10-xfrout so the new version of zone will + b10-xfrout so the new version of the zone will be served, and other secondary servers will be notified via the DNS notify protocol. diff --git a/src/bin/ddns/b10-ddns.8 b/src/bin/ddns/b10-ddns.8 index 131b6ccc37..8b369e886b 100644 --- a/src/bin/ddns/b10-ddns.8 +++ b/src/bin/ddns/b10-ddns.8 @@ -1,7 +1,7 @@ '\" t .\" Title: b10-ddns .\" Author: [FIXME: author] [see http://docbook.sf.net/el/author] -.\" Generator: DocBook XSL Stylesheets v1.75.2 +.\" Generator: DocBook XSL Stylesheets v1.76.1 .\" Date: February 28, 2012 .\" Manual: BIND10 .\" Source: BIND10 @@ -9,6 +9,15 @@ .\" .TH "B10\-DDNS" "8" "February 28, 2012" "BIND10" "BIND10" .\" ----------------------------------------------------------------- +.\" * Define some portability stuff +.\" ----------------------------------------------------------------- +.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.\" http://bugs.debian.org/507673 +.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html +.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.ie \n(.g .ds Aq \(aq +.el .ds Aq ' +.\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation @@ -33,29 +42,29 @@ boss process\&. When the \fBb10\-auth\fR DNS server receives a DDNS update, \fBb10\-ddns\fR -updates the zone in the BIND 10 zone data store\&. -.if n \{\ -.sp -.\} -.RS 4 -.it 1 an-trap -.nr an-no-space-flag 1 -.nr an-break-flag 1 -.br -.ps +1 -\fBNote\fR -.ps -1 -.br +updates the zone in the BIND 10 zone data source\&. .PP -Currently installed is a dummy component\&. It does not provide any functionality\&. It is a skeleton implementation that will be expanded later\&. -.sp .5v -.RE +When the +\fBb10\-auth\fR +authoritative DNS server receives an UPDATE request, it internally forwards the request to +\fBb10\-ddns\fR, which handles the rest of request processing\&. When the process is completed +\fBb10\-ddns\fR +will send a response to the client with the processing result\&. If the zone has been changed as a result, it will internally notify +\fBb10\-auth\fR +and +\fBb10\-xfrout\fR +so the new version of zone will be served, and other secondary servers will be notified via the DNS notify protocol\&. .PP This daemon communicates with BIND 10 over a \fBb10-msgq\fR(8) C\-Channel connection\&. If this connection is not established, \fBb10\-ddns\fR -will exit\&. +will exit\&. The +\fBb10\-ddns\fR +daemon depends on some other BIND 10 components: +\fBb10-auth\fR(8) +and +\fBb10-zonemgr\fR(8)\&. .PP \fBb10\-ddns\fR @@ -75,7 +84,13 @@ The configurable settings are: .PP \fIzones\fR -The zones option is a named set of zones that can be updated with DDNS\&. Each entry has one element called update_acl, which is a list of access control rules that define update permissions\&. By default this is empty; DDNS must be explicitely enabled per zone\&. +The zones option is a list of configuration items for specific zones that can be updated with DDNS\&. Each entry is a map that can contain the following items: +\fIorigin\fR +is a textual domain name of the zone; +\fIclass\fR +(text) is the RR class of the zone; +\fIupdate_acl\fR +is a list of ACL that controls permission for updates\&. See the BIND 10 Guide for configuration details\&. Note that not listing a zone in this list does not directly mean update requests for the zone are rejected, but the end result is the same because the default ACL for updates is to deny all requests\&. .PP The module commands are: .PP @@ -91,6 +106,8 @@ argument to select the process ID to stop\&. (Note that the BIND 10 boss process \fBb10-auth\fR(8), \fBb10-cfgmgr\fR(8), \fBb10-msgq\fR(8), +\fBb10-xfrout\fR(8), +\fBb10-zonemgr\fR(8), \fBbind10\fR(8), BIND 10 Guide\&. .SH "HISTORY" From 4f1848c0b300fba25d8b26800fccd21b3b1506b1 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Fri, 15 Jun 2012 10:13:19 -0700 Subject: [PATCH 04/30] [2005] noted that xfrout is effectively a mandatory component too (and one minor editorial update) --- doc/guide/bind10-guide.xml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index a8e77501fc..8babbac608 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -1964,6 +1964,10 @@ what is XfroutClient xfr_client?? b10-ddns depends are configured to run, which are b10-auth and b10-zonemgr. + In addition, b10-xfrout should also be + configured to run; otherwise the notification after an update + (see above) will fail with a timeout, suspending the DDNS + service while b10-ddns waits for the response. If BIND 10 is already configured to provide authoritative DNS service they should normally be configured to run already. @@ -2155,7 +2159,7 @@ what is XfroutClient xfr_client?? The difference of two versions of a zone, before and after a - DDNS transaction is automatically recorded in the underlying + DDNS transaction, is automatically recorded in the underlying data source, and can be retrieved in the form of outbound IXFR. There has to be no configuration to make this possible. From afb888c27e574c98bdcac814bd5260d4faa599c7 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Fri, 15 Jun 2012 10:39:56 -0700 Subject: [PATCH 05/30] [2005] revised ACL config using "add" for each rule than setting all list --- doc/guide/bind10-guide.xml | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 8babbac608..5766188fb1 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2057,9 +2057,10 @@ what is XfroutClient xfr_client?? > config add DDNS/zones > config set DDNS/zones[0]/origin example.org > config set DDNS/zones[0]/class IN -> config set DDNS/zones[0]/update_acl [{"action": "ACCEPT", "key": "key.example.org"}] +> config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "key": "key.example.org"} > config commit + (The class can be omitted). The TSIG key must be configured system wide (see .) @@ -2068,15 +2069,16 @@ 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 ACL is to allow update requests that meet the - above condition, or 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 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. -> config set DDNS/zones[0]/update_acl [{"action": "ACCEPT", "key": "key.example.org"}, {"action": "ACCEPT", "from": "::1", "key": "key.example"}] +> config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "from": "::1", "key": "key.example"} +> config show DDNS/zones[0]/update_acl +DDNS/zones[0]/update_acl[0] {"action": "ACCEPT", "key": "key.example.org"} any (modified) +DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key.example"} any (modified) > config commit - (Right now, ACL cannot be updated incrementally; you need to - specify the entire new list of rules at once.) From 7dd6d4083029074dd029f2e4be1875dc477a71e1 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Fri, 15 Jun 2012 10:42:06 -0700 Subject: [PATCH 06/30] [2005] wording update based on review suggestion --- doc/guide/bind10-guide.xml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 5766188fb1..67b0ae0419 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2162,8 +2162,10 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key.exam The difference of two versions of a zone, before and after a DDNS transaction, is automatically recorded in the underlying - data source, and can be retrieved in the form of outbound IXFR. - There has to be no configuration to make this possible. + data source, and can be retrieved in the form of outbound + IXFR. + This is done automaticallyl; it does not require specific + configuration to make this possible.
From 56a203c83779dd8695712b2df56198eb5d5fad69 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Fri, 15 Jun 2012 10:46:09 -0700 Subject: [PATCH 07/30] [2005] described -h, and some other small editorial updates --- src/bin/ddns/b10-ddns.xml | 62 ++++++++++++++++++++++++++++++--------- 1 file changed, 48 insertions(+), 14 deletions(-) diff --git a/src/bin/ddns/b10-ddns.xml b/src/bin/ddns/b10-ddns.xml index 15fcb1a029..b8c5815eaf 100644 --- a/src/bin/ddns/b10-ddns.xml +++ b/src/bin/ddns/b10-ddns.xml @@ -58,23 +58,32 @@ Normally it is started by the bind108 boss process. - When the b10-auth DNS server receives - a DDNS update, b10-ddns updates the zone - in the BIND 10 zone data store. - - Currently installed is a dummy component. It does not provide - any functionality. It is a skeleton implementation that - will be expanded later. - - + + 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 processing result. + If the zone has been changed as a result, it will internally + notify b10-auth and + b10-xfrout so the new version of the zone will + be served, and other secondary servers will be notified via the + DNS notify protocol. + This daemon communicates with BIND 10 over a b10-msgq8 C-Channel connection. If this connection is not established, b10-ddns will exit. + The b10-ddns daemon also depends on some other + BIND 10 components (either directly or indirectly): + b10-auth8, + b10-xfrout8, and + b10-zonemgr8. @@ -90,6 +99,17 @@ + + + , + + + + + Print the command line arguments and exit. + + + , @@ -98,7 +118,7 @@ This value is ignored at this moment, but is provided for - compatibility with the bind10 Boss process + compatibility with the bind10 Boss process. @@ -112,10 +132,18 @@ zones - The zones option is a named set of zones that can be updated with - DDNS. Each entry has one element called update_acl, which is - a list of access control rules that define update permissions. - By default this is empty; DDNS must be explicitely enabled per zone. + The zones option is a list of configuration items for specific + zones that can be updated with DDNS. Each entry is a map that + can contain the following items: + origin is a textual domain name of the zone; + class (text) is the RR class of the zone; + update_acl is an ACL that controls + permission for updates. + See the BIND 10 Guide for configuration details. + Note that not listing a zone in this list does not directly + mean update requests for the zone are rejected, but the end + result is the same because the default ACL for updates is to + deny all requests. @@ -144,6 +172,12 @@ b10-msgq8 , + + b10-xfrout8 + , + + b10-zonemgr8 + , bind108 , From 5d434e6cbe595de340b39348013acacaaccc588d Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Fri, 15 Jun 2012 12:05:12 -0700 Subject: [PATCH 08/30] [2005] untabify It's not clear whether the no-tab convention applies to the xml docs, but on jabber it was pointed out that it mucked up readability in a 4-tab-width editor. I've noticed there are tabs in other chapters than in DDNS, but I've limited my changes to the DDNS chapter, partly for keeping the diff small, and partly because I was not sure if it can cause an unexpected regression on the resulting html (etc) output. --- doc/guide/bind10-guide.xml | 250 ++++++++++++++++++------------------- 1 file changed, 125 insertions(+), 125 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 67b0ae0419..5738c4cc31 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -1960,43 +1960,43 @@ what is XfroutClient xfr_client??
Enabling Dynamic Update - First off, it must be made sure that a few components on which - b10-ddns depends are configured to run, - which are b10-auth - and b10-zonemgr. - In addition, b10-xfrout should also be - configured to run; otherwise the notification after an update - (see above) will fail with a timeout, suspending the DDNS - service while b10-ddns waits for the response. - If BIND 10 is already configured to provide authoritative DNS - service they should normally be configured to run already. + First off, it must be made sure that a few components on which + b10-ddns depends are configured to run, + which are b10-auth + and b10-zonemgr. + In addition, b10-xfrout should also be + configured to run; otherwise the notification after an update + (see above) will fail with a timeout, suspending the DDNS + service while b10-ddns waits for the response. + If BIND 10 is already configured to provide authoritative DNS + service they should normally be configured to run already. - Second, for the obvious reason dynamic update requires that the - 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 process - 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. + Second, for the obvious reason dynamic update requires that the + 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 process + 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. - - The way to configure data sources is now being revised. - Configuration on the data source for DDNS will be very - likely to be changed in a backward incompatible manner in - a near future version. - + + The way to configure data sources is now being revised. + Configuration on the data source for DDNS will be very + likely to be changed in a backward incompatible manner in + a near future version. + - Next, to enable the DDNS service, b10-ddns - needs to be explicitly configured to run. - It can be done by using the bindctl - utility. For example: + Next, to enable the DDNS service, b10-ddns + needs to be explicitly configured to run. + It can be done by using the bindctl + utility. For example: > config add Boss/components b10-ddns > config set Boss/components/b10-ddns/address DDNS @@ -2009,17 +2009,17 @@ 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. - To allow updates to take effect, an access control rule - (called update ACL) with that policy must explicitly be - configured. - Update ACL must be configured per zone basis in the - zones configuration parameter of - b10-ddns. - This is a list of per-zone configuration regarding DDNS. - Each list element consists of the following parameters: + By default b10-ddns rejects any update + 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 + configured. + Update ACL must be configured per zone basis in the + zones configuration parameter of + b10-ddns. + This is a list of per-zone configuration regarding DDNS. + Each list element consists of the following parameters: origin @@ -2031,7 +2031,7 @@ what is XfroutClient xfr_client?? class The RR class of the zone - (normally IN) + (normally IN) @@ -2040,132 +2040,132 @@ what is XfroutClient xfr_client?? List of access control rules (ACL) for the zone - - The syntax of the ACL is the same as ACLs for other - components. - Specific examples are given below. + + The syntax of the ACL is the same as ACLs for other + components. + Specific examples are given below. - 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 - from clients that send requests signed with a TSIG whose - key name is "key.example.org" (and refuses all others): + 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 + 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 > config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "key": "key.example.org"} > config commit - + (The class can be omitted). The TSIG key must be configured system wide (see .) - 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. + 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. > config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "from": "::1", "key": "key.example"} > config show DDNS/zones[0]/update_acl -DDNS/zones[0]/update_acl[0] {"action": "ACCEPT", "key": "key.example.org"} any (modified) -DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key.example"} any (modified) +DDNS/zones[0]/update_acl[0] {"action": "ACCEPT", "key": "key.example.org"} any (modified) +DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key.example"} any (modified) > config commit - The b10-ddns process 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 - spoofing the source address of a UDP packet is often pretty - easy). - Unless you know what you are doing and that you can accept - its consequence, any update ACL rule that allows updates - should have a TSIG key in its constraints. + The b10-ddns process 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 + spoofing the source address of a UDP packet is often pretty + easy). + Unless you know what you are doing and that you can accept + its consequence, any update ACL rule that allows updates + should have a TSIG key in its constraints. - 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. + 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. - Contrary to what RFC 2136 (literally) specifies, - b10-ddns checks the update ACL before - checking the prerequisites of the update request. - This is a deliberate implementation decision. - This counter intuitive specification has been repeatedly - 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 - exist in the zone as a result of prerequisite checks even if a - zone is somehow configured to reject normal queries from - arbitrary clients. - There have been other troubles that could have been avoided if - the ACL could be checked before the prerequisite check. + Contrary to what RFC 2136 (literally) specifies, + b10-ddns checks the update ACL before + checking the prerequisites of the update request. + This is a deliberate implementation decision. + This counter intuitive specification has been repeatedly + 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 + exist in the zone as a result of prerequisite checks even if a + zone is somehow configured to reject normal queries from + arbitrary clients. + There have been other troubles that could have been avoided if + the ACL could be checked before the prerequisite check.
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 - 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 - at this moment. + 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 + 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 + at this moment. - Also unlike BIND 9, it's currently not possible - to freeze a zone temporarily in order to - suspend DDNS while you manually update the zone. - If you need to make manual updates to a dynamic zone, - you'll need to temporarily reject any updates to the zone via - the update ACLs. + Also unlike BIND 9, it's currently not possible + to freeze a zone temporarily in order to + suspend DDNS while you manually update the zone. + If you need to make manual updates to a dynamic zone, + you'll need to temporarily reject any updates to the zone via + the update ACLs. - Dynamic updates are only applicable to primary zones. - In order to avoid updating secondary zones via DDNS requests, - b10-ddns refers to the - secondary_zones configuration of - b10-zonemgr. Zones listed in - secondary_zones will never be updated via DDNS - regardless of the update ACL configuration. - 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 - secondary_zones, be careful not to allow DDNS - for the zone; it would be quite likely to lead to inconsistent - state between different servers. - Normally this should not be a problem because the default - update ACL rejects any update requests, but you may want to - take an extra care about the configuration if you have such - type of secondary zones. + Dynamic updates are only applicable to primary zones. + In order to avoid updating secondary zones via DDNS requests, + b10-ddns refers to the + secondary_zones configuration of + b10-zonemgr. Zones listed in + secondary_zones will never be updated via DDNS + regardless of the update ACL configuration. + 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 + secondary_zones, be careful not to allow DDNS + for the zone; it would be quite likely to lead to inconsistent + state between different servers. + Normally this should not be a problem because the default + update ACL rejects any update requests, but you may want to + take an extra care about the configuration if you have such + type of secondary zones. - The difference of two versions of a zone, before and after a - DDNS transaction, is automatically recorded in the underlying - data source, and can be retrieved in the form of outbound - IXFR. - This is done automaticallyl; it does not require specific - configuration to make this possible. + The difference of two versions of a zone, before and after a + DDNS transaction, is automatically recorded in the underlying + data source, and can be retrieved in the form of outbound + IXFR. + This is done automaticallyl; it does not require specific + configuration to make this possible.
From 2fad24672daed63e82dbb92234cedea9fe28ca67 Mon Sep 17 00:00:00 2001 From: "Jeremy C. Reed" Date: Mon, 18 Jun 2012 10:51:24 -0500 Subject: [PATCH 09/30] [2005] remove spelling typo --- doc/guide/bind10-guide.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 5738c4cc31..1647e69c9b 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2164,7 +2164,7 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. DDNS transaction, is automatically recorded in the underlying data source, and can be retrieved in the form of outbound IXFR. - This is done automaticallyl; it does not require specific + This is done automatically; it does not require specific configuration to make this possible.
From 03871e57d90245cca56b2fd438aa081f270e9e7a Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 12:57:51 -0700 Subject: [PATCH 10/30] [2005] clarified the meaning of "processing result". --- doc/guide/bind10-guide.xml | 4 +++- src/bin/ddns/b10-ddns.xml | 3 ++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 1647e69c9b..aac9aed28f 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -1934,7 +1934,9 @@ what is XfroutClient xfr_client?? 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 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 b10-auth and b10-xfrout so the new version of the zone will diff --git a/src/bin/ddns/b10-ddns.xml b/src/bin/ddns/b10-ddns.xml index b8c5815eaf..a5a969d9cf 100644 --- a/src/bin/ddns/b10-ddns.xml +++ b/src/bin/ddns/b10-ddns.xml @@ -66,7 +66,8 @@ 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 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 b10-auth and b10-xfrout so the new version of the zone will From f9771a16778f1ecfae1eccded1db9b0b61b09038 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 12:58:26 -0700 Subject: [PATCH 11/30] [2005] use "component" instead of "process" more consistently. --- doc/guide/bind10-guide.xml | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index aac9aed28f..37770c8b37 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 b10-ddns - process, which is started by the bind10 + component, which is started by the bind10 process if configured so. @@ -1938,14 +1938,18 @@ what is XfroutClient xfr_client?? 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 b10-auth and - b10-xfrout so the new version of the zone will - be served, and other secondary servers will be notified via the - DNS notify protocol. + notify b10-xfrout so that other secondary + 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 + ), + b10-ddns will also + notify b10-auth so that b10-auth + will re-cache the updated zone content. - The b10-ddns process supports requests over + The b10-ddns 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 @@ -1979,7 +1983,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 b10-ddns process + Also, right now, the b10-ddns component configures itself with the data source referring to the database_file configuration parameter of b10-auth. @@ -2084,7 +2088,7 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. - The b10-ddns process accepts an ACL + The b10-ddns 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 From aab679cd7faf500112dbcab789899b45b5b63eca Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 13:08:40 -0700 Subject: [PATCH 12/30] [2005] clarified about reusing TCP connection. --- doc/guide/bind10-guide.xml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 37770c8b37..3b67bb31e6 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -1953,7 +1953,12 @@ what is XfroutClient xfr_client?? 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 b10-ddns; + 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). From 32751469f3c21db28a5f922423962f2394102248 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 15:04:43 -0700 Subject: [PATCH 13/30] [2005] revised DDNS_UPDATE_NOTIFY_FAIL desc about likely cause and effects. --- src/bin/ddns/ddns_messages.mes | 41 +++++++++++++++++++++++----------- 1 file changed, 28 insertions(+), 13 deletions(-) diff --git a/src/bin/ddns/ddns_messages.mes b/src/bin/ddns/ddns_messages.mes index 61311bc0da..c30cf6eb18 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. From feca3314862c72dca95f993310d56f07911ef008 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 15:05:19 -0700 Subject: [PATCH 14/30] [2005] updated the DDNS_UPDATE_NOTIFY_FAIL case --- doc/guide/bind10-guide.xml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 3b67bb31e6..7e80e6b1a6 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -1966,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. + + 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. + +
@@ -1978,7 +1985,9 @@ what is XfroutClient xfr_client?? In addition, b10-xfrout should also be configured to run; otherwise the notification after an update (see above) will fail with a timeout, suspending the DDNS - service while b10-ddns waits for the response. + service while b10-ddns 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. From fb7423508e86f8e938f129c9d4406ecf7ec75e35 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 15:09:50 -0700 Subject: [PATCH 15/30] [2005] on log messages regarding dependencies --- doc/guide/bind10-guide.xml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 7e80e6b1a6..e83f2ee824 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2012,6 +2012,15 @@ what is XfroutClient xfr_client?? + + In general, if something goes wrong regarding the dependency + described above, b10-ddns 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. + + Next, to enable the DDNS service, b10-ddns needs to be explicitly configured to run. From af892b5382f052891aaa94f056e8c337f4f9ec06 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 15:27:43 -0700 Subject: [PATCH 16/30] [2005] on peculiar behavior with bindctl and boss components config. --- doc/guide/bind10-guide.xml | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index e83f2ee824..308b1b0fea 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2032,6 +2032,16 @@ what is XfroutClient xfr_client?? > config set Boss/components/b10-ddns/kind dispensable > 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. +
@@ -2088,7 +2098,7 @@ what is XfroutClient xfr_client?? > config set DDNS/zones[0]/class IN > config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "key": "key.example.org"} > config commit - + (The class can be omitted). The TSIG key must be configured system wide (see .) From f50985476336a7a41dd30de96d7ed6d3c5313d0e Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 15:37:07 -0700 Subject: [PATCH 17/30] [2005] a minor wording clarification on ACL --- doc/guide/bind10-guide.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 308b1b0fea..c9530b4eb7 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2052,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 zones configuration parameter of From 887ba8b3bd14b45d4eccde8f55a69d16fb6495c6 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 15:45:11 -0700 Subject: [PATCH 18/30] [2005] about omittable "IN" default. --- doc/guide/bind10-guide.xml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index c9530b4eb7..d319109daf 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2070,7 +2070,8 @@ what is XfroutClient xfr_client?? class The RR class of the zone - (normally IN) + (normally IN, and in that case + can be omitted in configuration) @@ -2096,10 +2097,10 @@ what is XfroutClient xfr_client?? > 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 - (The class can be omitted). The TSIG key must be configured system wide (see .) From c0fa5a1b01ac6a86b96160f3b669fe3509ed0976 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 15:47:43 -0700 Subject: [PATCH 19/30] [2005] trac ticket number for "update-policy" ACL --- doc/guide/bind10-guide.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index d319109daf..6477b5df25 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2138,6 +2138,7 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. it's not possible to specify access control with higher granularity such as for particular domain names or specific types of RRs. + From 1f195b1c22296d159cd39de24ff32334d22a0f9a Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 15:55:41 -0700 Subject: [PATCH 20/30] [2005] clarify "config add" for adding a new ACL rule with a value --- doc/guide/bind10-guide.xml | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 6477b5df25..e118989601 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2109,8 +2109,9 @@ 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 + 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" and has an IPv6 address of ::1. > config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "from": "::1", "key": "key.example"} @@ -2119,6 +2120,12 @@ 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) > 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. + 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). From 54baeb376adb8518e7cf60cf15c3d0dbdf945d29 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 15:57:01 -0700 Subject: [PATCH 21/30] [2005] some clarification on a config param --- doc/guide/bind10-guide.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index e118989601..c65ca8ac93 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2112,7 +2112,8 @@ what is XfroutClient xfr_client?? 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" and has an IPv6 address of ::1. + using TSIG key name of "key.example" (different from the + key used in the previous example) and has an IPv6 address of ::1. > config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "from": "::1", "key": "key.example"} > config show DDNS/zones[0]/update_acl From 5b2f4e7ba0a8c0967719cc9f3e840950ffc7048e Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 16:01:16 -0700 Subject: [PATCH 22/30] [2005] explain how ACL rules apply --- doc/guide/bind10-guide.xml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index c65ca8ac93..b0619c5d4d 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2141,6 +2141,14 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. should have a TSIG key in its constraints. + + 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 + b10-ddns. + + Currently update ACL can only control updates per zone basis; it's not possible to specify access control with higher From d0dba48458ac80578538a4ca234a43ba21f1e992 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 16:06:14 -0700 Subject: [PATCH 23/30] [2005] on REJECT and DROP acl actions. --- doc/guide/bind10-guide.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index b0619c5d4d..6ad5a52306 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2149,6 +2149,12 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. b10-ddns. + + Other actions than "ACCEPT", namely "REJECT" and "DROP", can be + used, too. + See about their effects. + + Currently update ACL can only control updates per zone basis; it's not possible to specify access control with higher From 03f10b9d6ba493489d68e0652749b1dc0a74d492 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 16:08:27 -0700 Subject: [PATCH 24/30] [2005] wording clarification on ACL order --- doc/guide/bind10-guide.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 6ad5a52306..7fbef0bdec 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2172,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. From dac5152826d9bdd56252d70228880a9108255455 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 16:14:24 -0700 Subject: [PATCH 25/30] [2005] clarified RCODE of NOTAUTH case. --- doc/guide/bind10-guide.xml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 7fbef0bdec..568b517ffc 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2210,7 +2210,9 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. secondary_zones configuration of b10-zonemgr. Zones listed in secondary_zones will never be updated via DDNS - regardless of the update ACL configuration. + regardless of the update ACL configuration; + b10-ddns 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 From abe48da05aa1625a942ff093058889fb7e822169 Mon Sep 17 00:00:00 2001 From: JINMEI Tatuya Date: Mon, 18 Jun 2012 16:17:16 -0700 Subject: [PATCH 26/30] [2005] updated date and history --- src/bin/ddns/b10-ddns.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/bin/ddns/b10-ddns.xml b/src/bin/ddns/b10-ddns.xml index a5a969d9cf..02879f489a 100644 --- a/src/bin/ddns/b10-ddns.xml +++ b/src/bin/ddns/b10-ddns.xml @@ -20,7 +20,7 @@ - February 28, 2012 + June 18, 2012 @@ -191,6 +191,7 @@ The b10-ddns daemon was first implemented in December 2011 for the ISC BIND 10 project. + The first functional version was released in June 2012.