Zone Config
From: https://bind9.readthedocs.io/en/v9_18_4/chapter3.html 




3. Configurations and Zone Files




3.1. Introduction
BIND 9 uses a single configuration file called named.conf. named.conf is 
typically located in either:
/etc/namedb 
or 
/usr/local/etc/namedb.

Note
If rndc is being used locally (on the same host as BIND 9) then an 
additional file rndc.conf may be present, though rndc operates without this 
file. If rndc is being run from a remote host then an rndc.conf file must be 
present as it defines the link characteristics and properties.


Depending on the functionality of the system, one or more zone files is required.

The samples given throughout this and subsequent chapters use a standard base 
format for both the named.conf and the zone files for example.com. The intent is
for the reader to see the evolution from a common base as features are added or
removed.



3.1.1. named.conf Base File

This file illustrates the typical format and layout style used for named.conf 
and provides a basic logging service, which may be extended as required by the 
user.

// base named.conf file
// RECOMMENDED THAT YOU ALWAYS MAINTAIN A CHANGE LOG IN THIS FILE AS SHOWN HERE
// OPTIONS CLAUSE DEFINING THE SERVER-WIDE PROPERTIES
options 
{
  // ALL RELATIVE PATHS USE THIS DIRECTORY AS A BASE
  directory "/var";
  // VERSION STATEMENT FOR SECURITY TO AVOID HACKING KNOWN WEAKNESSES
  // IF THE REAL VERSION NUMBER IS REVEALED
  version "not currently available";
};
// logging clause
// log to /var/log/named/example.log ALL EVENTS FROM INFO UP IN SEVERITY (NO DEBUG)
// USES 3 FILES IN ROTATION SWAPS FILES WHEN SIZE REACHES 250K
// FAILURE MESSAGES THAT OCCUR BEFORE LOGGING IS ESTABLISHED ARE
// IN SYSLOG (/var/log/messages)
//
logging 
{
	channel example_log 
	{
		// USES A RELATIVE PATH NAME AND THE DIRECTORY STATEMENT TO
		// EXPAND TO /var/log/named/example.log
		file "log/named/example.log" versions 3 size 250k;
		// ONLY LOG INFO AND UP MESSAGES - ALL OTHERS DISCARDED
		severity info;
	};
	category default 
	{
		example_log;
	};
};

The logging and options clauses and category, channel, directory, file, and 
severity statements are all described further in the appropriate sections of 
this ARM.



3.1.2. example.com base zone file
The following is a complete zone file for the domain example.com, which 
illustrates a number of common features. Comments in the file explain these 
features where appropriate. Zone files consist of Resource Records (RR), which 
describe the zone’s characteristics or properties.

; base zone file for example.com
$TTL 2d    ; default TTL for zone
$ORIGIN example.com. ; base domain-name
; Start of Authority RR defining the key characteristics of the zone (domain)
@         IN      SOA   ns1.example.com. hostmaster.example.com. (
							2003080800 ; serial number
							12h        ; refresh
							15m        ; update retry
							3w         ; expiry
							2h         ; minimum
							)
; name server RR for the domain
	   IN      NS      ns1.example.com.
; the second name server is external to this zone (domain)
	   IN      NS      ns2.example.net.
; mail server RRs for the zone (domain)
	3w IN      MX  10  mail.example.com.
; the second  mail servers is  external to the zone (domain)
	   IN      MX  20  mail.example.net.
; domain hosts includes NS and MX records defined above
; plus any others required
; for instance a user query for the A RR of joe.example.com will
; return the IPv4 address 192.168.254.6 from this zone file
ns1        IN      A       192.168.254.2
mail       IN      A       192.168.254.4
joe        IN      A       192.168.254.6
www        IN      A       192.168.254.7
; aliases ftp (ftp server) to an external domain
ftp        IN      CNAME   ftp.example.net. 

This type of zone file is frequently referred to as a forward-mapped zone file,
since it maps domain names to some other value, while a reverse-mapped zone file
maps an IP address to a domain name. The zone file is called example.com for no
good reason except that it is the domain name of the zone it describes; as 
always, users are free to use whatever file-naming convention is appropriate to
their needs.



3.1.3. Other Zone Files
Depending on the configuration additional zone files may or should be present. 
Their format and functionality are briefly described here.



3.1.4. localhost Zone File
All end-user systems are shipped with a hosts file (usually located in /etc). 
This file is normally configured to map the name localhost (the name used by 
applications when they run locally) to the loopback address. It is argued, 
reasonably, that a forward-mapped zone file for localhost is therefore not 
strictly required. This manual does use the BIND 9 distribution file 
localhost-forward.db (normally in 
/etc/namedb/master 
or 
/usr/local/etc/namedb/master) 
in all configuration samples for the following reasons:

Users may, however, elect at their discretion not to implement this file since,
depending on the operational environment, it may not be essential.

The BIND 9 distribution file localhost-forward.db format is shown for 
completeness and provides for both IPv4 and IPv6 localhost resolution. The zone 
(domain) name is localhost.
$TTL 3h
localhost.  SOA      localhost.  nobody.localhost. 42  1d  12h  1w  3h
            NS       localhost.
            A        127.0.0.1
            AAAA     ::1 

Note
Readers of a certain age or disposition may note the reference in this file to 
the late, lamented Douglas Noel Adams.




3.1.5. localhost Reverse-Mapped Zone File
This zone file allows any query requesting the name associated with the loopback
IP (127.0.0.1). This file is required to prevent unnecessary queries from 
reaching the public DNS hierarchy. The BIND 9 distribution file localhost.rev is
shown for completeness:

$TTL 1D
@        IN        SOA  localhost. root.localhost. (
                        2007091701 ; serial
                        30800      ; refresh
                        7200       ; retry
                        604800     ; expire
                        300 )      ; minimum
         IN        NS    localhost.
1        IN        PTR   localhost. 




3.2. Authoritative Name Servers

These provide authoritative answers to user queries for the zones they support:
for instance, the zone data describing the domain name example.com. An 
authoritative name server may support one or many zones.

Each zone may be defined as either a primary or a secondary. A primary zone 
reads its zone data directly from a file system. A secondary zone obtains its 
zone data from the primary zone using a process called zone transfer. Both the 
primary and the secondary zones provide authoritative data for their zone; there
is no difference in the answer to a query from a primary or a secondary zone. An
authoritative name server may support any combination of primary and secondary 
zones.

Note
The terms primary and secondary do not imply any access priority. Resolvers 
(name servers that provide the complete answers to user queries) are not aware 
of (and cannot find out) whether an authoritative answer comes from the primary
or secondary name server. Instead, the resolver uses the list of authoritative 
servers for the zone (there must be at least two) and maintains a Round Trip 
Time (RTT) - the time taken to respond to the query - for each server in the 
list. The resolver uses the lowest-value server (the fastest) as its preferred 
server for the zone and continues to do so until its RTT becomes higher than the
next slowest in its list, at which time that one becomes the preferred server.

For reasons of backward compatibility BIND 9 treats “primary” and “master” as 
synonyms, as well as “secondary” and “slave.”

The following diagram shows the relationship between the primary and secondary 
name servers. The text below explains the process in detail.


Authoritative Primary and Secondary Name Servers

The numbers in parentheses in the following text refer to the numbered items in 
the diagram above.

The authoritative samples all use NOTIFY but identify the statements used, so 
that they can be removed if not required.




3.2.1. Primary Authoritative Name Server

The zone files are unmodified from the base samples but the named.conf file has 
been modified as shown:

// authoritative primary named.conf file
// options clause defining the server-wide properties
options 
{
	// ALL RELATIVE PATHS USE THIS DIRECTORY AS A BASE
	directory "/var";
	// VERSION STATEMENT FOR SECURITY TO AVOID HACKING KNOWN WEAKNESSES
	// IF THE REAL VERSION NUMBER IS REVEALED
	version "not currently available";
	// THIS IS THE DEFAULT - ALLOWS USER QUERIES FROM ANY IP
	allow-query { any; };
	// NORMAL SERVER OPERATIONS MAY PLACE ITEMS IN THE CACHE
	// THIS PREVENTS ANY USER QUERY FROM ACCESSING THESE ITEMS
	// ONLY AUTHORITATIVE ZONE DATA WILL BE RETURNED
	allow-query-cache { none; };
	// DO NOT PROVIDE RECURSIVE SERVICE TO USER QUERIES
	recursion no;
};
// LOGGING CLAUSE
// LOG TO /var/log/named/example.log ALL EVENTS FROM INFO UP IN SEVERITY (NO DEBUG)
// USES 3 FILES IN ROTATION SWAPS FILES WHEN SIZE REACHES 250K
// FAILURE MESSAGES THAT OCCUR BEFORE LOGGING IS ESTABLISHED ARE
// IN SYSLOG (/var/log/messages)
//
logging 
{
	channel example_log 
	{
		// USES A RELATIVE PATH NAME AND THE DIRECTORY STATEMENT TO
		// EXPAND TO /var/log/named/example.log
		file "log/named/example.log" versions 3 size 250k;
		// ONLY LOG INFO AND UP MESSAGES - ALL OTHERS DISCARDED
		severity info;
	};
	category default 
	{
		example_log;
	};
};
// PROVIDE FORWARD MAPPING ZONE FOR LOCALHOST
// (OPTIONAL)
zone "localhost" 
{
	type primary;
	file "master/localhost-forward.db";
	notify no;
};
// PROVIDE REVERSE MAPPING ZONE FOR LOOPBACK
// ADDRESS 127.0.0.1
zone "0.0.127.in-addr.arpa" 
{
	type primary;
	file "localhost.rev";
	notify no;
};
// THE PRIMARY SERVER FOR example.com
zone "example.com" 
{
	// THIS IS PRIMARY NAME SERVER FOR ZONE
	type primary;
	file "example.com";
	// THIS IS DEFAULT
	notify yes;
	// IP ADDRESSES OF SECONDARY SERVERS ALLOWED TO
	// TRANSFER example.com FROM THIS SERVER
	allow-transfer 
	{
		192.168.4.14;
		192.168.5.53;
	};
};

The added statements and clauses are commented in the above file.

The zone clause, and allow-query, allow-query-cache, allow-transfer, file, 
notify, recursion, and type statements are described in detail in the 
appropriate sections.



3.2.2. Secondary Authoritative Name Server

The zone files local-host-forward.db and localhost.rev are unmodified from the 
base samples. The example.com zone file is not required (the zone file is 
obtained from the primary via zone transfer). The named.conf file has been 
modified as shown:

// AUTHORITATIVE SECONDARY named.conf FILE
// OPTIONS CLAUSE DEFINING THE SERVER-WIDE PROPERTIES
options {
  // ALL RELATIVE PATHS USE THIS DIRECTORY AS A BASE
  directory "/var";
  // VERSION STATEMENT FOR SECURITY TO AVOID HACKING KNOWN WEAKNESSES
  // IF THE REAL VERSION NUMBER IS REVEALED
  version "not currently available";
  // THIS IS THE DEFAULT - ALLOWS USER QUERIES FROM ANY IP
  allow-query { any; };
  // NORMAL SERVER OPERATIONS MAY PLACE ITEMS IN THE CACHE
  // THIS PREVENTS ANY USER QUERY FROM ACCESSING THESE ITEMS
  // only authoritative zone data will be returned
  allow-query-cache { none; };
  // DO NOT PROVIDE RECURSIVE SERVICE TO USER QUERIES
  recursion no;
};
// LOGGING CLAUSE
// LOG TO /var/log/named/example.log ALL EVENTS FROM INFO UP IN SEVERITY (NO DEBUG)
// USES 3 FILES IN ROTATION SWAPS FILES WHEN SIZE REACHES 250K
// FAILURE MESSAGES THAT OCCUR BEFORE LOGGING IS ESTABLISHED ARE
// IN SYSLOG (/var/log/messages)
//
logging 
{
	channel example_log 
	{
		// USES A RELATIVE PATH NAME AND THE DIRECTORY STATEMENT TO
		// EXPAND TO /var/log/named/example.log
		file "log/named/example.log" versions 3 size 250k;
		// ONLY LOG INFO AND UP MESSAGES - ALL OTHERS DISCARDEd
		severity info;
	};
	category default 
	{
		example_log;
	};
};
// PROVIDE FORWARD MAPPING ZONE FOR LOCALHOST
// (OPTIONAL)
zone "localhost" 
{
	type primary;
	file "master/localhost-forward.db";
	notify no;
};
// PROVIDE REVERSE MAPPING ZONE FOR THE LOOPBACK ADDRESS 127.0.0.1
zone "0.0.127.in-addr.arpa" 
{
	type primary;
	file "localhost.rev";
	notify no;
};
// THE SECONDARY SERVER FOR example.com
zone "example.com" 
{
	// THIS IS A SECONDARY SERVER FOR THE ZONE
	type secondary;
	// THE FILE STATEMENT HERE ALLOWS THE SECONDARY TO SAVE
	// EACH ZONE TRANSFER SO THAT IN THE EVENT OF A PROGRAM RESTART
	// THE ZONE CAN BE LOADED IMMEDIATELY AND THE SERVER CAN START
	// TO RESPOND TO QUERIES WITHOUT WAITING FOR A ZONE TRANSFER
	file "example.com.saved";
	// IP ADDRESS OF example.com PRIMARY SERVER
	primaries { 192.168.254.2; };
};

The statements and clauses added are all commented in the above file.

The zone clause, and allow-query, allow-query-cache, allow-transfer, file, 
notify, primaries, recursion, and type statements are described in detail in the
appropriate sections.

If NOTIFY is not being used, no changes are required in this named.conf file, 
since it is the primary that initiates the NOTIFY message.

Note
Just when the reader thought they understood primary and secondary, things can 
get more complicated. A secondary zone can also be a primary to other 
secondaries: named, by default, sends NOTIFY messages for every zone it loads. 
Specifying notify primary-only; in the zone clause for the secondary causes 
named to only send NOTIFY messages for primary zones that it loads.





3.3. Resolver (Caching Name Servers)

Resolvers handle recursive user queries and provide complete answers; that is, 
they issue one or more iterative queries to the DNS hierarchy. Having obtained a
complete answer (or an error), a resolver passes the answer to the user and 
places it in its cache. Subsequent user requests for the same query will be 
answered from the resolver’s cache until the TTL of the cached answer has 
expired, when it will be flushed from the cache; the next user query that 
requests the same information results in a new series of queries to the DNS 
hierarchy.

Resolvers are frequently referred to by a bewildering variety of names, 
including caching name servers, recursive name servers, forwarding resolvers, 
area resolvers, and full-service resolvers.

The following diagram shows how resolvers can function in a typical networked 
environment:

_images/resolver-forward.png
Resolver and Forwarding Resolver