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 [ Zone ] [Def=N/A] 
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

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.