3. Configurations and Zone Files

BIND 9 uses a single configuration file called named.conf . which 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 blocks 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:

  1. Many users elect to delete the hosts file for security reasons (it is a potential target of serious domain name redirection/poisoning attacks).
  2. Systems normally lookup any name (including domain names) using the hosts file first (if present), followed by DNS. However, the nsswitch.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.
  3. 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.

$TTL 3h localhost. SOA localhost. nobody.localhost. 42 1d 12h 1w 3h NS localhost. A 127.0.0.1 AAAA ::1

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.

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.

_images/primary-secondary.png

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

  1. The authoritative primary name server always loads (or reloads) its zone files from (1) a local or networked filestore.
  2. The authoritative secondary name server always loads its zone data from a primary via a zone transfer operation. Zone transfer may use AXFR (complete zone transfer) or IXFR (incremental zone transfer), but only if both primary and secondary name servers support the service. The zone transfer process (either AXFR or IXFR) works as follows:
    1. The secondary name server for the zone reads (3 and 4) the SOA RR periodically. The interval is defined by the refresh parameter of the Start of Authority (SOA) RR.
    2. The secondary compares the serial number parameter of the SOA RR received from the primary with the serial number in the SOA RR of its current zone data.
    3. If the received serial number is arithmetically greater (higher) than the current one, the secondary initiates a zone transfer (5) using AXFR or IXFR (depending on the primary and secondary configuration), using TCP over port 53 (6).

    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 the loopback // address 127.0.0.1 zone "0.0.127.in-addr.arpa"  type primary; file "localhost.rev"; notify no; >; // We are the primary server for example.com zone "example.com"  // this is the primary name server for the zone type primary; file "example.com"; // this is the 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 blocks are commented in the above file.

    The zone block, 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; >; // We are 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 blocks added are all commented in the above file.

    The zone block, and allow-query , allow-query-cache , allow-transfer , file , 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.

    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 block 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

    1. 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.
    2. 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.
    3. 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:
      1. 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.
      2. 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.
      3. 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).
      4. Stealth Networks. Forwarding resolvers are extensively used in stealth or split networks .

      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 blocks 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 hint zone file is referenced using the type hint statement and 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. By default this statement is 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.

      ; reverse map zone file for 192.168.254.4 only $TTL 2d ; 172800 seconds $ORIGIN 254.168.192.IN-ADDR.ARPA. @ IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 ; serial number 3h ; refresh 15m ; update retry 3w ; expiry 3h ; nx = nxdomain ttl ) ; only one NS is required for this local file ; and is an out of zone name IN NS ns1.example.com. ; other IP addresses can be added as required ; this maps 192.168.254.4 as shown 4 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.

      // resolver named.conf file // Two corporate subnets we wish to allow queries from // defined in an acl clause acl corpnets  192.168.4.0/24; 192.168.7.0/24; >; // 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 recursion yes; // recursive queries only allowed from these ips // and references the acl clause allow-query  corpnets; >; // this ensures that any reverse map for private IPs // not defined in a zone file will *not* be passed to the public network // it is the default value empty-zones-enable yes; >; // 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; >; >; // zone file for the root servers // discretionary zone (see root server discussion above) zone "."  type hint; file "named.root"; >; // zone file for the localhost forward map // discretionary zone depending on hosts file (see discussion) zone "localhost"  type primary; file "masters/localhost-forward.db"; notify no; >; // zone file for the loopback address // necessary zone zone "0.0.127.in-addr.arpa"  type primary; file "localhost.rev"; notify no; >; // zone file for local IP reverse map // discretionary file depending on requirements zone "254.168.192.in-addr.arpa"  type primary; file "192.168.254.rev"; notify no; >;

      The zone and acl blocks, 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:

      1. The answer is already in the cache.
      2. The domain name is localhost (zone localhost).
      3. Is a reverse-map query for 127.0.0.1 (zone 0.0.127.in-addr.arpa).
      4. Is a reverse-map query for 192.168.254/24 (zone 254.168.192.in-addr.arpa).
      5. 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 .

      // forwarding named.conf file // Two corporate subnets we wish to allow queries from // defined in an acl clause acl corpnets  192.168.4.0/24; 192.168.7.0/24; >; // 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 recursion yes; // recursive queries only allowed from these ips // and references the acl clause allow-query  corpnets; >; // this ensures that any reverse map for private IPs // not defined in a zone file will *not* be passed to the public network // it is the default value empty-zones-enable yes; // this defines the addresses of the resolvers to which queries will be forwarded forwarders  192.168.250.3; 192.168.230.27; >; // indicates all queries will be forwarded other than for defined zones forward only; >; // 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; >; >; // hints zone file is not required // zone file for the localhost forward map // discretionary zone depending on hosts file (see discussion) zone "localhost"  type primary; file "masters/localhost-forward.db"; notify no; >; // zone file for the loopback address // necessary zone zone "0.0.127.in-addr.arpa"  type primary; file "localhost.rev"; notify no; >; // zone file for local IP reverse map // discretionary file depending on requirements zone "254.168.192.in-addr.arpa"  type primary; file "192.168.254.rev"; notify no; >;

      The zone and acl blocks, 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:

      1. The answer is already in the cache.
      2. The domain name is localhost (zone localhost).
      3. Is a reverse-map query for 127.0.0.1 (zone 0.0.127.in-addr.arpa).
      4. Is a reverse-map query for 192.168.254/24 (zone 254.168.192.in-addr.arpa).
      5. 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.

      // selective forwarding named.conf file // Two corporate subnets we wish to allow queries from // defined in an acl clause acl corpnets  192.168.4.0/24; 192.168.7.0/24; >; // 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 recursion yes; // recursive queries only allowed from these ips // and references the acl clause allow-query  corpnets; >; // this ensures that any reverse map for private IPs // not defined in a zone file will *not* be passed to the public network // it is the default value empty-zones-enable yes; // forwarding is not global but selective by zone in this configuration >; // 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; >; >; // zone file for the root servers // discretionary zone (see root server discussion above) zone "."  type hint; file "named.root"; >; // zone file for the localhost forward map // discretionary zone depending on hosts file (see discussion) zone "localhost"  type primary; file "masters/localhost-forward.db"; notify no; >; // zone file for the loopback address // necessary zone zone "0.0.127.in-addr.arpa"  type primary; file "localhost.rev"; notify no; >; // zone file for local IP reverse map // discretionary file depending on requirements zone "254.168.192.in-addr.arpa"  type primary; file "192.168.254.rev"; notify no; >; // zone file forwarded example.com zone "example.com"  type forward; // this defines the addresses of the resolvers to // which queries for this zone will be forwarded forwarders  192.168.250.3; 192.168.230.27; >; // indicates all queries for this zone will be forwarded forward only; >;

      The zone and acl blocks, 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:

      1. The answer is already in the cache.
      2. The domain name is localhost (zone localhost).
      3. Is a reverse-map query for 127.0.0.1 (zone 0.0.127.in-addr.arpa).
      4. Is a reverse-map query for 192.168.254/24 (zone 254.168.192.in-addr.arpa).
      5. Is a reverse-map query for any local IP (empty-zones-enable statement).
      6. 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: