BIND v. 8 - An Overview

by Rick Moen

Revised: Thursday, 2001-08-23

Master version will be at, and I'll try to improve it there.

History and Context:

About the time the ARPAnet adopted TCP/IP (early '80s), admins of the several hundred machines involved realised they had a problem: The master HOSTS.TXT file listing all those machines, maintained by the Network Information Center (NIC) at SRI International in Menlo Park, CA, was getting unwieldy. HOSTS.TXT was/is a full listing of sundry details about those machines, issued weekly until 1992. Stripped of non-Unix-relevant details, it gave us the standard /etc/hosts file format.

HOSTS.TXT (and /etc/hosts) was a static association between hostnames and IP addresses, allowing either to be looked up, given the other. (Remember that lookup can go either way.) The NIC at SRI was passed to Network Solutions, Inc. of Virginia, a consortium formed by several companies initially under NSF grant (and now Dept. of Commerce contract), became known as the InterNIC, and now is in bureaucratic limbo as a result of organisational intrigue among the increasingly commercial Network Solutions (now owned by Verisign), the almost-self-appointed ICANN group, and the U.S. Dept. of Commerce.

Paul Mockapetris of U.C. Berkeley's Computer Science Research Group (CSRG, the BSD people) created the JEEVES program to be a scalable, decentralised replacement for HOSTS.TXT. Shortly afterwards, Paul Vixie of the Internet Software Consortium (ISC) wrote its replacement, BIND (Berkeley Internet Name Daemon) -- introducing the Domain Name System in so doing (replacing the increasingly unworkable "bang-path" system, where one specified an absolute path relative to a "well-known" host, e.g., "ucbvax!zgp!zork!uncle-enzo").

I call DNS decentralised, but it puts all names in a theoretical hierarchy relative to a "root" or "origin" point, denoted by a period. The divisions below root are the Top Level Domains (TLDs): com, net, org, mil, gov, edu, us, ca, mx, no, uk,....

One subdivides further into Second Level Domains (the "domains" one registers), and arbitrarily as desired beyond that, e.g., .

BIND went up to v. 4.x, then was rewritten as v. 8.x to have more-flexible security archtitecture and a different configuration file format, and then stalled at 8.x for a long time. 8.x is obsolescent, as we'll discuss below.

Client/Server Architecture:

DNS requires at least one DNS server exist: This machine runs (e.g.) BIND. All machines that want to use DNS services must have the corresponding client software, called the DNS resolver. On Linux, this is built into the system libraries, and configured using /etc/resolv.conf . But don't forget that /etc/nsswitch.conf also controls the resolver's functioning, determining whether other sources of name information such as LDAP, NIS+, etc. should be consulted instead, and in what order of preference.

What Makes a Nameserver Tick:

A DNS nameserver, at a minimum, has a list (named.root, root.hints, or db.root) of servers that have guaranteed-accurate (authoritative) information about TLDs.[1] If it has only that, it is called a caching nameserver, in that it has no information of its own, but just stores answers to queries it has passed on to other nameservers. Linux distributions' default setup of BIND is exactly like this.

In addtition, it can have tables of DNS information (forward and reverse lookup) about specific parts of the total namespace. These are stored in "zonefiles". What zonefiles a nameserver manages is described in /etc/named.conf . Example:

  options {
          directory "/var/cache/bind";
          forwarders {

  zone "." {
          type hint;
          file "/etc/bind/db.root";

  zone "localhost" {
          type master;
          file "/etc/bind/db.local";

  zone "" {
          type master;
          file "/etc/bind/db.127";

  #For Rick Moen
  zone "" {
          type master;
          file "/etc/bind/";
          allow-transfer {

  #For Seth David Schoen
  zone "" {
          type slave;
          file "/var/cache/bind/";
          masters {

If you see /etc/named.boot (with a different internal format), then it's a BIND v. 4.x server, not 8.x. BIND v. 8 includes a perl script to generate named.conf from named.boot .

The "slave" vs. "master" distinction is one of whether this nameserver is publisher or publishee for the zone in question. A nameserver that is slave for a particular domain contacts its master occasionally to see if it needs to refresh its zonefile copy (called a "zone transfer").

Example forward-lookup zonefile:

; hosts file for named for /etc/bind/
$ORIGIN linuxmafia.COM.  
@       IN      SOA     linuxmafia.COM.         rick.deirdre.NET. (
                        2001032301              ; serial
                        10800                   ; refresh 3 hours
                        3600                    ; retry 1 hour
                        3600000                 ; expire 1000 hours
                        86400                   ; minimum 24 hours
                IN      NS      myrddin.imat.COM.
                IN      NS
@               IN      A
                IN      MX      0       linuxmafia.COM.
uncle-enzo      IN      A
enzo            IN      A
mail            IN      A
www             IN      A
ftp             IN      A
                IN      HINFO   AMI-486DX2/66   Linux-v2.0.36
                IN      MX      10      uncle-enzo
guido           IN      A
debian          IN      A
                IN      HINFO   FIC-K6/233      Linux-v.2.2.1
                IN      MX      10      guido
tikihut         IN      A
                IN      MX      10
                IN      HINFO   unknown         Linux
; "Ben Kennnedy" <>
tungsten        IN      A
                IN      MX      10
                IN      HINFO   unknown Linux
; "Bill Schoolcraft"  <>

SOA (start of authority) header explanation:

serial        = integer used to signal a querying slave server that there's
                a new zonefile it must fetch.  By convention, use date + 
                two digits, and count upwards from 00 as you save changes
                and restart BIND.
refresh       = how often in seconds slaves should start trying to ask the
                master if there's a new zonefile.
retry         = how often to subsequently reattempt contact after a refresh
                attempt fails (shorter interval)
expire        = time after which non-refreshed data should be regarded as 
                stale and no longer used (must be set higher than refresh)
TTL (minimum) = time to live at other caching servers other than slaves

Other items:

SOA           = start of authority.  Puts limits on how the data are
                used, indicates what host is master, and indicates how 
                to reach the admin.
IN            = Internet.  There are not yet any other keyword for this
A             = Address.  Regular forward name-to-IP record.
NS            = Nameserver.
MX            = Mail exchanger.  Lower number indicates higher priority.
                These are the places where mail addressed to the named
                host should be delivered, instead.  Each MX will accept
                mail and then redeliver it to the lowest-numbered host
                it can reach.  Thus, the higher-numbered MXes function as
                temporary mail caches.
HINFO         = Host info (text field of arbitrary information you want
                to put there).
CNAME         = (not seen here) Canonical Name or host alias name

Note the period after complete hostnames: This is the root or origin. If you fail to specify it, BIND will assume you mean relative to the value of $ORIGIN (also denoted by "@").

Note the odd, unique-to-BIND convention for specifying the admin's e-mail address: "": Turn the "@" symbol into a period, since "@" is reserved to mean $ORIGIN.

Spot the bonehead error: Only one mail exchanger (MX) for I fixed this, only to be bitten by the fact that myrddin.imat.COM refuses to handle mail for hosts with no matching reverse DNS. (I fixed that next.) Which leads us to:

Example reverse-lookup file:

70              IN      SOA     myrddin.imat.COM. rrc.myrddin.imat.COM.
                                        259200 )
                IN      NS      myrddin.imat.COM.
                IN      NS      lll-winken.llnl.GOV.
                IN      NS      polaris.llnl.GOV.
                IN      NS
1       IN      PTR     myrddin.imat.COM.
2       IN      PTR     nevyn.imat.COM.
3       IN      PTR     wyrm.imat.COM.
4       IN      PTR     grendel.imat.COM.
5       IN      PTR     taliesin.imat.COM.
10      IN      PTR     seahunt.imat.COM.
22      IN      PTR
21      IN      PTR     hugin.imat.COM.
31      IN      PTR     atlas.sfpcug.ORG.
32      IN      PTR     eos.sfpcug.ORG.
51      IN      PTR     mocha.coffeenet.NET.
52      IN      PTR     latte.coffeenet.NET.
53      IN      PTR     espresso.coffeenet.NET.
54      IN      PTR     sumatra.coffeenet.NET.
55      IN      PTR     java.coffeenet.NET.
56      IN      PTR     kenya.coffeenet.NET.
57      IN      PTR     macchiato.coffeenet.NET.
58      IN      PTR     mail.coffeenet.NET.
59      IN      PTR     crema.coffeenet.NET.
60      IN      PTR     americana.coffeenet.NET.
100     IN      PTR     mordred.imat.COM.
101     IN      PTR
102     IN      PTR
103     IN      PTR
104     IN      PTR
105     IN      PTR

PTR           = Pointer.  Regular reverse IP-to-name record.

Note the reverse-naming convention that this zone's name is the IP net number ( inverted (as 70.174.140) with "" appended. Thus, the first PTR record specifies what the reverse lookup value for reverse-domain entry "" is.

Note that "" is a TLD, just like ".com". (Well, technically, ".arpa" is the TLD and "" is its one and only SLD.)

There are many services on the Net -- e.g., extremely paranoid e-mail and ftp server hosts -- that refuse to do business with remote machines whose forward and reverse lookups don't match. If such a host got a connection from IP address, it would first see what reverse lookup value it got from "". From the above, it would get "myrddin.imat.COM." Then, it would do a forward lookup on that result: In the authoritative zonefile for SLD "imat.COM" (not shown), it would find an "A" record associating hostname "myrddin.imat.COM" to IP address . And the check would be complete.

Omitting correct reverse DNS (or failing to ensure that it matchies the corresponding forward lookups) is a common configuration error: Most businesses fail to set up reverse DNS at all, and many ISPs drag their feet on either setting it up correctly or delegating it for their IP ranges.

If you have less than a class C subnet, delegating the reverse zone for just your netblock is tricky[2], and many ISPs don't even know how to do it.

Delegation Technique:

(Not detailed here.) For a given subdomain discussed in a zonefile, you can include an NS record to refer queries to that domain to the specified nameserver host. Thus, NS1.COMPANY.COM might refer queries about all hosts of the form * to some subsidiary nameserver at HQ that holds all relevant records for that subdomain.

Inherent Security Problem in Any DNS:

DNS reveals information about the network it serves. If your company's complete DNS is publicly reachable, attackers can use it for "resource discovery": figuring out where the crown jewels are, and what's worth getting at. Some advanced techniques such as "split DNS" is used to limit the amount of outside exposure.[3]

Security Problems: BIND v. 8 end-of-life

Around 1999, ISC decided v. 8 could no longer be maintained and had ultimately hopeless security problems, and so commissioned a from-scratch rewrite, which resulted in BIND v. 9.x . 9.x is totally compatible, except that it will not tolerate syntax errors condoned by 8.x. Any clean set of 8.x zonefiles and named.conf will migrate perfectly to 9.x. Mine did.

The BIND v. 8 security problem can be partially contained by running it in a chroot jail, but this is just a band-aid solution because any process with root authority can break out of a chroot jail.

Common errors:


dig, nslookup:    General-purpose command-line tools for removely
                  querying DNS servers.  nslookup is "deprecated" because
                  it relies on some BIND v. 8 characteristics that will
                  be going away.
nslint, dnswalk:  Utilities to traverse zonefiles looking for errors.
cvs:              Need I mention that you should check all your DNS
                  files into CVS?  Otherwise, you'll have fun figuring
                  out how and when you messed them up.
pdnsd:            Good caching-only DNS server.  Unlike a caching-only
                  BIND server, this software stores its cache on-disk
                  rather than in RAM only.  That makes it very useful
                  for workstations and laptops.


1. Configure your copy of BIND v. 8 to serve up deliberately-bogus zonefile "" (which you'll have to populate), as a master server. Make sure you also set up a matching reverse file reflecting your local IP addresses. Run it, and query some of its records using nslookup or dig.

You'll find a complete set of zonefiles and configuration files for your reference, at . This is from my former landlord Richard Couture's DNS setup, and has been frequently cited as a teaching example in serious, in-depth DNS classes.

2. Configure a second machine to do slave DNS for those domains. Update the DNS on the master server, restart. Verify that the updated information propagates to the slave server.

Further Information:

DNS and BIND by C. Liu and P. Albitz from O'Reilly & Associates (ISBN 0-937175-82-X). 3rd edition.


Chroot BIND8 HOWTO (covers v. 8)

Chroot BIND HOWTO (covers v. 9)

Secure BIND Template by Rob Thomas


[1] The named.root file distributed by the ISC is one issued by Network Solutions, Inc. in semi-cooperation with ICANN and the ISO3166 Committee at DIN in Berlin, and is available from, or by a cron job detailed here: One can replace it, if desired, with a broader consensus list of "root servers" , e.g., one from OpenNIC.