O'Reilly Network    
 Published on O'Reilly Network (http://www.oreillynet.com/)
 See this if you're having trouble printing code examples

O'Reilly Book Excerpts: DNS & BIND Cookbook

Cooking with DNS & BIND

Related Reading

DNS & Bind Cookbook
By Cricket Liu

by Cricket Liu

Editor's Note: Here's a sampling of the recipes you'll find in the recently released DNS & BIND Cookbook. The author, Cricket Liu, has selected five recipes from Chapter 5 on "BIND Name Server Operations." The problems and solutions in this excerpt range from how to determine the amount of memory a name server needs to how to modify zone data without restarting the name server.


Creating zone data and configuring a name server is just 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.

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.

Figuring Out How Much Memory a Name Server Will Need


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


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.


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.

Testing a Name Server's Configuration


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


Use the named-checkconf and named-checkzon 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-checkzon 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-checkzon prints an error. If the zone would load without errors, named-checkzon prints a message like this:

zone foo.example/IN: loaded serial 2002022400

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-checkzon) 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.


Even though named-checkconf and named-checkzon 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-checkzon, too.

Viewing a Name Server's Cache


You want to view a name server's cached data.


Use rndc dumpdb (BIND 9) or ndc dumpdb (BIND 8) to dump the cache to disk, then look through the dump file.


BIND 9 name servers only dump the contents of the cache to disk by default, but BIND 8 name servers dump both the contents of cache and authoritative zone data to disk, so you'll have to find the cached records in the file.

To determine which records in a BIND 8 database dump were cached, look at the TTLs and the contents of the comment field. Authoritative zone data will have the nice, round TTLs you configured, while cached records will have had their TTLs decremented by the number of seconds they've been in the cache. Cached records will also have "Cr=" as a comment at the end of the record, giving the credibility level of the record (an indication of the quality of the cached record). For example, these records were cached from an authoritative response from the name server at

.       518380  IN      NS      I.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      E.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      D.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      A.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      H.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      C.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      G.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      F.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      B.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      J.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      K.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      L.ROOT-SERVERS.NET.     ;Cr=auth []
        518380  IN      NS      M.ROOT-SERVERS.NET.     ;Cr=auth []

Remember that dumping the cache to disk has no effect on the contents of the cache. If you want to flush (clear) the cache, see Flushing (Clearing) a Name Server's Cache.

Flushing (Clearing) a Name Server's Cache


You want to flush bad records from a name server's cache.


If you run a BIND 9.2.0 or newer name server, you can flush the cache with rndc flush. With older name servers, you need to kill the name server and restart it to flush the cache. You can do that in one fell swoop with rndc restart or rndc exec.


Clearing the cache is really a side effect of killing the name server, since BIND name servers only store cached data in memory. Since restarting the name server takes time, especially if the name server is authoritative for many zones, rndc flush is a better option.

If you run multiple views on your BIND 9.2.0 or newer name server, you can flush the cache in only one view using rndc flush viewname. For example:

# rndc flush internal

BIND 9.3.0 will support flushing all of the records attached to a particular domain name with rndc flushname. For example:

# rndc flushname cnn.com

Modifying Zone Data Without Restarting the Name Server


You want to modify your zone data without restarting the name server.


Make the change to the zone data file. For BIND 9, run:

# rndc reload domain-name-of-zone

For BIND 8, run:

# ndc reload domain-name-of-zone

If you've modified multiple zones, just list them after reload. For example:

# rndc reload foo.example bar.example


Remember to increment the serial number in your zone's SOA record after changing the zone data. The primary master reloads the zone regardless of whether you've incremented the serial number, since the file's modification time has changed, but your zone's slaves only have the serial number to tell them whether the zone has been updated.

Reloading individual zones, as shown above, was introduced in BIND 8.2.1 and again in 9.1.0. With older versions of BIND, just use rndc reload or ndc reload, as appropriate. That takes a little more time, since the name server checks all zone data files to see which have changed.

If you're reloading a zone that exists in multiple views on a BIND 9 name server, specify the view with rndc reload domain-name-of-zone class view. For example:

# rndc reload foo.example in external

Unfortunately, you can't leave out the class, even though you're unlikely ever to reload a non-Internet class zone.

Telling a BIND 9 name server to reload a dynamically updated zone has no effect, since the name server doesn't expect you to update the zone manually. Telling a BIND 8 name server to reload a dynamically updated zone may work--or you may lose your manual changes.

Dynamic update is, of course, another way to update zone data without restarting the name server; see "See Dynamically Updating a Zone" in Chapter 7 for details.

DNS & Bind Cookbook

Related Reading

DNS & Bind Cookbook
By Cricket Liu

Cricket Liu is the co-author of all of O'Reilly's Nutshell Handbooks on the Domain Name System, "DNS and BIND," "DNS on Windows NT," "DNS on Windows 2000," "DNS on Windows Server 2003," and the "DNS & BIND Cookbook," and was the principal author of Managing Internet Information Services.

Return to the O'Reilly Network.

Copyright © 2009 O'Reilly Media, Inc.