DNS and BIND [Paperback]

DNS and BIND is an explanation of the glorious Domain Name System (DNS). DNS takes familiar Internet network and machine names (such as "Amazon.co.uk") and converts them to Internet Protocol (IP) addresses (such as "208.35.218.15") that are meaningful to routers and so useful for identifying the machine you want to reach. What's amazing is, DNS enables someone in Germany to refer, by name, to a computer in Mongolia even if no one in Germany has ever accessed the distant machine before. It's pretty much self-configuring too: no human effort in Germany is necessary to make the Mongolian machine reachable by name. DNS and BIND explains how DNS works better than any other piece of documentation, printed or otherwise. The work of Paul Albitz and Cricket Liu, now in its fourth revision, has long been considered a classic among systems administrators and network architects, particularly those with a UNIX bent.

The fourth edition is mainly an update: The authors have added coverage of incremental and conditional zone transfer with BIND's new NOTIFY features, as well as of Transaction Signatures (TSIG) and DNS Security Extensions (DNSSEC). Sections on firewalling and DNS for IPv6 addresses have been expanded, and Albitz and Liu maintain their impeccable style that combines text and illustrative listings into an educational whole throughout. --David Wall

Topics covered: The Domain Name System (DNS) and how it's implemented by BIND (through versions 8.2.3 and 9.1.0), how to set up BIND, how to configure MX records for mail service, parent and child domains, NOTIFY, and DNS security. --This text refers to an out of print or unavailable edition of this title.

This is the definitive book on the Domain Name System (DNS), the powerful scheme that facilitates the translation of English-like domain names (www.amazon.com) into computer-comprehensible Internet Protocol (IP) addresses (208.216.182.15). If you run a DNS server of any kind, particularly under Unix, you need to have this book on hand.

This book's early chapters give a view of DNS from high altitude, explaining basic concepts such as domains, name servers and name resolution. From there, the authors proceed on a more practical tack, presenting specific instructions for setting up your own domain and DNS server using BIND. The authors then tell you what to do as your domain grows and you need to add more machines, subdomains, and greater throughput capacity. They also talk a lot about nslookup and C programming with the various DNS and BIND libraries. Administrators will find the chapter on BIND debugging output particularly helpful. Here, the authors translate BIND's mysterious error messages and offer specific strategies for fixing and optimising the program. This edition covers BIND 8.1.2, but pays lots of attention to older versions that are still in wide use (4.8.3 and 4.9). The authors are careful to note differences among the versions. --David Wall, Amazon.com

'Now into its fourth edition, updated to cover BIND 9, the O'Reilly textbook has already attained classic status. DNS and BIND can be found on the shelf, or more likely open on the desk, of most clued-up system administrators... Don't expect a fun read ... the subject matter is a little dry for that ... but if you like your Unix and want to truly understand how DNS works in general and in practice within your enterprise, this is the book to buy.' - Davey Winder, PC PRO, September 'This book has been the bible for DNS administration since 1992. .. I can't fault this new edition of the book. The first edition serve me well when I was setting up my first DNS server. The book still achieves what it sets out to do, and explains DNS and BIND. This has got more complicated (sorry, feature rich!) over the years, but this book still explains it in clear terms. O'Reilly rightly made their name through publishing titles like this.' - Joel Smith, new@UK, December 2001 'This book is as useful now as it was back in the mid 90's. Buy it if you have to do any more than be a simple user of DNS. As a measure of how times change, the appendices no longer show you how to compile and install BIND on a Sun operating system, it is now shown with Linux.' - Raza Rizvi, new@UK, December 2001 --This text refers to an out of print or unavailable edition of this title.

One of the Top Ten Books for 2001. --This text refers to an out of print or unavailable edition of this title.

The fourth edition of DNS and BIND covers the new 9.1.0 and 8.2.3 versions of BIND as well as 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 section on accommodating Windows 2000 clients, servers and Domain Controllers. --This text refers to an out of print or unavailable edition of this title.

Paul Albitz is a software engineer at Hewlett-Packard. Paul earned a bachelor of science degree from the University of Wisconsin, LaCrosse, and a master of science degree from Purdue University. Paul worked on BIND for the HP-UX 7.0 and 8.0 releases. During this time Paul developed the tools used to run the hp.com domain. Since then Paul has worked on networking HP's DesignJet plotter and on the fax subsystem of HP's OfficeJet multifunction peripheral. Before joining HP, Paul was a system administrator in the CS Department of Purdue University. As system administrator, Paul ran versions of BIND before BIND's initial release with 4.3 BSD. Paul and his wife Katherine live in San Diego, CA. Cricket Liu matriculated at the University of California's Berkeley campus, that great bastion of free speech, unencumbered UNIX and cheap pizza. He went to work for Hewlett-Packard after graduation and stayed at HP for nine years. Cricket began managing the hp.com zone after the Loma Prieta earthquake forcibly moved the zone's management from HP Labs to HP's Corporate Offices. He was hostmaster@hp.com for over three years, and then joined HP's Professional Services Organization to found HP's Internet consulting program. Cricket currently runs his own DNS consulting and training company, Acme Byte & Wire, with his friend Matt Larson. Cricket, his wife, Paige, and their son, Walt, live in Colorado with two Siberian Huskies, Annie and Dakota. On warm weekends, you'll probably find them on the flying trapeze.

Chapter 11 - Security

In this chapter:
TSIG
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.(The AlterNIC runs an alternate set of root name servers that delegate to additional top-level domains with names like med and porn.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.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.
TSIG
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). --This text refers to an out of print or unavailable edition of this title.