From: JINMEI Tatuya Date: Fri, 15 Jun 2012 06:02:58 +0000 (-0700) Subject: [2005] added a chapter for DDNS to BIND 10 guide. X-Git-Tag: trac2351_base~226^2~29^2~28 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=35eab8559632ab2cd0f1f32cb1c2db594b050e24;p=thirdparty%2Fkea.git [2005] added a chapter for DDNS to BIND 10 guide. --- 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