Working with the BIND Configuration File (named.conf)


Working with the BIND Configuration File (named.conf)

To make your name server do anything useful, you need to make sure that it is topologically in the right place with respect to its clients and the rest of the network and that it is configured to interoperate properly with other name servers. A misconfigured name server can result in deluges of DNS traffic between your server and the root servers as it tries futilely to synchronize its data. Your /etc/namedb/named.conf file must be constructed properly, so it needs to be understood properly.

Caution

As should be a habit by now, be sure to make a backup copy of your named.conf file (such as named.conf.20060315) before you make any changes to it. Always leave yourself the option to revert to your previous working configuration!


Fortunately, BIND 9 (the version included in FreeBSD at the time of this writing) greatly simplifies many of the esoteric details of name server configuration that were the norm in BIND version 4 and earlier. BIND 8, which immediately replaced BIND 4, introduced a lot more configurability and at the same time eliminated many elements that were obsolete or poorly designed, and BIND 9 continues this simplification. Listing 32.1 shows a sample named.conf file, giving you an idea of its syntax and structure.

Listing 32.1. Sample /etc/namedb/named.conf File

/*  * A simple BIND 8/9 configuration  */ logging {     category lame-servers { null; };     category cname { null; }; }; options {     directory "/etc/namedb"; }; zone "example.com" {     type master;     file "master/example.com"; }; zone "131.41.64.in-addr.arpa" {     type master;     file "master/131.41.64.in-addr.arpa"; }; zone "elsewhere.com" {     type slave;     file "slave/elsewhere.com";     masters { 113.125.2.145; }; }; zone "." {     type hint;     file "named.root"; }; zone "0.0.127.in-addr.arpa" {     type master;     file "master/localhost.rev"; }; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {         type master;         file "master/localhost.rev"; };

As shown in the listing, a configuration file consists of a number of blocks (or statements) in C-style syntax, with substatements allowed within curly brackets ({}). All possible statements are listed and described in the man named.conf page. Some of the most useful ones are options, controls, logging, and zone.

Comments in named.conf are also C style; single-line comments are done with double slashes (//), and block comments are done with the /* comment */ syntax. Shell-style comments (#) are also supported.

The named.conf file that exists in the default installation of FreeBSD has a few of the statements shown in Listing 32.1 and a few that are not. It also has a lot of inline documentation that describes how to use each of them.

Whenever you make a change to named.conf or to any of the zone files (which we will discuss later in this chapter), restart named using the ndc program:

# ndc reload Reload initiated.


Using a Forwarder

Recalling the topology shown in Figure 32.1, a forwarder is a name server at an "upstream" networka larger network "closer" to the root serversthat allows you to request DNS information from it. (Note that access to a name server can be restricted, as you will see.) A good candidate for a forwarder is your uplink ISP's name server, if your FreeBSD machine is acting as a name server for a home network. Normally, if your machine can't answer a DNS request on its own, it must query the root servers (found in /etc/namedb/named.root) for the authoritative reply. These extra steps take time and add to the packet traffic on the network.

It really isn't necessary for everyone to get authoritative answers all the time. It's perfectly acceptable in most cases to work from nonauthoritative DNS information, such as that from a caching name server:

# nslookup www.freebsd.org ns.example.com Server:  ns.example.com Address:  64.41.131.172 Non-authoritative answer: Name:    freefall.freebsd.org Address:  216.136.204.21 Aliases:  www.freebsd.org


Note

Although the examples in this chapter use the rudimentary nslookup program (because of the clarity of its output), nslookup has been superseded for most administrators by the more versatile and verbose dig.


Configuring your FreeBSD system to query one or more forwarders allows it to benefit from the cache of the upstream name server, rather than to fetch authoritative data on every query. The downside (as we discussed earlier) is that the cached data can become "stale" by as much time as the authoritative server's zone file specifies it should (a period frequently measured in daysthough most forwarders do use reasonably short TTL values, which mitigates this drawback). Figure 32.2 shows a DNS query path in which a forwarder is involved. The forwarder does most of the work, building up its cache through queries of its own and in service to its own clients. The downstream DNS that points to it needs only to query the forwarder, thus preventing unnecessary lag and query traffic.

Figure 32.2. A diagram of a DNS lookup involving a forwarder providing cached DNS information in a nonauthoritative capacity to the local DNS and the client.


Tip

The deluges of DNS traffic mentioned earlier are often caused by name servers that are improperly configured, never to take advantage of caching name servers. These forwarders are what prevent too much unnecessary traffic from swamping low-bandwidth linksfor instance, in cases where a DNS host serving as the authoritative name server for a domain is on a small DSL or dial-up link. Without caching name servers, every host on the Internet would have to send DNS queries to that overloaded name server directly. With forwarders, the load on the target host's link is greatly reduced. Using a forwarder is a way to act as a good network citizen and make your own queries faster and more efficient.


To enable a forwarder, replace 127.0.0.1 in the forwarders block of the options statement with the upstream name server's IP address (127.0.0.1, the localhost address, will not work here) and uncomment the block by removing the /* and */ comment tags:

/*         forwarders {                 127.0.0.1;                 66.114.72.112;         }; */


You can specify as many forwarders as you like, and named will consult each one before giving up and querying the root servers. You can additionally uncomment the forward only; statement in the options block to force named to consult only the forwarders on all queries. Normally, your machine will consult the forwarders for DNS data unless it appears that the forwarders are unreachable or broken, in which case it makes full queries to the root servers. Setting the forward only; option prevents it from making root server queries on any occasion.

Master and Slave Configurations

Each zone block defines a domain or subdomain that your FreeBSD machine will administer. Most commonly, a zone block defines a domain of the form example.com:

zone "example.com" {     type master;     file "master/example.com"; };


All that's absolutely necessary in this block is the name of the domain or subdomain (without the trailing dot that will usually be associated with a zone name), the type statement that defines whether it's a master or slave configuration for that domain, and the name of the file that contains the zone information (relative to the /etc/namedb root, which is actually /var/named/etc/namedb). Let's examine what it means for a name server to act as a master or a slave for a particular zone.

The type substatement can be master, slave, stub, forward, or hint. The most commonly used of these are master and slave; the rest are used in special circumstances only, which we will look at shortly.

A master zone indicates that the server is authoritative for the zone; it means the server has a master copy of the zone file, defining name-to-address mappings that are to propagate throughout the Internet, and any changes to it must be made manuallybut those changes override the information in every other name server's DNS cache when the existing information expires.

A slave zone is a replica of a master zone obtained from another server, with a zone file derived from the one that the master has. Slave servers can provide authoritative answers to DNS queries. A slave zone block looks like this:

zone "elsewhere.com" {     type slave;     file "slave/elsewhere.com";     masters { 113.125.2.145; }; };


The masters statement contains a semicolon-delimited list of master servers from which to transfer zone information. These masters can be actual authoritative master zone servers or they can be other slaves, but if a specified master has an allow-transfer statement in its global configuration, the slave's IP address must be listed in that statement. (Access restrictions are discussed later in this chapter.)

The file statement in a slave zone refers to the name of the autogenerated zone file that named will create when it transfers it from the master. In this example, the elsewhere.com file is automatically generated within the /etc/namedb/slave subdirectory. Master zone files, which you create manually, are kept instead in the master subdirectory.

Tip

When you set up a slave zone on your server, run ndc reload to cause BIND to perform a zone transfer and create the new zone file at the location you specify in the file statement.

When changes are made to the master zone file on the master name server, your slave server inherits the changes only after the caching period specified in the file has expired. You can force the file to be updated more immediately by simply deleting the zone file in the slave directory and issuing the ndc reload command to re-create it.

Make sure that the /etc/namedb/slave directory exists before you issue the ndc reload command; otherwise, the command will fail.


Other Zone Types

As described in man named.conf, you can have three other types of zone blocks. These types are as follows:

  • stub A stub zone works in the same way as a slave zone, except that it transfers only the NS recordsthe records specifying where clients can find valid DNS information for the specified domain.

  • forward You can use a forward zone type to forward all requests for the zone to another server or set of servers. A forwarders block can be specified in this type of zone statement, operating like the global one in the options block; this enables you to override the global forwarders list.

  • hint A hint zone is only really used in connection with the initial list of potential root servers, found in /etc/namedb/named.root. This initial list is not actually the authoritative list of root servers; it's a list of "hints" for BIND, specifying servers that will have the current true list of root servers. The contents of the true list has a habit of changing as network conditions vary.

Restricting DNS Access

Of interest to administrators with complex DNS configurations is that BIND has the capability to restrict access based on Access Control Lists (ACLs). ACLs are not a requirement, but they can make configuring your server much simpler, allowing you to use shorthand names for lists of addresses that you tend to reuse. An ACL is specified in an acl statement, which defines a name for the list and contains the criteria for which hosts are included in the list. These criteria can take a number of forms, and they can be recursive; in other words, an ACL can contain other ACLs. The following ACLs are predefined for you:

  • any Allows all hosts

  • none Denies all hosts

  • localhost Allows the IP addresses of all interfaces on the system

  • localnets Allows any host on a network for which the system has an interface

Other types of list elements that are allowed can be IP addresses (for instance, 111.112.113.114), networks in CIDR format (for instance, 111.112.113/24), a "negated" version of either of these (!111.112.113.114, which means "any host but 111.112.113.114"), or a key statement (used in secure DNS transactions, which are beyond the scope of this chapter). When you're compiling a list of ACL elements, it's best to put the more specific elements before the broader ones because the list is evaluated in the order in which it's specified. If a host matches any element, it will be allowed, regardless of whether a later "negation" element would have matched it. Put all such exceptions toward the beginning of the list.

Because the contents of named.conf are read sequentially, an ACL must be specified in the file before it can be referred to later in other statements. For best results, put all acl statements toward the top of your named.conf file, above the options block. A sample ACL would be the following:

acl "my_list" {   localhost;   localnets;   another_list;   !132.112.14.124;   132.112.14/24; };


This list first contains the built-in localhost and localnets ACLs and then includes another ACL called another list, which would be defined elsewhere in the file. Then a negated "exception" host appears (132.112.14.124), with the "!" prefix exempting it from the 132.112.14/24 subnet that comes next. Thus, this ACL contains everything in that subnet except for the single host 132.112.14.124.

After you have a list specified, you can use it along with other address list elements later in a zone statement (to control access to requests for just that zone) or in the global options statement. Here's a list of the available access-control statements:

  • allow-query { address_list_elements; ... };

    Specifies which hosts are allowed to perform ordinary DNS queries. allow-query may also be specified in a zone statement, in which case it overrides the options allow-query statement. If not specified, the default is to allow queries from all hosts.

  • allow-transfer { address_list_elements; ... };

    Specifies which slave servers are allowed to receive zone transfers from this server. allow-transfer may also be specified in the zone statement, in which case it overrides the options allow-transfer statement. If not specified, the default is to allow transfers from all hosts.

  • allow-recursion { address_list_elements; ... };

    Specifies which hosts are allowed to make recursive queries through this server. If not specified, the default is to allow recursive queries from all hosts.

  • blackhole { address_list_elements; ... };

    Specifies a list of addresses that the server will not accept queries from or use to resolve a query. Queries from these addresses will not be answered.

For example, you could restrict queries globally to members of the my_list ACL that you specified earlier. You also could restrict queries for the example.com domain to the members of my_list, as well as to an additional network, and restrict zone transfers only to two specified slave servers with the following partial configuration:

options {     directory "/etc/namedb";         allow-query { my_list; }; }; zone "example.com" {     type master;     file "example.com";         allow-query { my_list; 64.2.43/24; };         allow-transfer { 64.2.43.167; 123.15.221.3; }; };





FreeBSD 6 Unleashed
FreeBSD 6 Unleashed
ISBN: 0672328755
EAN: 2147483647
Year: 2006
Pages: 355
Authors: Brian Tiemann

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net