BIND Definition of Address List Match

This section defines the term 'address_list_match' used with many statements. Full list of options statements. The full syntax allows many variations:

address_match_list = element ; [ element; ... ]

An address_match_list is comprised of one or more elements each of which has the following syntax:

element = [!] (ip [/prefix] | key key_id | "acl_name" | { address_match_list } )

The elements which make up an address match list can be:

• Optional negation ("!") of an element

• An IP address (IPv4 or IPv6)

• An IP prefix (in the `/'-notation) e.g. 10.0.0.0/16
• A key ID, as defined by the key clause
• The name of an address_match_list previously defined with an acl clause or one of four predefined names
• A nested address match list enclosed in braces

The four predefined address_match_list names are:

• "none" - matches no hosts
• "any" - matches all hosts
• "localhost" - matches all the IP address(es) of the server on which BIND is running e.g. if the server has a single interface with an IP address of 192.168.2.3 then localhost will match 192.168.2.3 and 127.0.0.1 (the loopback address is always present).
• "localnets" - matches all the IP address(es) and subnetmasks of the server on which BIND is running i.e. if the server has a single interface with an IP address of 192.168.2.3 and a netmask of 255.255.255.0 (or 192.168.2.2/24) then localnets will match 192.168.2.0 to 192.168.2.255 and 127.0.0.1 (the loopback is assumed to be a single address). Some systems do not provide a way to determine the prefix lengths of local IPv6 addresses. In such a case, localnets only matches the local IPv6 addresses, just like localhost.

One of the main uses for address_match_lists is with IP addresses for access control. When a given IP address is compared to an address_match_list the list is traversed in order until an element matches at which point processing stops. The action taken will depend on the context of the statement to which it is being applied as shown in the following example:

options {
    allow-transfer { !192.168.2.7;192.168.2.3/24;};
};

If the IP address 192.168.2.47 requests a transfer it does not match the first element but matches the second element and the transfer is permitted, if however the IP 192.168.2.7 requests a transfer it matches the first element which is negated meaning the transfer is denied. Because a match stops processing the match order is significant. If the above were rewritten to reverse the order then 192.168.2.7 would always be permitted to transfer because the first item always matches:

options {
     allow-transfer {192.168.2.3/24; !192.168.2.7;};
};

The general rule may be expressed as "a non-negated match permits the operation and a negated match denies the operation, if there is no match the operation is denied". The following example shows the use of an acl clause to standardize an address_match_list by simply changing the contents of the acl these changes are propagated to all users of the acl clause:

acl "good-guys" {
     !192.169.2.5/28; // denies first 16 IPs
     192.168.2.5/24;  // allows rest of subnet
     localnets;   // allows our network
     2001:db8:0:1::/64; // allows this subnet only
};
options {
      allow-transfer {"good-guys";};
};

The key_id parameter allows the address_match_list to reference a key clause - the match in this case will occur if the keys match.

Nesting is generally only used with the topology (not currently implemented) and the sortlist statement and the address_match_list behavior is slightly changed. Nesting use is described in the context of the sortlist statement.

---

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.