5.1 Introduction

Creating zone data and configuring a name server is only the beginning. Managing a name server over time requires an understanding of how to control it and which commands it supports. It takes familiarity with other tools from the BIND distribution, including nsupdate , used to send dynamic updates to a name server.

This chapter includes lots of recipes that involve ndc and rndc , programs that send control messages to BIND 8 and 9 name servers, respectively. These programs let an administrator reload modified zones, refresh slave zones, flush the cache, and much more. The list of commands the name server supports seems to grow with each successive release of BIND, so I've provided a peek at a few new commands in BIND 9.3.0 for the curious .

Several recipes describe how to drive the nsupdate program to send dynamic updates. In the brave new world of dynamic zones, an administrator may have to make most of the changes to zone data using dynamic update, rather than by manually editing zone data files. The recipes cover sending plain vanilla dynamic updates (Section 5.20), setting prerequisites in a dynamic update (Section 5.22), and sending TSIG-signed dynamic updates (Section 5.23).

Finally, the chapter covers a few common administrative processes, such as setting up and failing over to a backup master name server, migrating from one domain name to another, and measuring a name server's performance.

5.2 Figuring Out How Much Memory a Name Server Will Need

5.2.1 Problem

You need to figure out how much memory a name server will require.

5.2.2 Solution

While this answer may seem like a cop-out, the only sure-fire way to determine how much memory a name server will need is to configure it, start it, and then monitor it using a tool like top . After a week or so, the size of the named process should stabilize, and you'll know how much memory it needs.

5.2.3 Discussion

The reason it's so difficult to calculate how much memory a name server requires is that there are so many variables involved. The size of the named executable varies on different operating systems and hardware architectures. Zones have a unique mix of records. Zone data files may use lots of shortcuts (e.g., leaving out the origin, or even using a $GENERATE control statement) or none at all. The resolvers that use the name server may send a huge volume of queries, causing the name server's cache to swell, or may send just sporadic queries.

5.2.4 See Also

The BIND 9 ARM, section 2.3.

5.3 Testing a Name Server's Configuration

5.3.1 Problem

You want to test a name server's configuration before putting it into production.

5.3.2 Solution

Use the named-checkconf and named-checkzone programs to check the named.conf file and zone data files, respectively. named-checkconf reads /etc/named.conf by default, so if you haven't moved the configuration file into /etc yet, specify the pathname to the configuration file you want to test as the argument:

$ named-checkconf ~/test/named.conf

named-checkconf uses the routines in BIND (BIND 9.1.0 and later, to be exact) to make sure the named.conf file is syntactically correct. If there are any syntactic or semantic errors in named.conf , named-checkconf will print an error. For example:

$ named-checkconf /tmp/named.conf
/tmp/named.conf:3: missing ';' before '}'

named-checkzone uses BIND's own routines to check the syntax of a zone data file. To run it, specify the domain name of the zone and the name of the zone data file as arguments:

$ named-checkzone foo.example db.foo.example

If the zone contains any errors, named-checkzone prints an error. If the zone would load without errors, named-checkzone prints a message like this:

zone foo.example/IN: loaded serial 2002022400
OK

Once you've checked the configuration file and zone data, configure the name server to listen on a nonstandard port with the listen-on options substatement, and not to use a control channel:

controls { };

options {
    directory "/var/named";
    listen-on port 1053 { any; };
};

That way, the test name server won't interfere with any production name server you might already have running. Check the name server's syslog output (which should be clean, if you ran named-checkconf and named-checkzone ) and query the name server with dig or another query tool, specifying the alternate port:

$ dig -p 1053 soa foo.example.

Once you're satisfied with the name server's responses to a few queries, you can remove the listen-on substatement, add a real controls statement and put it into production.

5.3.3 Discussion

Even though named-checkconf and named-checkzone first shipped with BIND 9.1.0, BIND 8's configuration syntax is similar enough to BIND 9's that you can easily use named-checkconf with a BIND 8 named.conf file. The zone data file format is exactly the same between versions, so you can use named-checkzone , too.