DNS & Bind Cookbook | O'Reilly Media

BUY THIS BOOK

Print Book $34.95

Safari Books Online

What is this?

Print Book £24.95

What is this?

Looking to Reprint this content?

Tell a friend

DNS & Bind Cookbook

By Cricket Liu
Price: $34.95 USD
£24.95 GBP

Cover | Table of Contents | Colophon

Chapter 1: Getting Started

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

All first moves in a Scrabble game have a few things in common: you play across the star, the opening square. You try to score high without opening up a premium square, particularly a Triple Word Score, for your opponent.

Most DNS setups start in very similar ways, too: you register a new domain and maybe a reverse-mapping domain; choose a version of BIND; download the BIND source code, if you need to, and build it; configure a primary master and slave name server; and make sure both name servers start at boot time.

This chapter will guide you through those opening moves and help you get your DNS infrastructure established.

You can't find information you need about the Domain Name System or BIND in this book.

For much more complete coverage of DNS theory and a step-by-step approach to setting up BIND name servers, pick up a copy of DNS and BIND, this book's close cousin.

For BIND configuration or operational problems, search the archives of one of the newsgroups or mailing lists on BIND:

For BIND 4 or 8, Google's archive of the newsgroup comp.protocols.dns.bind, at http://groups.google.com/groups?as_ugroup=comp.protocols.dns.bind&hl=en.
The archive of bind-users, the mailing list equivalent of comp.protocols.dns.bind, at http://marc.theaimsgroup.com/?l=bind-users.
And for BIND 9, the archive of the bind9-users mailing list is located at http://marc.theaimsgroup.com/?l=bind-users.

For information on the Domain Name System, you should look for relevant RFCs at http://www.rfc-editor.org/rfcsearch.html or you can search Google's archive of the newsgroup comp.protocols.std.dns, which is located at http://groups.google.com/groups?as_ugroup=comp.protocols.dns.std&hl=en. You might also check the BIND section of the Internet Software Consortium's web site, at http://www.isc.org/products/bind/.

This list is far from comprehensive; there's lots of information about DNS and BIND available on the Internet. If you don't find what you're looking for at one of the places mentioned here, use a good search engine to track down what you're looking for.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter will guide you through those opening moves and help you get your DNS infrastructure established.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Finding More Information About DNS and BIND

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You can't find information you need about the Domain Name System or BIND in this book.

For much more complete coverage of DNS theory and a step-by-step approach to setting up BIND name servers, pick up a copy of DNS and BIND, this book's close cousin.

For BIND configuration or operational problems, search the archives of one of the newsgroups or mailing lists on BIND:

For BIND 4 or 8, Google's archive of the newsgroup comp.protocols.dns.bind, at http://groups.google.com/groups?as_ugroup=comp.protocols.dns.bind&hl=en.
The archive of bind-users, the mailing list equivalent of comp.protocols.dns.bind, at http://marc.theaimsgroup.com/?l=bind-users.
And for BIND 9, the archive of the bind9-users mailing list is located at http://marc.theaimsgroup.com/?l=bind-users.

"Handy Mailing Lists and Usenet Newsgroups" in Chapter 3 of DNS and BIND.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Asking Questions You Can't Find Answers To

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You have a pressing question about DNS or BIND and can't find the answer in this book.

Check one of the relevant mailing lists or newsgroups:

The BIND Users mailing list, at bind-users@isc.org, discusses the operation and configuration of BIND name servers and resolvers. BIND Users is bidirectionally gatewayed to the Usenet newsgroup comp.protocols.dns.bind.
The BIND 9 Users mailing list, at bind9-users@isc.org, discusses the operation and configuration of BIND 9 name servers.

You can also try asking me at Cricket's Corner: http://www.menandmice.com/9000/9300_DNS_Corner.html. I can't answer every question, but I answer as many as I can.

Before asking a question on either of these mailing lists or the newsgroup, be sure to check their archives. See Section 1.2 for their locations. If everyone did this, the volume of messages on the mailing lists would drop precipitously, and newbies would get fewer curt or exasperated answers from cranky old-timers like me. (And we'd all live happily ever after.)

You may want to subscribe to one of the mailing lists or the newsgroup above, rather than just posing your question, getting an answer and disappearing until the next question pops into your head. Subscribing guarantees that you'll see any replies (since some folks won't copy you on responses) and will expose you to a wealth of DNS and BIND knowledge.

To subscribe to BIND Users or BIND 9 Users, send a message with the word "subscribe" in the body to bind-users-request@isc.org or bind9-users-request@isc.org, as appropriate.

Section 1.2 and "Handy Mailing Lists and Usenet Newsgroups" in Chapter 3 of DNS and BIND.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Getting a List of Top-Level Domains

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need a list of top-level domains (TLDs), possibly to figure out which one your organization belongs in.

See http://www.norid.no/domreg.html for an alphabetical list of top-level domains. See http://www.norid.no/domreg-alpha.html for a list of top-level domains alphabetized by country name (instead of the top-level domain label). Each list includes links to the registration authority for each TLD.

The most recent edition of DNS and BIND, as of this writing, also contains a list of top-level domains as its Appendix A. However, that list does not include the new generic top-level domains (e.g., biz and info), as they were introduced after that edition's publication.

Appendix A of DNS and BIND.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Checking Whether a Domain Name Is Registered

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to check whether a particular domain name is already registered, or who has registered that domain name.

Use the whois service offered by the appropriate registration authority, or use a command-line version of whois to look up registration information about the domain name you're interested in.

The Internet Assigned Numbers Authority, or IANA, maintains a list of country-code top-level domains (ccTLDs) at http://www.iana.org/cctld/cctld-whois.htm,which includes links to the web pages of those ccTLDs registration authorities. Many of these web pages offer online whois lookups. The web site http://www.allwhois.com/also includes links to many whois lookup facilities.

If your host's operating system includes a command-line whois client, you can use that to look up to look up registration information about the domain name. Newer whois clients automatically determine which whois server to query, so you can simply run:

$ whois domain-name

Older whois clients may require you to specify the whois server to use. For these, you can try tld.whois-server.net. For example:

$ whois -h ca.whois-servers.net risq.ca

The whois output usually contains information about the registrant (the person or organization that registered the domain name). For example:

$ whois isc.org

produces output that includes:

Registrant:
Internet Software Consortium (ISC2-DOM)
   950 Charter Street
   Redwood City, CA 94062
   US

   Domain Name: ISC.ORG

   Administrative Contact, Billing Contact:
      Conrad, David Randolph  (DC396)  drc@ISC.ORG
      Internet Software Consortium
      950 Charter Street
      Redwood City, CA 94063
      1-650-779-7061 (FAX) 1-650-779-7055
   Technical Contact:
      Vixie, Paul  (PV15)  paul@VIX.COM
      M.I.B.H., LLC
      950 Charter Street
      Redwood City, CA 94063
      +1.650.779.7000 (FAX) +1.650.779.7055

   Record last updated on 04-Mar-2002.
   Record expires on 05-Apr-2004.
   Record created on 04-Apr-1994.
   Database last updated on 14-Mar-2002 09:39:00 EST.

   Domain servers in listed order:

   NS-EXT.VIX.COM               204.152.184.64
   NS1.GNAC.COM                 209.182.195.77

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Registering a Domain Name

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to register a new domain name.

First, find out which registrars can register your domain name. For the generic top-level domains, this is easy: there's a list of registrars accredited by ICANN, the Internet Corporation for Assigned Names and Numbers, at http://www.icann.org/registrars/accredited-list.html. For other domains, start at http://www.norid.no/domreg.html: each entry is a link to the registry for that particular top-level domain. While the registry may not process registration requests, most registries provide links to their registrars on their web sites.

Next, choose a registrar. The registrars for a single top-level domain may offer different prices for registration and various associated services, such as hosting your zone on their name servers. For the gTLDs (com, net, and org), the cost of registration is usually between $15 and $35 annually (the wholesale price -- which you can't get, even if you "know someone in the business" -- is $6 per year). For other TLDs, the cost varies considerably.

Finally, register your domain name with the registrar. This is almost invariably a web-based process that involves specifying the domain name you want to register: personal information, such as your name, address, phone number and email address, and the domain names of the name servers you'll use (and possibly their IP addresses). Oh, and some means of allowing the registrar to bill you.

Choose your registrar wisely, and not solely on the basis of price. Some registrars offer notoriously poor customer service, and transferring to a different registrar is much more difficult than simply making the right decision the first time. Ask for recommendations from friends and colleagues, check newsgroups for sad tales of woe and, hypothetically, laudatory postings. And make sure you can work with the registrar the way you want to: using a web-based interface, if that's what you prefer, or via fax or a toll-free number (that they answer promptly).

Recipes Section 1.7 and Section 1.9, for registering name servers and changing registrars; and "Registering Your Zones" in Chapter 3 of

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Registering Name Servers

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to register a name server so that you can then register a domain name and have the corresponding subdomain delegated to it.

Registering name servers isn't normally done separately from registering a domain name; as part of the registration process for a domain name, you specify the domain names (and, sometimes, the IP addresses) of the name servers that will serve the corresponding zone. If the name servers you specify aren't already registered, the process will register them. See Section 1.6 for more information on that process.

If you find that you really need to register a name server independently of registering a new domain name, check your registrar's web site to see if they offer such a service. Network Solutions, for example, lets ISPs register name servers that their customers can then delegate to at https://www.netsol.com/cgi-bin/makechanges/itts/host.

Before you try to register name servers, make sure they aren't already registered. Any name server that has had even one subdomain of a top-level domain delegated to it is registered with that top-level domain's registry.

Also note that you shouldn't register a host that's not a name server, even if your registrar will let you. Some registrars (and their registries) don't check whether the host you're registering actually has any subdomains delegated to it. But if you register, say, your web server, you may have a hard time changing that information on short notice, and you may forget that your registry's name servers are giving out answers about your web server. Then, when you move your web server and change its address in your zone data, you'll wonder why some people are still trying the web server's old address.

Section 1.6 for registering a domain name.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Registering a Reverse-Mapping Domain

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to register the reverse-mapping domain that corresponds to your network.

Start by determining whether your reverse-mapping domain is already registered and, if not, which of its parent domains is registered. If your network is, say, 192.168.0/24, try looking up an SOA record for 0.168.192.in-addr.arpa. If you find an SOA record, then your network's reverse-mapping domain has been registered. If your network is part of a larger block of networks that your ISP owns, you may find that your ISP has registered it. Contact your ISP and ask them to change the delegation for that domain to your name servers. If you're not sure which email address to use for your ISP, the SOA record will show you the email address (in the second RDATA field) of a technical contact. You can also use the whois service offered by one of the regional address registries to look up contact information for your network, including phone numbers; see this recipe's "Discussion" for details.

If you don't find an SOA record, peel off the domain name's leading label and a dot and try looking up an SOA record for the result; in this example, you'd look up an SOA record for 168.192.in-addr.arpa. If that turns up an SOA record, use that record's email address or the associated whoisinformation (again, see the "Discussion") to find out whom to contact to have your domain delegated. If there's no SOA record, keep peeling off those labels until you find one. If you get all the way to in-addr.arpa, you may need to contact your regional address registry to register your network and the corresponding reverse-mapping zone with them.

The three regional address registries are APNIC, which serves Asia and the Pacific, ARIN, which handles the Americas, sub-Saharan Africa and the Caribbean, and RIPE, which deals with Europe and Saharan Africa. Each registry runs its own whois service, which contains information about all of that registry's registered networks. Here's a list of the registries' whois web pages and the domain names of their whois servers:

APNIC: The web page is at http://www.apnic.net/apnic-bin/whois2.pl

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Transferring Your Domain Name to Another Registrar

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to transfer your domain name to another registrar, possibly because they're cheaper or because they offer better service, or to consolidate all of your domain names with a single registrar.

Each registrar has a different transfer process. That process is usually initiated by the registrar you're transferring the domain name to, not the registrar you're transferring the domain name from. Check your registrar's web site for details.

Nearly all transfer processes will prompt you for the domain name to transfer, information about the administrative contact (and possibly other contacts), and billing information. The registrar you're transferring the domain name to will then send a form to the email address of the administrative contact for the domain name. The administrative contact will probably need to send the form to a particular email address to authorize the transfer and complete the process.

Make sure the email address of your domain name's administrative contact is up-to-date before initiating the transfer, or he won't receive the form the transferring registrar sends. (If you're not sure who the administrative contact is, you can use whois to find out, as described in Section 1.5.) If you need to change the administrative contact, you'll have to do that through your current registrar, not the registrar you're transferring to.

Recipes Section 1.5 and Section 1.6, for checking registration and registering a domain.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Choosing a Version of BIND

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to choose which version of BIND to build and install.

First, decide whether you'll compile your own version of BIND or use a version supplied by your operating system vendor. If you need to run a version of BIND supported by your vendor, that will limit your choices. Often, the version shipped with your operating system isn't very recent. See if your vendor offers a patch that will upgrade that version to something more current -- preferably at least BIND 8.2.3.

If you're willing to compile your own version of BIND, all you really need to decide is whether you want to run BIND 8 or BIND 9. For most administrators and most name servers, BIND 9 is a better choice. The latest released version of BIND 9 as of this writing, 9.2.1, supports nearly every feature that the latest version of BIND 8, 8.3.3, supports. Only administrators running extremely busy name servers (those receiving thousands of queries per second) or those that require one of the few features supported only by BIND 8 should consider running it.

Whether you choose to run BIND 8 or BIND 9, use the latest released version. Earlier versions inevitably contain bugs fixed in the newer version, and some contain dangerous vulnerabilities. Check the ISC's BIND Vulnerabilities web page, at http://www.isc.org/products/BIND/bind-security.html, to make sure the version you're considering isn't vulnerable.

I have sympathy for administrators compelled by corporate policy to run a vendor-supported version of BIND -- I come from a big corporate environment myself. Otherwise, I'd issue a blanket recommendation that everyone run the latest released version of BIND. Just be sure you understand what your vendor's support includes. Some vendors limit their support of BIND to fixing bugs in the code. If you're counting on their help with configuration issues, you may be out of luck.

The ISC's BIND Vulnerabilities web page at http://www.isc.org/products/BIND/bind-security.html and "Getting BIND" in Chapter 3 of DNS and BIND.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Finding Out Which Version of BIND You're Running

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You aren't sure which version of BIND you're running, or which version is installed on your host.

Start the name server and look for version information in its syslogoutput. You don't even need a named.conffile for named to read:

# /usr/sbin/named
Feb 25 17:17:33 bigmo named[54307]: starting BIND 9.2.0
Feb 25 17:17:33 bigmo named[54307]: using 1 CPU
Feb 25 17:17:33 bigmo named[54307]: loading configuration from '/etc/named.conf'
Feb 25 17:17:33 bigmo named[54307]: none:0: open: /etc/named.conf: file not found
Feb 25 17:17:33 bigmo named[54307]: loading configuration: file not found
Feb 25 17:17:33 bigmo named[54307]: exiting (due to fatal error)

Even though the name server doesn't start, you can still find the information you need in the output: This name server is running BIND 9.2.0.

Newer BIND name servers will also print their version if you execute them with the -voption:

$ /usr/sbin/named -v
BIND 9.2.0

If you go this route, however, make absolutely sure that the binary you're checking is the one that's running, and that you haven't recently upgraded to a new version of BIND without restarting the daemon.

If you don't find the output you're looking for in the syslogoutput, check syslog.confto make sure that you're checking the right file: namedusually logs to the syslog facility daemon.

If the name server is already running, you can send it a query for a TXT record attached to the pseudo-domain name version.bindin the CHAOSNET class:

$ dig version.bind. txt chaos

; <<>> DiG 9.2.0 <<>> version.bind. txt chaos
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40457
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind.                  CH      TXT

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "9.2.0"

;; Query time: 2 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Mon Feb 25 17:23:53 2002
;; MSG SIZE  rcvd: 48

The version appears in after the string "TXT" on the line immediately below the comment ";; ANSWER SECTION:".

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Getting BIND

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need a copy of BIND to build and install.

BIND's source code is freely available. The source code for BIND 9.2.1, the latest release of BIND 9 as of this writing, is available via anonymous FTP from ftp.isc.org as /isc/bind9/9.2.1/bind-9.2.1.tar.gz. The source code for the latest BIND 8 release, currently 8.3.3, is available from the same host as /isc/bind/src/cur/bind-8/bind-src.tar.gz.

If you're concerned about support for your operating system, you may want to check your vendor's web site to see if there's a supported patch you can apply to upgrade the version of BIND that came with your operating system to a newer version.

"Getting BIND" in Chapter 3 of DNS and BIND.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Building and Installing BIND

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to build and install BIND.

Once you've downloaded BIND's source code, building and installing it is usually easy. First, unpack the distribution. The BIND 9 distribution unpacks into its own subdirectory, named for the release, so you can unpack it with:

# cd /usr/local/src       or your source directory
# tar -zxvf /tmp/bind-9.2.1.tar.gz
[Lots of output]
# cd bind-9.2.1

BIND 8 distributions unpack into the current working directory, so you may want to create a subdirectory for the distribution before unpacking:

# cd /usr/local/src
# mkdir bind-8.3.3
# cd bind-8.3.3
# tar -zxvf /tmp/bind-src.tar.gz
[Lots of output]

Next, make sure that the build will use the appropriate settings for your operating system. BIND 9 uses the automagical configure program to determine what it needs to know about your operating system and the installation environment. You may still want to specify compilation options, alternate installation directories and the like; to find out what aspects of the build and the installation you can configure, read the README file in the top-level directory of the distribution, or run configure - -help. Once you've decided, run configure with those options, and once it's finished, run make:

# ./configure
# make

BIND 8 still uses a Makefile. To change compilation options, find the subdirectory of src/port relevant to your operating system -- for example, src/port/freebsd for FreeBSD. Edit the Makefile.set file in that directory as you see fit, then build BIND with:

# make clean
# make depend
# make all

Finally, to install either BIND 8 or BIND 9, run:

# make install

You'll probably need to su to root to install the various binaries and libraries.

If you have problems building BIND, check the archives of the mailing lists and newsgroups in Section 1.2, and any newsgroups specific to your operating system for hints. You might also want to look for BIND in archives of precompiled binaries for your operating system, as described in Section 1.14.

Section 1.12 for getting the BIND source code and Section 1.14 for getting precompiled copies of BIND, and Appendix C of

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Getting a Precompiled Version of BIND

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need a copy of BIND precompiled for your particular operating system.

Search the software archive for your operating system for a precompiled version of BIND. Here are the locations of precompiled versions of BIND for a few popular operating systems:

FreeBSD 4.6: BIND 9.2.1: ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5-current/net/bind9-9.2.1.tgz
Red Hat Linux 7.3: BIND 9.2.0: Ftp://ftp.redhat.com/pub/redhat/linux/7.3/en/os/i386/RedHat/RPMS/bind-9.2.0-8.i386.rpm
Solaris 8: BIND 9.2.1: http://www.ibiblio.org/pub/solaris/freeware/sparc/8/bind-9.2.1-sol8-sparc-local.gz
Windows 2000 and XP: BIND 9.2.1: ftp://ftp.isc.org/isc/bind/contrib/ntbind-9.2.1/BIND9.2.1.zip

This option doesn't allow any customization of compile-time options, like whether BIND is built multithreaded or with IPv6 support, so I'd recommend compiling your own copy of BIND if you can.

Recipes Section 1.12 and Section 1.13 for getting a copy of BIND and compiling it yourself.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Creating a named.conf File

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to create a named.conf file for a name server.

Use your favorite editor to create the named.conf file, usually in the /etc directory. Nearly every name server's named.conf file contains an options statement near the beginning specifying the name server's working directory:

options {
    directory "/var/named";
};

The options statement often contains a good deal more than that, too, including access lists, etc.

After the options statement, add zone statements to configure the name server as authoritative for one or more zones, as described in Recipes Section 1.16, Section 1.17, and Section 1.18. Finally, if you're running a BIND 8 name server, add a special zone statement for the root hints file, which tells the name server the domain names and addresses of the root name servers:

zone "." {
    type hint;
    file "named.root";
};

Check whether your installation came with a root hints file, and make sure the filename in the file substatement matches its name. ("named.root" is just a common name for the root hints file.) If you don't have a root hints file, see Recipe 2.11 for instructions on downloading one.

You must specify -- and create! -- a working directory for the name server because there's no default. Some operating systems recommend /var/named or /etc/namedb, but the choice is really yours: just make sure the directory is on a filesystem that is mounted when the name server starts, and that the directory has enough space for your zone data files.

Recipes Section 1.16 and Section 1.17 for configuring the name server as primary master or slave for a zone, respectively, Section 1.18 for configuring the name server as authoritative for more than one zone, and Section 2.12 for updating (or downloading) a root hints file.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Configuring a Name Server as the Primary Master for a Zone

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to configure a name server to be the primary master for a zone.

Add the appropriate zone statement to the name server's named.conf file.

The zone statement specifies the domain name of the zone and the name of the zone data file, and that this name server is the zone's primary master (with

type
master

zone "foo.example" {
    type master;
    file "db.foo.example";
};

Make sure you get the punctuation right: BIND name servers are notoriously unforgiving of incorrect syntax. Double-quote the domain name of the zone and the name of the zone data file. Enclose the type and file substatements in curly braces, and terminate both substatements and the zone statement with semicolons.

You must, of course, also create the zone's data file, which contains all of the resource records in the zone, including the zone's SOA record and NS records. That's covered in Section 2.2.

Note that this example shows the most basic zone configuration: I didn't use any zone-specific options, such as an access list for transfers of this zone.

Section 2.2, for instruction on creating a zone data file; and"Running a Primary Master Name Server" in Chapter 4 of DNS and BIND.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Configuring a Name Server as a Slave for a Zone

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to configure a name server to be a slave for a zone.

Add the appropriate zone statement to the name server's named.conf file.

The zone statement specifies the domain name of the zone, the IP address of the master name server, the name of the backup zone data file, and that this name server is a slave for the zone (with

type
slave

zone "foo.example" {
    type slave;
    masters { 192.168.0.1; };
    file "bak.foo.example";
};

When configuring a slave zone, there's no need to create the backup zone data file: The name server will write the backup zone data file after it has transferred the zone from the master name server you designated. The slave name server will transfer the zone each time its check of its master shows that the master's copy of the zone has a higher serial number than the slave's copy.

The master name server doesn't need to be the zone's primary master. A slave can just as easily transfer a zone from another of the zone's slaves, as long as that slave gets its zone data from the primary master -- directly or indirectly. You can even specify that a slave use multiple master name servers: just list their IP addresses in the masters substatement in the order in which you want the slave to use them.

It's a good idea to distinguish backup zone data files from zone data files for primary master zones; I use the prefix "bak" instead of "db" for backup zone data files. This cue makes it less likely that I'll try to make changes to a backup (and hence read-only) copy of a zone's data.

Note that this example shows the most basic zone configuration: I didn't use any zone-specific options, such as an access list for transfers of this zone.

"Running a Slave Name Server" in Chapter 4 of DNS and BIND.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Configuring a Name Server as Authoritative for Multiple Zones

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to configure a name server to be authoritative (i.e., primary master or slave) for more than one zone.

Add multiple zone statements to the name server's named.conf file. For example, to make the name server the primary master name server for the foo.example zone and a slave for the bar.example zone, you might use these two zone statements:

zone "foo.example" {
    type master;
    file "db.foo.example";
};

zone "bar.example" {
    type slave;
    masters { 192.168.0.1; };
    file "bak.bar.example";
};

A single name server can be authoritative for multiple zones at once. In fact, there are individual name servers on the Internet that are authoritative for over 100,000 zones. Imagine the size of the named.conffile on that name server!

The name server's relationship to the zone is defined on a zone-by-zone basis, in the type substatement. So a name server can be the primary master for some zones while it's a slave for others. It can't be both primary master and slave for the same zone, however.

The order of the zonestatements isn't important. They don't depend on each other in any way, so you can list them in any order you like.

Recipes Section 1.16 and Section 1.17 for the syntax of individual zone statements, and Chapter 4 of DNS and BIND, as usual.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Starting a Name Server

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to start a name server.

Run the program named or, if you're using BIND 8, use ndc:

# named

or:

# ndc start

If root's path doesn't include the directory in which the named executable is installed (often /usr/sbin), you'll have to specify the full path:

# /usr/sbin/named

The pathname of the file ndc executes to start named is compiled-in. If it's not correct, you can edit the file Makefile.set and set the variable DESTSBIN to the directory in which named actually lives. Then recompile ndc with:

# cd bind-distribution-directory/src/bin/ndc
# make clean
# make ndc

The Makefile.set file you should modify is in the directory src/port/<os>, where <os> indicates the operating system you run (e.g., freebsd ).

If you need to start named with command-line arguments, you can specify them on the command-line:

# named -c /tmp/named.conf

Or, if you use ndc, you can specify them after the argument start:

# ndc start -c /tmp/named.conf

Section 3.2 for setting up and using ndc.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Stopping a Name Server

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to stop a running name server.

Use ndc (for BIND 8 name servers) or rndc (for BIND 9 name servers):

# ndc stop

or:

# rndc stop

ndc stopand rndc stop both tell the running name server to clean up and exit. "Cleaning up," in this age of dynamically updated zones, means writing the zone data files of any "dirty" zones to disk. ("Dirty" zones are zones that have been dynamically updated but not yet written to disk.)

Should you ever need to stop the name server without saving "dirty" zones to disk, BIND 9 offers the halt command:

# rndc halt

If you don't have ndc or rndc at your disposal (and you won't be able to use rndc until you've set up rndc.conf and a controls statement, as described in Section 3.3), you can still kill named with signals. With BIND 8, use SIGTERM:

# kill `cat /var/run/named.pid`

With BIND 9, you can use SIGTERM or SIGINT:

# kill -INT `cat /var/run/named.pid`

Recipes Section 3.2 and Section 3.3 for setting up ndc and rndc, respectively, and "Controlling the Name Server" in Chapter 7 of DNS and BIND.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Starting named at Boot Time

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want namedto start at boot time.

On many Unixish operating systems, namedwill start automatically if the startup scripts see a named.conffile in the right directory, usually /etc. On others, you just need to make minor changes to a startup configuration file. However, on some Unixish operating systems, you may need to add the necessary lines to the appropriate file or create a special link to start up named.

On BSD-based systems, namedis usually started by one of the startup scripts, such as /etc/rc.network. Here's the relevant part of /etc/rc.networkin FreeBSD 4.5:

case ${named_enable} in
[Yy][Ee][Ss])      
    echo -n ' named';       ${named_program:-named} ${named_flags}
    ;;
esac

In this case, the variables named_enable, named_programand named_flagsare set in /etc/rc.conf:

named_enable="YES"
named_flags="-t /etc/namedb -u bind"

named_program isn't set in /etc/rc.conf, so it defaults to namedin /etc/rc.network.

Note that I use the -t and -uoptions to tell namedto call chroot( )and to give up root privileges. This requires some special setup; see Recipes Section 7.8 and Section 7.9 for details.

If you're running a BSD-based operating system, just edit /etc/rc.conf, change named_enableto "YES"and set the other named_*variables, if you need to.

On Solaris 8, named is started from /etc/init.d/inetsvc:

SunOS 5.8
#
# If this machine is configured to be an Internet Domain Name System (DNS)
# server, run the name daemon.  Start named prior to: route add net host,
# to avoid dns gethostbyname timout delay for nameserver during boot.
#
if [ -f /usr/sbin/in.named -a -f /etc/named.conf ]; then
        echo 'starting internet domain name server.'
        /usr/sbin/in.named &
fi

If you haven't installed the BIND name server as in.named, you can adjust the (two!) occurrences of in.named in the script appropriately.

If your operating system uses System V Release 4-style startup scripts, namedis usually started by a shell script called namedin the /etc/rc.d/init.dor /etc/init.ddirectory. If you create a link in the directory /etc/rc.d/rc3.d

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Zone Data

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

With 27 different tiles in an English Scrabble set ("A" through "Z" plus the blanks) and 7 tiles in a rack, you can draw billions of different combinations. And with over 100,000 words in the Official Word List, you can assemble a lot of words from almost any of those combinations.

In DNS, there are fewer than 300 possible types of resource records, and of those, only a handful could be called common. Still, you can do a remarkable variety of interesting things with those records.

All resource records, when written in plain text (as they'd appear in a zone data file), share the following format:

[owner] [TTL] [class] <type> <RDATA>

The fields in square brackets ("[" and "]") are optional, while the fields between angle brackets ("<" and ">") are mandatory. Section 2.2 explains what happens when you leave out one or more of those fields.

The RDATA field often consists of multiple subfields. The number of subfields required depends upon the type of record. For example, SOA records take seven RDATA subfields, while A and NS records need just one.

A zone data file contains the resource records attached to all of the domain names in a zone. A zone's primary master name server loads the zone data file, and the zone's slaves transfer the zone data from the primary master.

You need to create a data file for a zone.

Using your favorite editor, create a file in the primary master name server's working directory. Name the file after the zone whose resource records it will contain. For example, for the foo.examplezone, you might call the zone data file db.foo.example.

Begin the file with a $TTL control statement. This tells other name servers (not those authoritative for the zone) how long they may cache records from this zone by specifying the zone's default time to live. You can specify the value as an integer number of seconds or as a scaled value: an integer followed by s for seconds, m for minutes, h for hours, d for days or w for weeks. For example, you can specify a time to live of one day with either:

$TTL 86400

or:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

All resource records, when written in plain text (as they'd appear in a zone data file), share the following format:

[owner] [TTL] [class] <type> <RDATA>

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Creating a Zone Data File

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to create a data file for a zone.

$TTL 86400

or:

$TTL 1d

You can even concatenate two scaled values, like so:

$TTL 1d12h

Time to live values between one hour and one day are common.

Next, add an SOA record for the zone. The SOA record contains information about the whole zone, including how often the zone's slave name servers should check to see whether the zone has changed. The SOA record begins with the zone's domain name, a specification of the zone's class (which is almost always IN, for Internet), and the type mnemonic SOA. After the type, the SOA record requires seven fields:

The MNAME field: Specify the domain name of the zone's primary master name server.
The RNAME field: Specify an email address at which the administrator of the zone can be reached. Substitute a dot (".") for the "@" in the email address.
The zone's serial number: If you'll only be changing the zone manually, by editing the zone data file, consider using the format YYYYMMDDVV, where YYYY is the year, MM is the numeric month (from 1 to 12), DD is the date, and VV is a two-digit version number that starts at 00. This will give you a handy indicator of when you last updated the zone.
The zone's refresh value: This specifies how frequently slave name servers for the zone should check their master name server to see whether the zone's serial number has been incremented (indicating that the zone has changed). This value isn't particularly important if you use the NOTIFY mechanism, which enables your primary master name server to

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Adding a Host

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to add a host to DNS.

Add an A and a PTR record for the host to the appropriate zones (which are almost certainly two different zones: a forward-mapping and a reverse-mapping zone). For example, to add a host called host.foo.example with the IP address 10.0.0.1 to DNS, you could add this record to the foo.example zone data file:

host.foo.example.    IN    A    10.0.0.1

And you'd add this record to the zone data file for the reverse-mapping zone, which might be 10.in-addr.arpa, 0.10.in-addr.arpa, or 0.0.10.in-addr.arpa, depending on how you break up administration of your reverse-mapping domain:

1.0.0.10.in-addr.arpa.    IN    PTR    host.foo.example.

You're free to take advantage of the origin in the file to abbreviate the resource records. For example, if you're adding the A record to a line in the zone data file in which the origin is foo.example, you can write:

host    IN    A    10.0.0.1

If you're adding the PTR record on a line in which the origin is 0.0.10.in-addr.arpa, you can write:

1    IN    PTR    host.foo.example.

Since the default class is IN, for Internet, you can leave out the IN, too.

It's important to add PTR records for your hosts. Without PTR records, your hosts' addresses won't map to domain names, so they won't be able to access services that require reverse mapping, and your network management software may not identify them automatically.

You may also want to add other records for the host. If the host's domain name might appear on the right side of an email address, add an MX record specifying where mail addressed to the host should be delivered.

Section 2.5, for how to add an MX record; Section 2.10 to limit how long the records can be cached, Section 2.11 to learn how to handle multihomed hosts, and Chapter 4 of DNS and BIND.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Adding an Alias

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to create an alias from one domain name to another.

Add a CNAME record to the zone that the alias belongs in. For example, to make a.foo.example an alias for b.bar.example, add this CNAME record to the foo.example zone data file:

a.foo.example.    IN    CNAME    b.bar.example.

Note that a CNAME record makes the alias equivalent to the target of the alias. Queries for any types of record attached to the alias will end up as queries for the same type of record, but attached to the domain name the alias points to. Consequently, you can't add any other types of records to a domain name that is an alias.

You also shouldn't use aliases on the right side of other types of records, such as NS and MX records. The consumers of NS and MX records -- name servers and mail servers, respectively -- don't expect aliases on the right side and therefore don't process them correctly. The only kind of record that allows an alias on the right side is the CNAME record itself: You can point an alias to another alias, as long as the alias chain ends at a non-alias domain name. Make sure the chain isn't more than eight links long, though, and beware alias loops.

Finally, note that the CNAME record belongs in the zone that contains the domain name of the alias, not the target of the alias.

Section 2.7 to learn how to set up virtual web hosts; and Chapter 4 and the "Using CNAME Records" section of Chapter 16 in DNS and BIND.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Adding a Mail Destination

Content preview·