by Paul Albitz, Cricket Liu

View All Available Formats & Editions

This edition edition brings readers up to date on the new 9.1.0 and 8.2.3 versions of BIND along with the older 4.9 version. There's also more extensive coverage of NOTIFY, IPv6 forward and reverse mapping, transaction signatures, and the new DNS Security Extensions; and a new section on accommodating Windows 2000 clients, servers and Domain Controllers.See more details below


This edition edition brings readers up to date on the new 9.1.0 and 8.2.3 versions of BIND along with the older 4.9 version. There's also more extensive coverage of NOTIFY, IPv6 forward and reverse mapping, transaction signatures, and the new DNS Security Extensions; and a new section on accommodating Windows 2000 clients, servers and Domain Controllers.

Editorial Reviews

In DNS And BIND, Paul Albitz and Cricket Liu efficiently collaborate to present an invaluable reference on one of the fundamental building blocks of the Internet which is the distributed host information database responsible for translating names into addresses, routing mail to its proper destination, and many other services. The topics covered in a very accessible and highly recommended text include what DNS is and how it works; how to find your a place in the Internet's namespace; setting up name servers; using MX records to route mail; configuring hosts to use DNS name servers; subdividing domains; securing a name server; ne BIND 9 features; DNS Security Extensions and Transaction Signatures; mapping one name to several servers for load sharing; dynamic updates, asynchronous notification of changes to a zone, and incremental zone transfers; troubleshooting; and DNS programming using the resolver library, as well as Per's Net::DNS module. DNS And BIND is an impressive contribution to personal and professional computer reference shelf collections.

Product Details

O'Reilly Media, Incorporated
Publication date:
Edition description:
Fourth Edition
Product dimensions:
7.04(w) x 8.96(h) x 1.10(d)

Read an Excerpt

Chapter 11: Security

In this chapter:
Securing Your Name Server
DNS and Internet Firewalls
The DNS Security Extensions

"I hope you've got your hair well fastened on?"
he continued, as they set off.

"Only in the usual way," Alice said, smiling.

"That's hardly enough," he said, anxiously.
"You see the wind is so very strong here.
It's as strong as soup."

"Have you invented a plan for keeping the hair from being blown
off?" Alice enquired.

"Not yet," said the Knight. "But I've got a plan
for keeping it from falling off."

Why should you care about DNS security? Why go to the trouble of securing a service that mostly maps names to addresses? Let us tell you a story.

In July 1997, during two periods of several days, users around the Internet who typed www.internic.net into their web browsers thinking they were going to the InterNIC's web site instead ended up at a web site belonging to the AlterNIC. (The AlterNIC runs an alternate set of root name servers that delegate to additional top-level domains with names like med and porn.) How'd it happen? Eugene Kashpureff, then affiliated with the AlterNIC, had run a program to "poison" the caches of major name servers around the world, making them believe that www.internic.net's address was actually the address of the AlterNIC web server.

Kashpureff hadn't made any attempt to disguise what he had done; the web site that users reached was plainly the AlterNIC's, not the InterNIC's. But imagine someone poisoning your name server's cache to direct www.amazon.com or www.wellsfargo.com to his own web server, conveniently well outside local law enforcement jurisdiction. Further, imagine your users typing in their credit card numbers and expiration dates. Now you get the idea.

Protecting your users against these kinds of attacks requires DNS security. DNS security comes in several flavors. You can secure transactions--the queries, responses, and other messages your name server sends and receives. You can secure your name server, refusing queries, zone transfer requests, and dynamic updates from unauthorized addresses, for example. You can even secure zone data by digitally signing it.

Since DNS security is one of the most complicated topics in DNS, we'll start you off easy and build up to the hard stuff.


BIND 8.2 introduced a new mechanism for securing DNS messages called transaction signatures, or TSIG for short. TSIG uses shared secrets and a one-way hash function to authenticate DNS messages, particularly responses and updates.

TSIG, now codified in RFC 2845, is relatively simple to configure, lightweight for resolvers and name servers to use, and flexible enough to secure DNS messages (including zone transfers) and dynamic updates. (Contrast this with the DNS Security Extensions, which we'll discuss at the end of this chapter.)

With TSIG configured, a name server or updater adds a TSIG record to the additional data section of a DNS message. The TSIG record "signs" the DNS message, proving that the message's sender had a cryptographic key shared with the receiver and that the message wasn't modified after it left the sender.1

One-Way Hash Functions

TSIG provides authentication and data integrity through the use of a special type of mathematical formula called a one-way hash function. A one-way hash function, also known as a cryptographic checksum or message digest, computes a fixed-size hash value based on arbitrarily large input. The magic of a one-way hash function is that each bit of the hash value depends on each and every bit of the input. Change a single bit of the input and the hash value changes dramatically and unpredictably--so unpredictably that it's "computationally infeasible" to reverse the function and find an input that produces a given hash value.

TSIG uses a one-way hash function called MD5. In particular, it uses a variant of MD5 called HMAC-MD5. HMAC-MD5 works in a keyed mode in which the 128-bit hash value depends not only on the input, but also on a key.

The TSIG Record

We won't cover the TSIG record's syntax in detail because you don't need to know it: TSIG is a "meta-record" that never appears in zone data and is never cached by a resolver or name server. A signer adds the TSIG record to a DNS message, and the recipient removes and verifies the record before doing anything further, such as caching the data in the message.

You should know, however, that the TSIG record includes a hash value computed over the entire DNS message as well as some additional fields. (When we say "computed over," we mean that the raw, binary DNS message and the additional fields are fed through the HMAC-MD5 algorithm to produce the hash value.) The hash value is keyed with a secret shared between the signer and the verifier. Verifying the hash value proves both that the DNS message was signed by a holder of the shared secret and that it wasn't modified after it was signed.

The additional fields in the TSIG record include the time the DNS message was signed. This helps combat replay attacks, in which a hacker captures a signed, authorized transaction (say a dynamic update deleting an important resource record) and replays it later. The recipient of a signed DNS message checks the time signed to make sure it's within the allowable "fudge" (another field in the TSIG record).

Configuring TSIG

Before using TSIG for authentication, we need to configure one or more TSIG keys on either end of the transaction. For example, if we want to use TSIG to secure zone transfers between the master and slave name servers for movie.edu, we need to configure both name servers with a common key:

key terminator-wormhole.movie.edu. {
	algorithm hmac-md5;
	secret "skrKc4Twy/cIgIykQu7JZA==";

The argument to the key statement in this example, terminator-wormhole.movie.edu., is actually the name of the key, though it looks like a domain name. (It's encoded in the DNS message in the same format as a domain name.) The TSIG RFC suggests you name the key after the two hosts that use it. The RFC also suggests that you use different keys for each pair of hosts.

It's important that the name of the key--not just the binary data the key points to--be identical on both ends of the transaction. If it's not, the recipient tries to verify the TSIG record and finds it doesn't know the key that the TSIG record says was used to compute the hash value. That causes errors like the following:

Nov 21 19:43:00 wormhole named-xfer[30326]: SOA TSIG
verification from server [], zone movie.edu: message
had BADKEY set (17)

The algorithm, for now, is always hmac-md5. The secret is the base 64 encoding of the binary key. You can create a base 64-encoded key using the dnssec-keygen program included in BIND 9 or the dnskeygen program included in BIND 8. Here's how you'd create a key using dnssec-keygen, the easier of the two to use:

# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST terminator-wormhole.movie.edu.

The -a option takes as an argument the name of the algorithm the key will be used with. (That's necessary because dnssec-keygen can generate other kinds of keys, as we'll see in the DNSSEC section.) -b takes the length of the key as its argument; the RFC recommends using keys 128 bits long. -n takes as an argument HOST, the type of key to generate. (DNSSEC uses ZONE keys.) The final argument is the name of the key.

dnssec-keygen and dnskeygen both create files in their working directories that contain the keys generated. dnssec-keygen prints the base name of the files to its standard output. In this case, dnssec-keygen created the files Kterminator-wormhole.movie.edu.+157+28446.key and Kterminator-wormhole.movie.edu.+157+28446.private. You can extract the key from either file. The funny numbers (157 and 28446), in case you're wondering, are the key's DNSSEC algorithm number (157 is HMAC-MD5) and the key's fingerprint (28446), a hash value computed over the key to identify it. The fingerprint isn't particularly useful in TSIG, but DNSSEC supports multiple keys per zone, so identifying which key you mean by its fingerprint is important.

Kterminator-wormhole.movie.edu.+157+28446.key contains:

terminator-wormhole.movie.edu. IN KEY 512 3 157 skrKc4Twy/cIgIykQu7JZA==

and Kterminator-wormhole.movie.edu.+157+28446.private contains:

Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: skrKc4Twy/cIgIykQu7JZA==

You can also choose your own key and encode it in base 64 using mmencode :

% mmencode

Since the actual binary key is, as the substatement implies, a secret, we should take care in transferring it to our name servers (e.g., by using ssh) and make sure that not just anyone can read it. We can do that by making sure our named.conf file isn't world-readable or by using the include statement to read the key statement from another file, which isn't world-readable:

include "/etc/dns.keys.conf";

There's one last problem that we see cropping up frequently with TSIG: time synchronization. The timestamp in the TSIG record is useful for preventing replay attacks, but it tripped us up initially because the clocks on our name servers weren't synchronized. That produced error messages like the following:

Nov 21 19:56:36 wormhole named-xfer[30420]: SOA TSIG
verification from server [], zone movie.edu:

We quickly remedied the problem using NTP, the network time protocol.2

Using TSIG

Now that we've gone to the trouble of configuring our name servers with TSIG keys, we should probably configure them to use those keys for something. In BIND 8.2 and later name servers, we can secure queries, responses, zone transfers, and dynamic updates with TSIG.

The key to configuring this is the server statement's keys substatement, which tells a name server to sign queries and zone transfer requests sent to a particular remote name server. This server substatement, for example, tells the local name server, wormhole.movie.edu, to sign all such requests sent to (terminator.movie.edu) with the key terminator-wormhole.movie.edu:

server {
	keys { terminator-wormhole.movie.edu.; };

Now, on terminator.movie.edu, we can restrict zone transfers to those signed with the terminator-wormhole.movie.edu key:

zone "movie.edu" {
	type master;
	file "db.movie.edu";
	allow-transfer { key terminator-wormhole.movie.edu.; };

terminator.movie.edu also signs the zone transfer, which allows wormhole.movie.edu to verify it.

You can also restrict dynamic updates with TSIG by using the allow-update and update-policy substatements, as we showed you in the last chapter.

The nsupdate programs shipped with BIND 8.2 and later support sending TSIG-signed dynamic updates. If you have the key files created by dnssec-keygen lying around, you can specify either of those as an argument to nsupdate's -k option. Here's how you'd do that with BIND 9's version of nsupdate :

% nsupdate -k Kterminator-wormhole.movie.edu.+157+28446.key


% nsupdate -k Kterminator-wormhole.movie.edu.+157+28446.private

With the BIND 8.2 or later nsupdate, the syntax is a little different: -k takes a directory and a key name as an argument, separated by a colon:

% nsupdate -k /var/named:terminator-wormhole.movie.edu.

If you don't have the files around (maybe you're running nsupdate from another host), you can still specify the key name and the secret on the command line with the BIND 9 nsupdate :

% nsupdate -y terminator-wormhole.movie.edu.:skrKc4Twy/cIgIykQu7JZA==

The name of the key is the first argument to the -y option, followed by a colon and the base 64-encoded secret. You don't need to quote the secret since base 64 values can't contain shell metacharacters, but you can if you like.

Michael Fuhr's Net::DNS Perl module also lets you send TSIG-signed dynamic updates and zone transfer requests. For more information on Net::DNS, see Chapter 15, Programming with the Resolver and Name Server Library Routines.

Now that we've got a handy mechanism for securing DNS transactions, let's talk about securing our whole name server.

Securing Your Name Server

BIND 4.9 introduced several important security features that help you protect your name server. BIND 8 and 9 continued the tradition by adding several more. These features are particularly important if your name server is running on the Internet, but they're also useful on purely internal name servers.

We'll start by discussing measures you should take on all name servers for which security is important. Then we'll describe a model in which your name servers are split into two communities, one for serving only resolvers and one for answering other name servers' queries.

BIND Version

One of the most important ways you can enhance the security of your name server is to run a recent version of BIND. All versions of BIND before 8.2.3 are susceptible to at least a few known attacks. Check the ISC's list of vulnerabilities in various BIND versions at http://www.isc.org/products/BIND/bind-security.html for updates.

But don't stop there: new attacks are being thought up all the time, so you'll have to do your best to keep abreast of BIND's vulnerabilities and the latest "safe" version of BIND. One good way to do that is to read the comp.protocols.dns.bind newsgroup regularly.

There's another aspect of BIND's version relevant to security: if a hacker can easily find out which version of BIND you're running, he may be able to tailor his attacks to that version of BIND. And, wouldn't you know it, since about BIND 4.9, BIND name servers have replied to a certain query with their version. If you look up TXT records in the CHAOSNET class attached to the domain name version.bind, BIND graciously returns something like this:

% dig txt chaos version.bind.
; <<>> DiG 9.1.0 <<>> txt chaos version.bind.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34772
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;version.bind.                  CH      TXT
version.bind.           0       CH      TXT     "9.1.0"

To address this, BIND Versions 8.2 and later let you tailor your name server's response to the version.bind query:

options {
	version "None of your business";

Of course, receiving a response like "None of your business" will tip off the alert hacker to the fact that you're likely running BIND 8.2 or better, but that still leaves a number of possibilities.

Restricting Queries

Before BIND 4.9, administrators had no way to control who could look up names on their name servers. That makes a certain amount of sense; the original idea behind DNS was to make information easily available all over the Internet.

The neighborhood is not such a friendly place anymore, though. In particular, people who run Internet firewalls may have a legitimate need to hide certain parts of their namespace from most of the world while making it available to a limited audience.

The BIND 8 and 9 allow-query substatement lets you apply an IP address-based access control list to queries. The access control list can apply to queries for data in a particular zone or to any queries received by the name server. In particular, the access control list specifies which IP addresses are allowed to send queries to the server.

Restricting all queries

The global form of the allow-query substatement looks like this:

options {
      allow-query { address_match_list; };

So to restrict our name server to answering queries from the three main Movie U. networks, we'd use:

options {
      allow-query { 192.249.249/24; 192.253.253/24; 192.253.254/24; };

Restricting queries in a particular zone

BIND 8 and 9 also allow you to apply an access control list to a particular zone. In this case, just use allow-query as a substatement to the zone statement for the zone you want to protect:

acl "HP-NET" { 15/8; };
zone "hp.com" {
      type slave;
      file "bak.hp.com";
      masters {; };
      allow-query { "HP-NET"; };

Any kind of authoritative name server, master or slave, can apply an access control list to the zone. Zone-specific access control lists take precedence over a global ACL for queries in that zone. The zone-specific access control list may even be more permissive than the global ACL. If there's no zone-specific access control list defined, any global ACL will apply.

In BIND 4.9, this functionality is provided by the secure_zone record. Not only does it limit queries for individual resource records, it limits zone transfers, too. (In BIND 8 and 9, restricting zone transfers is done separately.) However, BIND 4.9 name servers have no mechanism for restricting who can send your server queries for data in zones your server is not authoritative for; the secure_zone mechanism works only with authoritative zones.

To use secure_zone, include one or more special TXT records in your zone data on the primary master name server. Conveniently, these records are transferred to the zone's slave servers automatically. Of course, only BIND 4.9 slaves will understand them.

The TXT records are special because they're attached to the pseudo-domain name secure_zone, and the resource record-specific data has a special format, too...

Read More

Customer Reviews

Average Review:

Write a Review

and post it to your social network


Most Helpful Customer Reviews

See all customer reviews >