From: Michal 'vorner' Vaner Date: Mon, 6 Aug 2012 11:40:11 +0000 (+0200) Subject: [2066] docs: Update links to the ACL chapter X-Git-Tag: trac2351_base~65^2~34^2^2~10 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=762239bdb617fcd2a3a737470f52aa5b5b70ccb9;p=thirdparty%2Fkea.git [2066] docs: Update links to the ACL chapter Instead of talking the same over and over again, we now link the common ACL chapter. --- diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 65606c3d4b..5df1c5c405 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -2073,37 +2073,22 @@ http://bind10.isc.org/wiki/ScalableZoneLoadDesign#a7.2UpdatingaZone can be used to control accessibility of the outbound zone transfer service. By default, b10-xfrout allows any clients to - perform zone transfers for any zones: + perform zone transfers for any zones. > config show Xfrout/transfer_acl Xfrout/transfer_acl[0] {"action": "ACCEPT"} any (default) - You can change this to, for example, rejecting all transfer - requests by default while allowing requests for the transfer - of zone "example.com" from 192.0.2.1 and 2001:db8::1 as follows: + You can configure it the same as any ACL + (). - > config set Xfrout/transfer_acl[0] {"action": "REJECT"} -> config add Xfrout/zone_config -> config set Xfrout/zone_config[0]/origin "example.com" -> config set Xfrout/zone_config[0]/transfer_acl [{"action": "ACCEPT", "from": "192.0.2.1"}, - {"action": "ACCEPT", "from": "2001:db8::1"}] -> config commit - - - In the above example the lines - for were divided for - readability. In the actual input it must be in a single line. - - If you want to require TSIG in access control, a system wide TSIG "key ring" must be configured. - For example, to change the previous example to allowing requests - from 192.0.2.1 signed by a TSIG with a key name of - "key.example", you'll need to do this: + In this example, we allow client matching both the IP address + and key. > config set tsig_keys/keys ["key.example:<base64-key>"] @@ -2320,29 +2305,7 @@ 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 a new rule to - the 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. - -> 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 - - (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.) + Full description of ACLs can be found in . @@ -2357,21 +2320,6 @@ 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. - - - - - 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 @@ -2511,59 +2459,9 @@ DDNS/zones[0]/update_acl[1] {"action": "ACCEPT", "from": "::1", "key": "key. DNS queries from the localhost (127.0.0.1 and ::1). The configuration may be used to reject, drop, or allow specific IPs or networks. - This configuration list is first match. + See . - - The configuration's item may be - set to ACCEPT to allow the incoming query, - REJECT to respond with a DNS REFUSED return - code, or DROP to ignore the query without - any response (such as a blackhole). For more information, - see the respective debugging messages: RESOLVER_QUERY_ACCEPTED, - RESOLVER_QUERY_REJECTED, - and RESOLVER_QUERY_DROPPED. - - - - The required configuration's item is set - to an IPv4 or IPv6 address, addresses with an network mask, or to - the special lowercase keywords any6 (for - any IPv6 address) or any4 (for any IPv4 - address). - - - - - - For example to allow the 192.168.1.0/24 - network to use your recursive name server, at the - bindctl prompt run: - - - -> config add Resolver/query_acl -> config set Resolver/query_acl[2]/action "ACCEPT" -> config set Resolver/query_acl[2]/from "192.168.1.0/24" -> config commit - - - (Replace the 2 - as needed; run config show - Resolver/query_acl if needed.) - - - This prototype access control configuration - syntax may be changed. -