DNS BIND zone clause
This section describes the zone clause which controls the properties and functionality associated with each zone. The zone clause may take many statements to provide a high degree of granularity. statements have global scope if they are specified in an options clause not associated with a particular zone. Using a statement in a zone clause means it is applicable only to that zone and will, for the specific zone, always override any global statement (defined in a options clause).
The zone clause can take any of the statements shown below, the items in square brackets after each statement indicate what other clauses the statement can appear in.
allow-notify { address_match_list }; [ Opt, View, Zone ]
allow-query { address_match_list }; [ Opt, View, Zone ]
allow-transfer { address_match_list }; [ Opt, View, Zone ]
allow-update { address_match_list }; [ Zone ]
allow-update-forwarding { address_match_list }; [ Opt, View, Zone ]
also-notify [port gp-num] [dscp gd-num] { (masters-list|IP-address )[port p-num] [dscp d-num]
[key key-name] ; [... ;] }; [ Opt, View, Zone ] BIND 9.9+
also-notify { ip_addr [port ip_port] ; ... ] }; [ Opt, View, Zone ] Pre BIND 9.9
alt-transfer-source ( ipv4 | * ) [ port ( integer | * )]; [ Opt, View, Zone ]
alt-transfer-source-v6 ( ipv6 | * ) [ port ( integer | * ) ]; [ Opt, View, Zone ]
check-names ( fail | warn | ignore ); [ Zone ]
database "database-name params"; [ Zone ]
delegation-only ( yes | no ) ; [ Zone ]
dialup dialup_options; [ Opt, View, Zone ]
file "file_name" ; [ Zone ]
forward ( only | first ); [ Opt, View, Zone ]
forwarders { ipv4_addr | ipv6_addr [port ip_port] ; ... ] }; [ Opt, View, Zone ]
in-view view-name; [ Zone ] [Def=N/A]
ixfr-from-differences ( yes | no); [ Opt, View, Zone ]
key-directory path_name; [ Opt, View, Zone ]
masterfile-format ( text|raw | map ); [ Opt, View, Zone ]
masters [port pg-port] [dscp dscp-num] {
( masters-list | ip-addr [port p-port] [dscp dscp-num] [key key-name] ) ; [...] } ; ] [ Zone ]
max-journal-size size_in_bytes; [ Opt, View, Zone ]
max-refresh-time seconds ; [ Opt, View, Zone ]
max-retry-time seconds ; [ Opt, View, Zone ]
max-transfer-idle-in minutes; [ Opt, View, Zone ]
max-transfer-idle-out minutes; [ Opt, View, Zone ]
max-transfer-time-in minutes; [ Opt, View, Zone ]
max-transfer-time-out minutes; [ Opt, View, Zone ]
min-refresh-time seconds ; [ Opt, View, Zone ]
min-retry-time seconds ; [ Opt, View, Zone ]
multi-master ( yes | no ) ; [ Opt, View, Zone ]
notify ( yes | no | explicit ); [ Opt, View, Zone ]
notify-source (ip4_addr | *) [port ip_port] ; [ Opt, View, Zone ]
notify-source-v6 (ip6_addr | *) [port ip_port] ; [ Opt, View, Zone ]
sig-validity-interval number ; [ Opt, View, Zone ]
sig-validity-interval days ; [ Opt, View, Zone ]
server-addresses server-addresses {ip-address; [...;]}; [ Zone ] [Def=N/A]
server-names { dom-name; [ ...; ] }; [ Zone ] [Def=N/A]
transfer-source (ip4_addr | *) [port ip_port] ; [ Opt, View, Zone ]
transfer-source-v6 (ip6_addr | *) [port ip_port] ; [ Opt, View, Zone ]
type zone_type; [ Zone ]
update-policy { update_policy_rule [...] }; [ Zone ]
use-alt-transfer-source ( yes | no ); [ Opt, View, Zone ]
zone-statistics ( yes | no ) ; [ Opt, View, Zone ]
zone Clause Syntax
zone "zone_name" [class] {
// zone statements
};
zone "example.com" {
....
};
The zone_name field is a quoted string and defines the zone to which the statements in this zone clause apply, for instance, "example.com". class is optional and if omitted class IN is defaulted.
check-names
check-names (warn|fail|ignore) ;
check-names fail;
The check-names statement will cause any host name for the zone to be checked for compliance with RFC 952 and RFC 1123 and take the defined action. Care should be taken when using this statement because many modern RRs, for example, SRV use names which do not meet these standards (they contain underscore) but which are permitted by RFC 2181 which greatly liberalized the rules for names (see labels and names). The default is not to perform host name checks. check-names may also appear in a view or options clause where it has a different syntax.
file
file "file_name";
file "slave/example.com";
Defines the file used by the zone in quoted string format, for instance, "slave/example.com" - or whatever convention you use. The file entry is mandatory for master and hint and optional - but highly recommended - for slave and not required for forward zones. The file may be an absolute path or relative to directory.
Note: If a type Slave has a file statement then any zone transfer will cause it to update this file. If the slave is reloaded then it will read this file and immediately start answering queries for the domain. If no file is specified it will immediately try to contact the Master and initiate a zone transfer. For obvious reasosn the Slave cannot to zone queries until this zone transfer is complete. If the Master is not available or the Slave fails to contact the Master, for whatever reason, the zone may be left with no effective Authoritative Name Servers.
// defines an optional slave file used to save zone data
type slave;
file "slave/example.com";
// defines a master zone file
type master;
file "master/example.net";
in-view
in-view "view-name";
in-view "internal";
BIND9.10+ only. Only valid within a zone clause. Allows a zone clause within one view to be used by another view. The view-name must refer to a valid view which contains a zone of the same name and the view containing the zone must have been previously defined (only backward references to views are allowed, not forward references). The in-view zone uses all the statements in the previously defined zone clause and thus is particularly useful if you defined a shed-load of stuff in the previous zone clause. Only forward and forwarders statements are allowed in in-view zone clauses. Example:
// defines an optional slave file used to save zone data
view "mordor" {
...
zone example.com {
// shed load of statements
// type may be master, slave etc.
...
};
};
view "gondor" {
...
zone example.com {
in-view "mordor";
// valid back-reference to previous defined view
// a forward reference to "khand" would fail
// forward and forwarders statements are allowed - nothing else
};
};
view "khand" {
...
zone example.com {
in-view "mordor";
};
};
masterfile-format text | raw | map;
masterfile-format map;
controls the format used to load the master file, May take the values text (default except for slaves where it is raw) indicating a normal text zones file, raw defines the binary zone format used in zone transfers and is selectively output from the named-compilezone utility and map is a (faster) alternative output from the named-compilezone utility consisting of a pure binary image of the zone used internally by BIND. The statement may appear in a zone, options or view clause.
masters
masters [port pg-num] [dscp dscp-num] { (masters-list | IP-address )[port p-num] [dscp dscp-num]
[key key-name] ; [... ;] };
masters port 11234 {ns1.example.com; ns2.example.com key zt-key; 2001:db8:0:1::34 port 57;};
The masters statement is valid only with slave zones and defines one or more IP addresses and optional port numbers of servers that hold the master zone file. The slave will use the defined IP address(es) to update the zone file when the SOA RR refresh parameter is reached (or a NOTIFY message is received). The pg-num parameter changes the port number used for zone transfers for all the listed servers (the default is port 53). The p-num parameter changes the port number for the specific IP address only. masters-list may be used to reference a list of masters defined in a masters clause. The key-name field defines the key to be used to authenticate the zone transfers when using TSIG and references the name of a key clause; a corresponding key clause with the same key-name must be present in the master server(s) for the zone. From BIND9.10 the statement also allows the use of a DiffServ Differentiated Service Code Point (DSCP) number (range 0 - 95, where supported by the OS) to be used to identify the traffic classification. The following example shows three masters for the zone, the first two will use port 1127 for zone transfers, the second will also use a TSIG key-name of zt-key and the IPv6 address will use port 1128:
// named.conf fragment
zone "example.com" in {
type slave;
file "slave/example.com";
masters port 1127 {192.168.2.7; 10.2.3.15 key zt-key; 2001:db8:0:1::15 port 1128;};
};
This example shows the usage with a master clause and an override to use port 1127 for all masters listed in the good-masters clause:
// named.conf fragment
masters good-masters {192.168.2.7;10.2.3.15;2001:db8:0:1::15};
...
zone "example.com" in {
type slave;
file "slave/example.com";
masters port 1127 {good-masters;};
};
server-addresses
server-addresses {ip-address; [...;]};
server-addresses { 192.168.2.57; 2001:db8:0:1;;17;};
BIND9.8+. Only used when zone type is static-stub. This defines the ip-address(es) (either IPv4 or IPv6) that will be configured as glue RRs using A (IPv4) or AAAA (IPv6) for the name server either defined by the server-names or in its absence for a name server at the apex of the static-stub zone. Example with no server-names:
...
zone example.com {
type static-stub;
server-addresses { 192.168.2.57; 2001:db8:0:1::17;};
};
; server synthesizes static-stub zone
$ORIGIN example.com.
...
NS example.com.
example.com. A 192.168.2.57 ; glue record
example.com. AAAA 2001:db8:0:1::17 ; glue record
server-names
server-names { dom-name; [ ...; ] };
server-names { ns2.example.org;ns34.example.net;};
BIND9.8+. Only used when zone type is static-stub. This defines one or more dom-name(es) that will be synthesized as the NS RR(a) for the zone. If no server-addresses are defined then these names must be out-of-zone static-stub zone to allow A/AAAA resolution (inside the zone they would require glue A/AAAA records. Example with no server-addresses:
...
zone example.com {
type static-stub;
server-names { ns2.example.org;ns34.example.net;};
};
; server synthesizes static-stub zone
$ORIGIN example.com.
...
example.com. NS ns2.example.org.
example.com. NS ns34.example.net.
type
type zone_type;
type forward;
Where zone_type may take one of the following values:
| delegation-only |
Indicates only referrals (or delegations) will be issued for the zone and should used for TLDs only not leaf (non TLD) zones. The generation of referrals in leaf zones is determined by the RRs contained in it (see Chapter 9 Delegation of Sub-domains).
|
| forward |
A zone of type forward is simply a way to configure forwarding on a per-domain or per zone basis. To be effective both a forward and forwarders statement should be included. If no forwarders statement is present or an empty list is provided then no forwarding will be done for the domain canceling the effects of any forwarders in the options clause. |
| hint |
The initial set of root-servers is defined using a hint zone. When the server starts up it uses the hints zone file to find a root name server and get the most recent list of root name servers. If no hint zone is specified for class IN, the server uses a compiled-in default set of root servers. Classes other than IN have no built-in defaults hints. 'hint' zone files are covered in more detail under required zones. |
| in-view |
Not valid for the type statement but removes the need for any type definition. See in-view statement. |
| master |
The server reads the zone data direct from local storage (a zone file) and provides authoritative answers for the zone. |
| redirect |
BIND9.9+. Applicable to recursive servers (resolvers) only. Allows the user to control the behavior of (to redirect) an NXDOMAIN response received only from a non-DNSSEC (unsigned) zone (that is, the NXDOMAIN response is not signed - it is not a PNE response) for certain users, controlled by an allow-query statement, or certain zones defined in a normal zone file specified by a file statement. The zone files used are not visible in any normal manner (they cannot be explicitly queried, addressed for the purposes of zone transfer or from rndc) but are in all other respects normal zone files. This is a very powerful feature and should be used with caution. For example, if an ISP in Argentina wished to promote an Argentinian Registration service (country code .ar) then it could define the following:
// snippet from recursive named.conf
...
zone "ar" {
type redirect;
file "ar.zone";
allow-query {any;}; ; all users
; this is not an OPEN resolver since the any
; applies only to NXDOMAIN responses
; the initial query scope (defined in the options clause)
; determines the OPEN/CLOSED status
};
...
; ar.zone zone file snippet
;
$ORIGIN ar.
...
; uses wildcard to soak up all responses for any .ar domain
*.ar. A 192.168.2.3 ; web service
;OR
*.ar. NS ns.example.ar.
...
If a web service is configured at 192.168.2.3 then it could, as an example, return a page offering to register this domain name, or it could simply make a benign service announcement suggesting some corrective action, or as in the second option it could point at a name server which could take some domain name specific action. The scope of the zone file is essentially unlimited thus, a zone "." clause (not to be confused with a hints file which would use type hints; not type redirect;) would pick up all NXDOMAINs for any TLD, whereas a zone "co.uk" clause would only pick up commercial domain names in the UK.
Only a single redirect zone is allowed or when used with view clauses only a single redirect per view. (Only the file, allow-query and masterfile-format statements are allowed i redirect zone clauses.)
|
| slave |
A slave zone is a replica of the master zone and obtains its zone data by zone transfer operations. The slave will respond authoritatively for the zone as long as it has valid (not timed out) zone data defined by the expiry parameter of the SOA RR. The mandatory masters statement specifies one or more IP addresses of master servers that the slave contacts to refresh or update its copy of the zone data. When the TTL specified by the refresh parameter is reached the slave will query the SOA RR from the zone master. If the sn paramater (serial number) is greater than the current value a zone tansfer is initiated. If the slave cannot obtain a new copy of the zone data when the SOA expiry value is reached then it will stop responding for the zone. Authentication between the zone slave and zone master can be performed with per-server TSIG keys (see masters statement). By default zone transfers are made using port 53 but this can be changed using the masters statement. If an optional file statement is defined then the zone data will be written to this file whenever the zone is changed and reloaded from this file on a server restart. If the file statement is not present then the slave cannot respond to zone queries until it has carried out a zone transfer, thus, if the zone master is unavailable on a slave load the slave cannot respond to queries for the zone. |
| static-stub |
A stub zone is similar to a slave zone except that it replicates only the NS records of a master zone instead of the entire zone (essentially providing a referral only service). Unlike Stub zones which take their NS RRs from the real zone master Static-Stub zones allow the user to configure the NS RRs (using server-names) or addresses (using server-addresses) that will be provided in the referral (overriding any valid data in the cache). The net effect of the static-stub is that the user is enabled (in a recursive resolver) to redirect a zone, whether for good or evil purposes is a local decision. (In addition to server-names and server-addresses only allow-query and zone-statistics statements are allowed when type static-stub; is present.)
|
| stub |
A stub zone is similar to a slave zone except that it replicates only the NS records of a master zone instead of the entire zone (essentially providing a referral only service). Stub zones are not a standard part of the DNS they are a feature specific to the BIND implementation and should not be used unless there is a specific requirement.
|
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.
