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.
Depending on the functionality of the system, one or more zone files is required.
The samples used 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.
1// base named.conf file
2// Recommended that you always maintain a change log in this file as shown here
3// options clause defining the server-wide properties
4options {
5 // all relative paths use this directory as a base
6 directory "/var";
7 // version statement for security to avoid hacking known weaknesses
8 // if the real version number is revealed
9 version "not currently available";
10};
11
12// logging clause
13// log to /var/log/named/example.log all events from info UP in severity (no debug)
14// uses 3 files in rotation swaps files when size reaches 250K
15// failure messages that occur before logging is established are
16// in syslog (/var/log/messages)
17//
18logging {
19 channel example_log {
20 // uses a relative path name and the directory statement to
21 // expand to /var/log/named/example.log
22 file "log/named/example.log" versions 3 size 250k;
23 // only log info and up messages - all others discarded
24 severity info;
25 };
26 category default {
27 example_log;
28 };
29};
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.
1; base zone file for example.com
2$TTL 2d ; default TTL for zone
3$ORIGIN example.com. ; base domain-name
4; Start of Authority RR defining the key characteristics of the zone (domain)
5@ IN SOA ns1.example.com. hostmaster.example.com. (
6 2003080800 ; serial number
7 12h ; refresh
8 15m ; update retry
9 3w ; expiry
10 2h ; minimum
11 )
12; name server RR for the domain
13 IN NS ns1.example.com.
14; the second name server is external to this zone (domain)
15 IN NS ns2.example.net.
16; mail server RRs for the zone (domain)
17 3w IN MX 10 mail.example.com.
18; the second mail servers is external to the zone (domain)
19 IN MX 20 mail.example.net.
20; domain hosts includes NS and MX records defined above
21; plus any others required
22; for instance a user query for the A RR of joe.example.com will
23; return the IPv4 address 192.168.254.6 from this zone file
24ns1 IN A 192.168.254.2
25mail IN A 192.168.254.4
26joe IN A 192.168.254.6
27www IN A 192.168.254.7
28; aliases ftp (ftp server) to an external domain
29ftp 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:
Many users elect to delete the
hosts
file for security reasons (it is a potential target of serious domain name redirection/poisoning attacks).Systems normally lookup any name (including domain names) using the
hosts
file first (if present), followed by DNS. However, thensswitch.conf
file (typically in /etc) controls this order (normally hosts: file dns), allowing the order to be changed or the file value to be deleted entirely depending on local needs. Unless the BIND administrator controls this file and knows its values, it is unsafe to assume that localhost is forward-mapped correctly.As a reminder to users that unnecessary queries for localhost form a non-trivial volume of DNS queries on the public network, which affects DNS performance for all users.
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.
1$TTL 3h
2localhost. SOA localhost. nobody.localhost. 42 1d 12h 1w 3h
3 NS localhost.
4 A 127.0.0.1
5 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:
1$TTL 1D
2@ IN SOA localhost. root.localhost. (
3 2007091701 ; serial
4 30800 ; refresh
5 7200 ; retry
6 604800 ; expire
7 300 ) ; minimum
8 IN NS localhost.
91 IN PTR localhost.
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](_images/resolver-forward.png)
Resolver and Forwarding Resolver
End-user systems are all distributed with a local stub resolver as a standard feature. Today, the majority of stub resolvers also provide a local cache service to speed up user response times.
A stub resolver has limited functionality; specifically, it cannot follow referrals. When a stub resolver receives a request for a name from a local program, such as a browser, and the answer is not in its local cache, it sends a recursive user query (1) to a locally configured resolver (5), which may have the answer available in its cache. If it does not, it issues iterative queries (2) to the DNS hierarchy to obtain the answer. The resolver to which the local system sends the user query is configured, for Linux and Unix hosts, in
/etc/resolv.conf
; for Windows users it is configured or changed via the Control Panel or Settings interface.Alternatively, the user query can be sent to a forwarding resolver (4). Forwarding resolvers on first glance look fairly pointless, since they appear to be acting as a simple pass-though and, like the stub resolver, require a full-service resolver (5). However, forwarding resolvers can be very powerful additions to a network for the following reasons:
Cost and Performance. Each recursive user query (1) at the forwarding resolver (4) results in two messages - the query and its answer. The resolver (5) may have to issue three, four, or more query pairs (2) to get the required answer. Traffic is reduced dramatically, increasing performance or reducing cost (if the link is tariffed). Additionally, since the forwarding resolver is typically shared across multiple hosts, its cache is more likely to contain answers, again improving user performance.
Network Maintenance. Forwarding resolvers (4) can be used to ease the burden of local administration by providing a single point at which changes to remote name servers can be managed, rather than having to update all hosts. Thus, all hosts in a particular network section or area can be configured to point to a forwarding resolver, which can be configured to stream DNS traffic as desired and changed over time with minimal effort.
Sanitizing Traffic. Especially in larger private networks it may be sensible to stream DNS traffic using a forwarding resolver structure. The forwarding resolver (4) may be configured, for example, to handle all in-domain traffic (relatively safe) and forward all external traffic to a hardened resolver (5).
Stealth Networks. Forwarding resolvers are extensively used in stealth or split networks.
Forwarding resolvers (4) can be configured to forward all traffic to a resolver (5), or to only forward selective traffic (5) while directly resolving other traffic (3).
Attention
While the diagram above shows recursive user queries arriving via interface (1), there is nothing to stop them from arriving via interface (2) via the public network. If no limits are placed on the source IPs that can send such queries, the resolver is termed an open resolver. Indeed, when the world was young this was the way things worked on the Internet. Much has changed and what seems to be a friendly, generous action can be used by rogue actors to cause all kinds of problems including Denial of Service (DoS) attacks. Resolvers should always be configured to limit the IP addresses that can use their services. BIND 9 provides a number of statements and clauses to simplify defining these IP limits and configuring a closed resolver. The resolver samples given here all configure closed resolvers using a variety of techniques.
3.3.1. Additional Zone Files
3.3.1.1. Root Servers (Hint) Zone File
Resolvers (although not necessarily forwarding resolvers) need to access the
DNS hierarchy. To do this, they need to know the addresses (IPv4 and/or IPv6)
of the 13 root servers. This is done by the provision of a
root server zone file, which is contained in the standard BIND 9 distribution
as the file named.root
(normally found in /etc/namedb or
/usr/local/namedb). This file may also be obtained from the IANA website
(https://www.iana.org/domains/root/files).
Note
Many distributions rename this file for historical reasons. Consult the appropriate distribution documentation for the actual file name.
The zone file is defined using the type hint; statement and using a zone (domain) name of “.” (the generally silent dot).
Note
The root server IP addresses have been stable for a number of years and are likely to remain stable for the near future. BIND 9 has a root-server list in its executable such that even if this file is omitted, out-of-date, or corrupt BIND 9 can still function. For this reason, many sample configurations omit the hints file. All the samples given here include the hints file primarily as a reminder of the functionality of the configuration, rather than as an absolute necessity.
3.3.1.2. Private IP Reverse Map Zone Files
Resolvers are configured to send iterative queries to the public DNS hierarchy when the information requested is not in their cache or not defined in any local zone file. Many networks make extensive use of private IP addresses (defined by RFC 1918, RFC 2193, RFC 5737, and RFC 6598). By their nature these IP addresses are forward-mapped in various user zone files. However, certain applications may issue reverse map queries (mapping an IP address to a name). If the private IP addresses are not defined in one or more reverse-mapped zone file(s), the resolver sends them to the DNS hierarchy where they are simply useless traffic, slowing down DNS responses for all users.
Private IP addresses may be defined using standard reverse-mapping
techniques or using the
empty-zones-enable statement. This statement is by
default set to empty-zones-enable yes;
and thus automatically prevents
unnecessary DNS traffic by sending an NXDOMAIN error response (indicating the
name does not exist) to any request. However, some applications may require a
genuine answer to such reverse-mapped requests or they will fail to function.
Mail systems in particular perform reverse DNS queries as a first-line spam
check; in this case a reverse-mapped zone file is essential. The sample
configuration files given here for both the resolver and the forwarding
resolver provide a reverse-mapping zone file for the private IP address
192.168.254.4, which is the mail server address in the base zone
file, as an illustration of the reverse-map technique. The
file is named 192.168.254.rev
and has a zone name of
254.168.192.in-addr.arpa.
1; reverse map zone file for 192.168.254.4 only
2$TTL 2d ; 172800 seconds
3$ORIGIN 254.168.192.IN-ADDR.ARPA.
4@ IN SOA ns1.example.com. hostmaster.example.com. (
5 2003080800 ; serial number
6 3h ; refresh
7 15m ; update retry
8 3w ; expiry
9 3h ; nx = nxdomain ttl
10 )
11; only one NS is required for this local file
12; and is an out of zone name
13 IN NS ns1.example.com.
14; other IP addresses can be added as required
15; this maps 192.168.254.4 as shown
164 IN PTR mail.example.com. ; fully qualified domain name (FQDN)
3.3.2. Resolver Configuration
The resolver provides recursive query support to a defined set of IP addresses. It is therefore a closed resolver and cannot be used in wider network attacks.
1// resolver named.conf file
2// Two corporate subnets we wish to allow queries from
3// defined in an acl clause
4acl corpnets {
5 192.168.4.0/24;
6 192.168.7.0/24;
7};
8
9// options clause defining the server-wide properties
10options {
11 // all relative paths use this directory as a base
12 directory "/var";
13 // version statement for security to avoid hacking known weaknesses
14 // if the real version number is revealed
15 version "not currently available";
16 // this is the default
17 recursion yes;
18 // recursive queries only allowed from these ips
19 // and references the acl clause
20 allow-query { corpnets; };
21 // this ensures that any reverse map for private IPs
22 // not defined in a zone file will *not* be passed to the public network
23 // it is the default value
24 empty-zones-enable yes;
25};
26
27// logging clause
28// log to /var/log/named/example.log all events from info UP in severity (no debug)
29// uses 3 files in rotation swaps files when size reaches 250K
30// failure messages that occur before logging is established are
31// in syslog (/var/log/messages)
32//
33logging {
34 channel example_log {
35 // uses a relative path name and the directory statement to
36 // expand to /var/log/named/example.log
37 file "log/named/example.log" versions 3 size 250k;
38 // only log info and up messages - all others discarded
39 severity info;
40 };
41 category default {
42 example_log;
43 };
44};
45
46// zone file for the root servers
47// discretionary zone (see root server discussion above)
48zone "." {
49 type hint;
50 file "named.root";
51};
52
53// zone file for the localhost forward map
54// discretionary zone depending on hosts file (see discussion)
55zone "localhost" {
56 type primary;
57 file "masters/localhost-forward.db";
58 notify no;
59};
60
61// zone file for the loopback address
62// necessary zone
63zone "0.0.127.in-addr.arpa" {
64 type primary;
65 file "localhost.rev";
66 notify no;
67};
68
69// zone file for local IP reverse map
70// discretionary file depending on requirements
71zone "254.168.192.in-addr.arpa" {
72 type primary;
73 file "192.168.254.rev";
74 notify no;
75};
The zone and acl clauses, and the allow-query, empty-zones-enable, file, notify, recursion, and type statements are described in detail in the appropriate sections.
As a reminder, the configuration of this resolver does not access the DNS hierarchy (does not use the public network) for any recursive query for which:
The answer is already in the cache.
The domain name is localhost (zone localhost).
Is a reverse-map query for 127.0.0.1 (zone 0.0.127.in-addr.arpa).
Is a reverse-map query for 192.168.254/24 (zone 254.168.192.in-addr.arpa).
Is a reverse-map query for any local IP (
empty-zones-enable
statement).
All other recursive queries will result in access to the DNS hierarchy to resolve the query.
3.3.3. Forwarding Resolver Configuration
This forwarding resolver configuration forwards all recursive queries, other than those for the defined zones and those for which the answer is already in its cache, to a full-service resolver at the IP address 192.168.250.3, with an alternative at 192.168.230.27. The forwarding resolver will cache all responses from these servers. The configuration is closed, in that it defines those IPs from which it will accept recursive queries.
A second configuration in which selective forwarding occurs is also provided.
1// forwarding named.conf file
2// Two corporate subnets we wish to allow queries from
3// defined in an acl clause
4acl corpnets {
5 192.168.4.0/24;
6 192.168.7.0/24;
7};
8
9// options clause defining the server-wide properties
10options {
11 // all relative paths use this directory as a base
12 directory "/var";
13 // version statement for security to avoid hacking known weaknesses
14 // if the real version number is revealed
15 version "not currently available";
16 // this is the default
17 recursion yes;
18 // recursive queries only allowed from these ips
19 // and references the acl clause
20 allow-query { corpnets; };
21 // this ensures that any reverse map for private IPs
22 // not defined in a zone file will *not* be passed to the public network
23 // it is the default value
24 empty-zones-enable yes;
25 // this defines the addresses of the resolvers to which queries will be forwarded
26 forwarders {
27 192.168.250.3;
28 192.168.230.27;
29 };
30 // indicates all queries will be forwarded other than for defined zones
31 forward only;
32};
33
34// logging clause
35// log to /var/log/named/example.log all events from info UP in severity (no debug)
36// uses 3 files in rotation swaps files when size reaches 250K
37// failure messages that occur before logging is established are
38// in syslog (/var/log/messages)
39//
40logging {
41 channel example_log {
42 // uses a relative path name and the directory statement to
43 // expand to /var/log/named/example.log
44 file "log/named/example.log" versions 3 size 250k;
45 // only log info and up messages - all others discarded
46 severity info;
47 };
48 category default {
49 example_log;
50 };
51};
52
53// hints zone file is not required
54
55// zone file for the localhost forward map
56// discretionary zone depending on hosts file (see discussion)
57zone "localhost" {
58 type primary;
59 file "masters/localhost-forward.db";
60 notify no;
61};
62
63// zone file for the loopback address
64// necessary zone
65zone "0.0.127.in-addr.arpa" {
66 type primary;
67 file "localhost.rev";
68 notify no;
69};
70
71// zone file for local IP reverse map
72// discretionary file depending on requirements
73zone "254.168.192.in-addr.arpa" {
74 type primary;
75 file "192.168.254.rev";
76 notify no;
77};
The zone and acl clauses, and the allow-query, empty-zones-enable, file, forward, forwarders, notify, recursion, and type statements are described in detail in the appropriate sections.
As a reminder, the configuration of this forwarding resolver does not forward any recursive query for which:
The answer is already in the cache.
The domain name is localhost (zone localhost).
Is a reverse-map query for 127.0.0.1 (zone 0.0.127.in-addr.arpa).
Is a reverse-map query for 192.168.254/24 (zone 254.168.192.in-addr.arpa).
Is a reverse-map query for any local IP (
empty-zones-enable
statement).
All other recursive queries will be forwarded to resolve the query.
3.3.4. Selective Forwarding Resolver Configuration
This forwarding resolver configuration only forwards recursive queries for the zone example.com to the resolvers at 192.168.250.3 and 192.168.230.27. All other recursive queries, other than those for the defined zones and those for which the answer is already in its cache, are handled by this resolver. The forwarding resolver will cache all responses from both the public network and from the forwarded resolvers. The configuration is closed, in that it defines those IPs from which it will accept recursive queries.
1// selective forwarding named.conf file
2// Two corporate subnets we wish to allow queries from
3// defined in an acl clause
4acl corpnets {
5 192.168.4.0/24;
6 192.168.7.0/24;
7};
8
9// options clause defining the server-wide properties
10options {
11 // all relative paths use this directory as a base
12 directory "/var";
13 // version statement for security to avoid hacking known weaknesses
14 // if the real version number is revealed
15 version "not currently available";
16 // this is the default
17 recursion yes;
18 // recursive queries only allowed from these ips
19 // and references the acl clause
20 allow-query { corpnets; };
21 // this ensures that any reverse map for private IPs
22 // not defined in a zone file will *not* be passed to the public network
23 // it is the default value
24 empty-zones-enable yes;
25
26 // forwarding is not global but selective by zone in this configuration
27};
28
29// logging clause
30// log to /var/log/named/example.log all events from info UP in severity (no debug)
31// uses 3 files in rotation swaps files when size reaches 250K
32// failure messages that occur before logging is established are
33// in syslog (/var/log/messages)
34//
35logging {
36 channel example_log {
37 // uses a relative path name and the directory statement to
38 // expand to /var/log/named/example.log
39 file "log/named/example.log" versions 3 size 250k;
40 // only log info and up messages - all others discarded
41 severity info;
42 };
43 category default {
44 example_log;
45 };
46};
47
48// zone file for the root servers
49// discretionary zone (see root server discussion above)
50zone "." {
51 type hint;
52 file "named.root";
53};
54
55// zone file for the localhost forward map
56// discretionary zone depending on hosts file (see discussion)
57zone "localhost" {
58 type primary;
59 file "masters/localhost-forward.db";
60 notify no;
61};
62
63// zone file for the loopback address
64// necessary zone
65zone "0.0.127.in-addr.arpa" {
66 type primary;
67 file "localhost.rev";
68 notify no;
69};
70
71// zone file for local IP reverse map
72// discretionary file depending on requirements
73zone "254.168.192.in-addr.arpa" {
74 type primary;
75 file "192.168.254.rev";
76 notify no;
77};
78// zone file forwarded example.com
79zone "example.com" {
80 type forward;
81 // this defines the addresses of the resolvers to
82 // which queries for this zone will be forwarded
83 forwarders {
84 192.168.250.3;
85 192.168.230.27;
86 };
87 // indicates all queries for this zone will be forwarded
88 forward only;
89};
The zone and acl clauses, and the allow-query, empty-zones-enable, file, forward, forwarders, notify, recursion, and type statements are described in detail in the appropriate sections.
As a reminder, the configuration of this resolver does not access the DNS hierarchy (does not use the public network) for any recursive query for which:
The answer is already in the cache.
The domain name is localhost (zone localhost).
Is a reverse-map query for 127.0.0.1 (zone 0.0.127.in-addr.arpa).
Is a reverse-map query for 192.168.254/24 (zone 254.168.192.in-addr.arpa).
Is a reverse-map query for any local IP (empty-zones-enable statement).
Is a query for the domain name example.com, in which case it will be forwarded to either 192.168.250.3 or 192.168.230.27 (zone example.com).
All other recursive queries will result in access to the DNS hierarchy to resolve the query.
3.4. Load Balancing
A primitive form of load balancing can be achieved in the DNS by using multiple resource records (RRs) in a zone file (such as multiple A records) for one name.
For example, assuming three HTTP servers with network addresses of 10.0.0.1, 10.0.0.2, and 10.0.0.3, a set of records such as the following means that clients will connect to each machine one-third of the time:
Name |
TTL |
CLASS |
TYPE |
Resource Record (RR) Data |
www |
600 |
IN |
A |
10.0.0.1 |
600 |
IN |
A |
10.0.0.2 |
|
600 |
IN |
A |
10.0.0.3 |
When a resolver queries for these records, BIND rotates them and responds to the query with the records in a random order. In the example above, clients randomly receive records in the order 1, 2, 3; 2, 3, 1; and 3, 1, 2. Most clients use the first record returned and discard the rest.
For more detail on ordering responses, refer to the rrset-order statement in the options clause.
3.5. Zone File
This section, largely borrowed from RFC 1034, describes the concept of a Resource Record (RR) and explains how to use them.
3.5.1. Resource Records
A domain name identifies a node in the DNS tree namespace. Each node has a set of resource information, which may be empty. The set of resource information associated with a particular name is composed of separate RRs. The order of RRs in a set is not significant and need not be preserved by name servers, resolvers, or other parts of the DNS. However, sorting of multiple RRs is permitted for optimization purposes: for example, to specify that a particular nearby server be tried first. See The sortlist Statement and RRset Ordering.
The components of a Resource Record are:
- owner name
The domain name where the RR is found.
- type
An encoded 16-bit value that specifies the type of the resource record. For a list of types of valid RRs, including those that have been obsoleted, please refer to https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4.
- TTL
The time-to-live of the RR. This field is a 32-bit integer in units of seconds, and is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can be cached before it should be discarded.
- class
An encoded 16-bit value that identifies a protocol family or an instance of a protocol.
- RDATA
The resource data. The format of the data is type- and sometimes class-specific.
The following classes of resource records are currently valid in the DNS:
- IN
The Internet. The only widely class used today.
- CH
Chaosnet, a LAN protocol created at MIT in the mid-1970s. It was rarely used for its historical purpose, but was reused for BIND’s built-in server information zones, e.g., version.bind.
- HS
Hesiod, an information service developed by MIT’s Project Athena. It was used to share information about various systems databases, such as users, groups, printers, etc.
The owner name is often implicit, rather than forming an integral part of the RR. For example, many name servers internally form tree or hash structures for the name space, and chain RRs off nodes. The remaining RR parts are the fixed header (type, class, TTL), which is consistent for all RRs, and a variable part (RDATA) that fits the needs of the resource being described.
The TTL field is a time limit on how long an RR can be kept in a cache. This limit does not apply to authoritative data in zones; that also times out, but follows the refreshing policies for the zone. The TTL is assigned by the administrator for the zone where the data originates. While short TTLs can be used to minimize caching, and a zero TTL prohibits caching, the realities of Internet performance suggest that these times should be on the order of days for the typical host. If a change is anticipated, the TTL can be reduced prior to the change to minimize inconsistency, and then increased back to its former value following the change.
The data in the RDATA section of RRs is carried as a combination of binary strings and domain names. The domain names are frequently used as “pointers” to other data in the DNS.
3.5.1.1. Textual Expression of RRs
RRs are represented in binary form in the packets of the DNS protocol, and are usually represented in highly encoded form when stored in a name server or resolver. In the examples provided in RFC 1034, a style similar to that used in primary files was employed in order to show the contents of RRs. In this format, most RRs are shown on a single line, although continuation lines are possible using parentheses.
The start of the line gives the owner of the RR. If a line begins with a blank, then the owner is assumed to be the same as that of the previous RR. Blank lines are often included for readability.
Following the owner are listed the TTL, type, and class of the RR. Class and type use the mnemonics defined above, and TTL is an integer before the type field. To avoid ambiguity in parsing, type and class mnemonics are disjoint, TTLs are integers, and the type mnemonic is always last. The IN class and TTL values are often omitted from examples in the interest of clarity.
The resource data or RDATA section of the RR is given using knowledge of the typical representation for the data.
For example, the RRs carried in a message might be shown as:
ISI.EDU.
MX
10 VENERA.ISI.EDU.
MX
10 VAXA.ISI.EDU
VENERA.ISI.EDU
A
128.9.0.32
A
10.1.0.52
VAXA.ISI.EDU
A
10.2.0.27
A
128.9.0.33
The MX RRs have an RDATA section which consists of a 16-bit number followed by a domain name. The address RRs use a standard IP address format to contain a 32-bit Internet address.
The above example shows six RRs, with two RRs at each of three domain names.
Here is another possible example:
XX.LCS.MIT.EDU.
IN A
10.0.0.44
CH A
MIT.EDU. 2420
This shows two addresses for XX.LCS.MIT.EDU, each of a different class.
3.5.2. Discussion of MX Records
As described above, domain servers store information as a series of resource records, each of which contains a particular piece of information about a given domain name (which is usually, but not always, a host). The simplest way to think of an RR is as a typed pair of data, a domain name matched with a relevant datum and stored with some additional type information, to help systems determine when the RR is relevant.
MX records are used to control delivery of email. The data specified in the record is a priority and a domain name. The priority controls the order in which email delivery is attempted, with the lowest number first. If two priorities are the same, a server is chosen randomly. If no servers at a given priority are responding, the mail transport agent falls back to the next largest priority. Priority numbers do not have any absolute meaning; they are relevant only respective to other MX records for that domain name. The domain name given is the machine to which the mail is delivered. It must have an associated address record (A or AAAA); CNAME is not sufficient.
For a given domain, if there is both a CNAME record and an MX record, the MX record is in error and is ignored. Instead, the mail is delivered to the server specified in the MX record pointed to by the CNAME. For example:
example.com.
IN
MX
10
mail.example.com.
IN
MX
10
mail2.example.com.
IN
MX
20
mail.backup.org.
mail.example.com.
IN
A
10.0.0.1
mail2.example.com.
IN
A
10.0.0.2
Mail delivery is attempted to mail.example.com and mail2.example.com (in any order); if neither of those succeeds, delivery to mail.backup.org is attempted.
3.5.3. Setting TTLs
The time-to-live (TTL) of the RR field is a 32-bit integer represented in units of seconds, and is primarily used by resolvers when they cache RRs. The TTL describes how long an RR can be cached before it should be discarded. The following three types of TTLs are currently used in a zone file.
- SOA minimum
The last field in the SOA is the negative caching TTL. This controls how long other servers cache no-such-domain (NXDOMAIN) responses from this server. Further details can be found in RFC 2308.
The maximum time for negative caching is 3 hours (3h).
- $TTL
The $TTL directive at the top of the zone file (before the SOA) gives a default TTL for every RR without a specific TTL set.
- RR TTLs
Each RR can have a TTL as the second field in the RR, which controls how long other servers can cache it.
All of these TTLs default to units of seconds, though units can be explicitly specified: for example, 1h30m.
3.5.4. Inverse Mapping in IPv4
Reverse name resolution (that is, translation from IP address to name) is achieved by means of the in-addr.arpa domain and PTR records. Entries in the in-addr.arpa domain are made in least-to-most significant order, read left to right. This is the opposite order to the way IP addresses are usually written. Thus, a machine with an IP address of 10.1.2.3 would have a corresponding in-addr.arpa name of 3.2.1.10.in-addr.arpa. This name should have a PTR resource record whose data field is the name of the machine or, optionally, multiple PTR records if the machine has more than one name. For example, in the example.com domain:
$ORIGIN
2.1.10.in-addr.arpa
3
IN PTR foo.example.com.
Note
The $ORIGIN line in this example is only to provide context; it does not necessarily appear in the actual usage. It is only used here to indicate that the example is relative to the listed origin.
3.5.5. Other Zone File Directives
The DNS “master file” format was initially defined in RFC 1035 and has subsequently been extended. While the format itself is class-independent, all records in a zone file must be of the same class.
Master file directives include $ORIGIN, $INCLUDE, and $TTL.
3.5.5.1. The @ (at-sign)
When used in the label (or name) field, the asperand or at-sign (@) symbol represents the current origin. At the start of the zone file, it is the <zone_name>, followed by a trailing dot (.).
3.5.5.2. The $ORIGIN Directive
Syntax: $ORIGIN domain-name [comment]
$ORIGIN sets the domain name that is appended to any
unqualified records. When a zone is first read, there is an implicit
$ORIGIN <zone_name>.
; note the trailing dot. The
current $ORIGIN is appended to the domain specified in the
$ORIGIN argument if it is not absolute.
$ORIGIN example.com.
WWW CNAME MAIN-SERVER
is equivalent to
WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
3.5.5.3. The $INCLUDE Directive
Syntax: $INCLUDE filename [origin] [comment]
This reads and processes the file filename as if it were included in the
file at this point. The filename can be an absolute path, or a relative
path. In the latter case it is read from named
’s working directory. If
origin is specified, the file is processed with $ORIGIN set to that
value; otherwise, the current $ORIGIN is used.
The origin and the current domain name revert to the values they had prior to the $INCLUDE once the file has been read.
3.5.5.4. The $TTL Directive
Syntax: $TTL default-ttl [comment]
This sets the default Time-To-Live (TTL) for subsequent records with undefined TTLs. Valid TTLs are of the range 0-2147483647 seconds.
$TTL is defined in RFC 2308.
3.5.6. BIND Primary File Extension: the $GENERATE Directive
Syntax: $GENERATE range lhs [ttl] [class] type rhs [comment]
$GENERATE is used to create a series of resource records that only differ from each other by an iterator. $GENERATE can be used to easily generate the sets of records required to support sub-/24 reverse delegations described in RFC 2317.
$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-2 @ NS SERVER$.EXAMPLE.
$GENERATE 1-127 $ CNAME $.0
is equivalent to
0.0.0.192.IN-ADDR.ARPA. NS SERVER1.EXAMPLE.
0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
...
127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.
Both generate a set of A and MX records. Note the MX’s right-hand side is a quoted string. The quotes are stripped when the right-hand side is processed.
$ORIGIN EXAMPLE.
$GENERATE 1-127 HOST-$ A 1.2.3.$
$GENERATE 1-127 HOST-$ MX "0 ."
is equivalent to
HOST-1.EXAMPLE. A 1.2.3.1
HOST-1.EXAMPLE. MX 0 .
HOST-2.EXAMPLE. A 1.2.3.2
HOST-2.EXAMPLE. MX 0 .
HOST-3.EXAMPLE. A 1.2.3.3
HOST-3.EXAMPLE. MX 0 .
...
HOST-127.EXAMPLE. A 1.2.3.127
HOST-127.EXAMPLE. MX 0 .
- range
This can be one of two forms: start-stop or start-stop/step. If the first form is used, then step is set to 1. “start”, “stop”, and “step” must be positive integers between 0 and (2^31)-1. “start” must not be larger than “stop”.
- owner
This describes the owner name of the resource records to be created. Any single $ (dollar sign) symbols within the owner string are replaced by the iterator value. To get a $ in the output, escape the $ using a backslash \, e.g.,
\$
. The $ may optionally be followed by modifiers which change the offset from the iterator, field width, and base.Modifiers are introduced by a { (left brace) immediately following the $, as in ${offset[,width[,base]]}. For example, ${-20,3,d} subtracts 20 from the current value and prints the result as a decimal in a zero-padded field of width 3. Available output forms are decimal (d), octal (o), hexadecimal (x or X for uppercase), and nibble (n or N for uppercase).
The default modifier is ${0,0,d}. If the owner is not absolute, the current $ORIGIN is appended to the name.
In nibble mode, the value is treated as if it were a reversed hexadecimal string, with each hexadecimal digit as a separate label. The width field includes the label separator.
For compatibility with earlier versions, $$ is still recognized as indicating a literal $ in the output.
- ttl
This specifies the time-to-live of the generated records. If not specified, this is inherited using the normal TTL inheritance rules.
class and ttl can be entered in either order.
- class
This specifies the class of the generated records. This must match the zone class if it is specified.
class and ttl can be entered in either order.
- type
This can be any valid type.
- rdata
This is a string containing the RDATA of the resource record to be created. It may be quoted if there are spaces in the string; the quotation marks do not appear in the generated record.
The $GENERATE directive is a BIND extension and not part of the standard zone file format.
3.5.7. Additional File Formats
In addition to the standard text format, BIND 9 supports the ability to read or dump to zone files in other formats.
The raw format is a binary representation of zone data in a manner similar to that used in zone transfers. Since it does not require parsing text, load time is significantly reduced.
For a primary server, a zone file in raw format is expected
to be generated from a text zone file by the named-compilezone
command.
For a secondary server or a dynamic zone, the zone file is automatically
generated when named
dumps the zone contents after zone transfer or
when applying prior updates, if one of these formats is specified by the
masterfile-format option.
If a zone file in raw format needs manual modification, it first must
be converted to text format by the named-compilezone
command,
then converted back after editing. For example:
named-compilezone -f raw -F text -o zonefile.text <origin> zonefile.raw
[edit zonefile.text]
named-compilezone -f text -F raw -o zonefile.raw <origin> zonefile.text