Unraveling BIND 9.3

Wednesday Apr 13th 2005 by Martin Brown
Share:

From DNSSEC to IPv6 support, we look at the main improvements in the latest release and discuss how to make the best use of these new features. We also look back on where BIND has been and ahead on where it's going.

The Domain Name System (DNS) is a component of the Internet often taken for granted. Although knowledgeable users are aware that the Internet works off of IP addresses, the reality is that we all type in names rather than impossible-to-remember long numbers. The DNS is based on an open standard, and, thus, numerous choices are available for managing DNS information. The best known method by far is the open source Berkeley Internet Name Domain, more commonly referred to as BIND.

BIND 9.3, the most recent release, has been available since September 2004. It features a number of key enhancements in terms of both security and the way it is supported. This article covers the main improvements in the release and discusses how to make the best use of these features.

Brief History of BIND

BIND has been available for years, and it has had a somewhat rambling history. What has not changed is the main aim of the software: to provide a secure and effective environment for managing domain name information. The earliest versions were developed at the University of California, Berkeley as part of a student project under a grant from the Department of Defense.

Contents

Brief History of BIND
Core Changes in 9.3
Securing your DNS with DNSSEC
Support Options
Looking Ahead to 9.4

Later, the Computer Systems Research Group and a loan employee from Digital Equipment Corporation (DEC) adopted BIND and made it a DEC project. DEC then released it. Paul Vixie, who worked for DEC at the time, adopted the project, and, eventually, through his own company, Vixie Enterprises, sponsored continued work on the project for the key release of version 4.9.2, which is still available today.

The Internet Systems Consortium (ISC) supports the most recent versions of BIND. Paul Vixie and Bob Halley remain key contributors to the latest versions. Today, most people come across BIND because it's included with their operating system, whether commercial (e.g., Solaris, Mac OS X, and Windows) or freely available (e.g., Linux and BSD).

Core Changes in 9.3

The main improvements in Bind 9.3 relate to the security of the application. The security elements are built into the software and improve on the security that the DNSSEC standard provides for securing domain information, transfers, and exchanges, as well as ensuring the information for a domain cannot be usurped or abused. The next section of this article examines DNSSEC in great detail.

Another improvement in 9.3 is the introduction of IPv6 support and, with that, transitional support for servers running both IPv4 and IPv6 that must support DNS on both network types. This is designed to make it easier for such organizations to migrate to the IPv6 platform.

The migration is further aided by support for better configuration of BIND on servers with multiple IP addresses. It's possible to perform a migration on a machine configured with multiple interfaces running on different IP standards. Administering the information has been improved through more extensive IXFR records, making it easier to delegate zones within a domain to different administrators. This is a huge help in very large domains, like big corporations and ISPs.

Other minor improvements in 9.3 include additional server identification options, which makes it easier to key the servers and help exchange information. It is also possible to extract more information about the BIND servers to get better statistics (useful for debugging and performance monitoring).

>> Securing your DNS with DNSSEC

Securing your DNS with DNSSEC

Once you understand how DNS works, it's easy to see why security is required to help control the information within a DNS database. The most fundamental issue with DNS is that its distributed nature, coupled with the way names are resolved into the IP addresses, makes it vital the information be correct.

One key reason DNS is not as secure as it should be is the use of UDP as a network transport. UDP packets do not provide information on the packet source, making it difficult to ensure that the client talking to the DNS server is really who it says it is. This can cause problems from unauthorized DNS registrations to attacks that enable entire domains to be spoofed, leading to traffic being redirected to alternative servers.

This is where DNSSEC can help. It provides secure extensions to the DNS protocol that operate through public-key infrastructure. Clients and servers that expect to supply DNS information must have the correct public key to update the domain. Changes like this normally mean completely changing the infrastructure of the protocol, obviously not an option with such a public system. DNSSEC is therefore backward-compatible with earlier DNS implementations, and the administrator chooses whether to use the functionality to help protect the DNS information.

Most DNS servers are configured to automatically list all the hosts (and their associated information, such as IP addresses) to a client when requested. This can give away potentially damaging information, such as the name of the servers to be used in an attack.

The first stage in preventing this is to use transaction signatures (TSIGs) and the allow-transfer directive to secure communication between the DNS server and other machines. A TSIG is a combination of a secret key string and a hashing algorithm — i.e., when Server A requests information from Server B, it must supply the TSIG and meet the restrictions on the allow-transfer directive for Server B to supply the domain information.

To set up a TSIG, first generate a unique key, which we do with the dnssec-keygen command. Specify the algorithm to use with the key, the size of the key (the number of bits), and the type of key you are generating. For a TSIG, a host key is required. Choosing the right algorithm and key size is dependent on the desired level and type of security. Irrespective of algorithm, the more bits, the better, as this implies a larger and more complex key to crack. For this exercise, we'll use the HMAC-MD5 key. To create a key, use the following command:

$ dnssec-keygen -a HMAC-MD5 -b 128 -n host shareit.private.dom

The key generator should automatically use the /dev/random device, if available (it's part of many Unix distributions), to generate a random string to be used as the key. If it's not available, you may be asked to type a key (which should be a random string, so go ahead and pound the keyboard with any old rubbish). Once finished, you should have two files:

Kshareit.private.dom.+157+19121.key Kshareit.private.dom.+157+19121.private 

The first file, ending with .key, is your public key. The public key contains the information to be distributed to the servers with which you want to exchange domain information. The second key, ending .private, is the private key. The numbers in the file name indicate the algorithm type and key size.

An examination of the content of the public key file at this time would reveal it contains a simple string for the hashing key:

shareit.private.dom. IN KEY 128 3 157 dlV1EKwOtxquWRX15IdNrg==

That sequence of random characters is the secret key, which will be needed in a moment.

Next, configure the two hosts, starting with the primary server. The named.conf file should look something like this:

key shareit.private.dom.{
        algorithm hmac-md5;
        
        secret "dlV1EKwOtxquWRX15IdNrg==";
        };
server 192.168.1.2 {
keys { shareit.private.dom; };
        }
        
zone "private.dom" {
type master;
file db.private.dom;
        
allow-transfer { key shareit.private.dom. ; };
    };

The very first part sets up the public key for the domain, and including it here in named.conf isn't a very secure idea. We'll look at ways to remedy this shortly.

Next, we specify the domain, set it up as a master domain, and then use the allow-transfer directive to tell the server to allow transfers only to servers that supply the correct key.

Thus, named.conf in the secondary server would look something like this:

key shareit.private.dom.{
            algorithm hmac-md5;
            
            secret "dlV1EKwOtxquWRX15IdNrg==";
            };
server 192.168.1.1 {
            keys { shareit.private.dom; };
            }
            
zone "private.dom" {
type slave;
master { 192.168.1.1 };
            file private.dom.cache;
             allow-transfer { none; };
};

The problem with the above configuration is that many people can read named.conf, as we're giving away the supposedly secret key right in the file. The solution is to put the domain keys, such as this one, into a separate file; secure that file by making it readable only by root; and then replace the key definition in named.conf to include the keyfile, by removing the inline key definition and adding the following line:

include /etc/bind/shared.keys

From now on, servers requesting the exchange of the entire domain private.dom from the primary DNS host will get the domain only if they supply the right public key. This is an explicit request to restrict access, meaning most users will have backward compatibility with the old unsecure method but can also secure their domains if they wish.

This is a very simple way of securing the overall domain exchange. BIND 9.3 can also sign an entire domain with a security key, making it easy to verify whether domain records have been changed. In addition, the public key security provided by the DNSSEC extensions can be used to create an entire infrastructure for signing domain information.

>> Support Options, Looking Ahead

Support Options

As a long-time open source project, BIND is community-backed via various Web sites, mailing lists, and newsgroups devoted to, and supporting, BIND software. BIND is supported through the BSD License, which allows anyone to use or redistribute the software, with or without fee, in source or binary form, and under any license desired.

For commercial distributions, like Solaris, the vendor (in the case of Solaris, Sun) provides the necessary support for the product as if it sells and distributes BIND as part of the operating system. Organizations that distribute BIND with other free or open source offerings, such as Linux, there is no such support available directly. However, SUSE and Red Hat do offer support with their enterprise products.

Many enterprises use BIND software in a commercial context, either in a free operating system like a Linux distro or BSD flavor, or through the versions of BIND installed in place of many commercial solutions on a range of different operating systems. Starting with 9.3, ISC will offer annual support contracts to these companies and organizations. The support ranges from simple e-mail to always-available phone support.

Depending on the contract selected, ISC can also help set up an infrastructure, hopefully preventing potential problems that occur in the future. The different options also incorporate both standard and emergency response systems and direct access to expert contacts. The price for this, admittedly, can be high. Standard support starts at $5,000, but for an ISP or one of the companies managing one of the root servers, the costs are minimal compared to the potential money lost in the event of a DNS failure.

Looking Ahead to 9.4

The key focus for BIND 9.4 will be the documentation. ISC already stated it expects to completely rewrite the manuals to make the BIND software easier to use and understand, a frequent complaint of many administrators.

Another complaint is the lack of an administrative interface for BIND. All configuration is still handled by text files that must be edited with a simple text editor. Future versions of BIND are not expected to provide a complete solution, but they will provide some middleware to make it easier for third-party developers to manage the BIND configuration.

ISC also sees the security aspects of BIND becoming an important part of the migration of DNS to be more than just a way to resolve IP addresses. Already, aspects of the additional information stored in the DNS can be useful; for example, HOST records can store information about the operating system and platform.

The DNS system already acts as a method for storing unique identifiers for hosts. It could be further expanded to hold more detailed information and even act as an asset register. This would make it easy to, for example, track and trace information about individual hosts. Another idea is to use the DNS datastore as a method for exchanging security information, such as encryption keys for remote login or wireless access (WEP or WPA). Of course, this relies on better security of the DNS database, especially when exchanging information with other hosts; giving away this data to unauthorized clients would be disastrous. Once the security issue is overcome (using DNSSEC), DNS will become a simple, and obvious, way to disseminate this information.

Other groups and individuals are already using it as a way of storing discrete information in a distributed format.

Share:
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved