5.2. DNS Software

 < Day Day Up > 

BIND and djbdns are not the only two software packages that perform DNS services. In the context of FreeBSD and OpenBSD, however, they are the only realistic choices for production-quality, stable DNS services. They are independently developed systems that operate very differently, but ultimately achieve the same goal.

5.2.1. BIND 9

The first versions of BIND were originally written at the University of California at Berkeley many years ago. The Internet Software Consortium (http://www.isc.org/) maintains it now. In recent years, the ISC set aside the entire Version 8 code base and rewrote the software from scratch. The Version 9 rewrite is cleaner, more consistent, and is the reference implementation for the official DNS standards published by the IETF. Some early adopters of BIND 9 were left with an unpleasant taste in their mouths because the early versions were lacking many key features that were commonly used in BIND 8. You may find mailing list messages and web pages disparaging BIND 9 for various reasons. Be sure to consider the age of the documents before believing them completely. Features are now complete that were gradually phased in, and many issues have been corrected.

BIND is all things DNS rolled into one large, complex program. Everything mentioned in every official DNS standard is implemented completely or incompletely somewhere in BIND. It acts as master, slave, server, and client all at various times. Depending on what you want your nameserver to do, this can be a convenience, or a needless amalgamation of features.

BIND implements a number of security standards including TSIG and DNSSEC. It adds a remote management API with rndc. It also adds a few automation features such as dynamic DNS, NOTIFY messages, and incremental zone transfers. Several of these features will factor into our discussion of secure DNS operations.

5.2.2. djbdns

Daniel J. Bernstein wrote djbdns in reaction to BIND's overwhelming complexity, size, and history of problems. BIND's complexity can be daunting and error-prone and its security track record is spotty. Additionally, BIND uses a lot of memory in normal operations. The extant versions of BIND when Bernstein was first writing djbdns had a variety of well-known and significant vulnerabilities. Even since djbdns was written, significant vulnerabilities have been discovered in BIND including in BIND 9.

Instead of being a monolithic super-server, djbdns is actually a series of small, specialized programs in the best Unix tradition. Each program handles a very specific set of responsibilities according to a small, well-defined set of rules. Furthermore, each program can be used as a logical unit for encapsulation. Each one can be chrooted or jailed. Each can run as a different user or run on a different server.

Security is the first and foremost priority of djbdns. The code's simplicity, separation of duties, and small size are intentional efforts to keep the system focused and secure. Bernstein even offers a $500 bounty to the first person who identifies a verifiable security flaw in djbdns. This is an interesting gesture; however, being the first to document a hole in djbdns after so many years of operation is probably far more compelling than $500 in 2005. The fact remains that there are no documented djbdns-specific flaws. There has never been a bug so egregious as a root-level compromise through a buffer overflow.

Documentation and usability are low on the priority list for djbdns. The documentation is spotty and very task oriented. That is, if you want to know how to do a specific task, there will be one suggestion on a web page somewhere that merely lists the command to run. The meaning behind the command and the internal workings are left undescribed. There are practically no comments in the source code, either.

5.2.3. Typical Architecture

In order to discuss DNS we need to establish a vocabulary of the systems and services that are involved. Figure 5-1 shows a typical DNS installation for a small to mid-sized organization.

Figure 5-1. An example DNS configuration


  • The caching DNS server (E) in the DMZ performs recursive queries, but only for queries that originate from the internal network.

  • Inside the organization, all workstations (A) are set to query a single internal DNS server or set of servers (B). Those servers are the only hosts whose DNS queries are allowed to leave the internal network. They forward all queries to the caching DNS server (E) to have them serviced.

  • There is an authoritative internal server (C) that is authoritative for internal host names and IP addresses. Depending on the software configuration, it might be the same system as (B).

  • The internal DHCP server (D) might send updates to the authoritative internal server (C) every time a new lease is given out. For simplicity's sake, this DHCP server sometimes runs on the same system as C, though it does not have to.

  • In the DMZ there is an authoritative server (F) that serves domain information for the organization. Typically, for robustness, there is some other server (G) at a different geographical location that acts as a slave to F and answers authoritatively for your zones. These servers are the means by which the rest of the world queries your zone information. Some organizations configure BIND so that E and F are the same server.

In an organization running djbdns, (B) and (C) must be different IP addresses. They might be two different jails on the same system, two different chroot environments, or two whole physically different machines. Likewise (E) and (F) must be on separate IP addresses. Regardless of how many physical systems there are, there are four distinct configurations to manage.

5.2.4. BIND Versus djbdns

There are many comparisons of the two programs on the Internet and in print. Be forewarned, however, that the opinions on both sides are strong and forcefully presented. We try to present only comparisons that are relevant in a security context, and we try to present them in an impartial way. Table 5-1 compares important functionality and how it is accomplished in djbdns and BIND.

Table 5-1. Functionality in BIND and djbdns
 

BIND

djbdns

Authoritative server for zones

Built-in to named

tinydns

Caching nameserver

Built-in to named

dnscache

Zone transfers

Built-in to named

Manually configured rsync and ssh scripts

Remote management

rndc

Not possible

Dynamic update

nsupdate

Not possible

 

BIND

djbdns

Adding new data to zones

Manually edit zone files or nsupdate

add-* scripts or manually edit data file

Sanity checking of zone data

named-checkzone

add-* scripts

Memory usage

Usually high

limited ability to tune it

Usually low

easily tuned

Cryptographically signed records

TSIG built-in to named

Not possible

Integration with Microsoft Windows

Dynamic updates

Not possible


5.2.4.1 One process or many?

No matter what role your nameserver will play, BIND will always use the same configuration file. You will have to add configuration directives to enable or disable certain functionality to suit your particular application. BIND will always cache and it will always try to load zone information into RAM. This can cause resource constraints, especially if you are using a small system. On the other hand, hardware is cheap and FreeBSD and OpenBSD are also free. A few hundred dollars can obviate any RAM issues.

Compare this monolithic BIND process with the one or two processes that you run with djbdns. The simpler your needs, the fewer processes you will run, and the smaller they will be. If you need a complex system, however, you will find that you need multiple IP addresses and/or multiple systems to accomplish all the different tasks. If you plan to run all your DNS services (zone transfers, authoritative query responder, caching server) on a single system, djbdns will add some non-DNS complexity to your server. To help offset the additional complexity, Bernstein provides a set of tools, separate from djbdns, that manage the chroot requirements automatically.

5.2.4.2 Zone maintenance

With djbdns, you get a set of utility programs that do basic maintenance for you. They even check for some common errors. There are some uncommon configurations that are not easily supported by these scripts. There are also a few record types (e.g., DNAME) that djbdns does not support at all, even though they are defined in RFCs. Most sites either do not use these records, or can probably live without them.

In BIND, the zones are updated by hand by editing text files. In the past, the file format was not very robust and BIND was not helpful in diagnosing accidental mistakes. It was very easy, for example, to accidentally set your MX record to be mail.example.com.example.com by leaving out an important period on the MX line. Such errors are still easy to make in BIND zone files, but BIND 9 made the syntax far more strict and regular than BIND 8. This allows it to flag more errors than BIND 8 did. It also includes tools to check configuration files (named-checkconf) and to check zone files (named-checkzone).

5.2.4.3 Dynamic updates

BIND offers dynamic updates, a feature that djbdns does not implement. They allow you to send DNS records over the network that modify a zone as it runs. These updates are received by the named process and cause it to add, delete, or modify records. Once the update is processed, BIND updates the serial number automatically.

One common and very useful application of dynamic updates is the integration between the ISC's DHCP server and BIND. When the DHCP software issues a lease for an IP address, it can update the forward and reverse DNS maps in BIND automatically using dynamic DNS. When a lease is granted, the DNS zones get the new forward and reverse records. If a lease expires and is not renewed, the zones are updated with deletions of the corresponding records.

There is a dark side to dynamic updates. As Yoda said in The Empire Strikes Back: "Once you start down that path, forever will it dominate your destiny." To use dynamic updates, you essentially relinquish all manual control over the zone files. BIND takes over. You will no longer be able, for instance, to follow the convention of using the date for the zone serial number (e.g., 2004081600 for the first update on August 16, 2004). Each new update will increment the serial number by one. You cannot edit the zone file manually anymore. The next time BIND makes an automatic change, it will clobber any manual changes you might have made and it will completely rewrite the zone file. Lastly, BIND keeps a journal file for every dynamically updated zone. These journal files are binary and essentially unreadable. They record the changes from one serial number to the next, so that BIND can send the proper differences from any prior serial number to the current data. These files can be problematic, especially in active zones like those that are regularly updated by a DHCP server. The journal files grow without bound and are never truncated by normal BIND operations. To truncate them safely, you must stop the server gracefully, remove the journal files (not the zone files!), and restart the server.

If you want to integrate with a Microsoft Windows Active Directory environment, you can, using dynamic updates in the way that BIND implements them. It is possible to service all your DNS through BIND, even the dynamic updates that recent versions of Windows want to issue. Even though Windows Advanced Server 2003 and similar server products offer DNS services, there is no need to run multiple DNS servers on different platforms and architectures.

5.2.4.4 Incremental zone transfers and notify

When a zone has been changed, either manually or through a dynamic update, BIND can send NOTIFY messages to all the necessary name servers for that zone. If the other servers are also BIND servers, they can respond by sending zone transfer requests. This allows servers to receive updates as soon as they happen, without waiting for a TTL to expire and without any manual intervention by the administrator (other than making the change to the zone).

Incremental zone transfer (IXFR) requests, as opposed to zone transfer (AXFR) requests, are also unique to BIND. They allow a slave server to send the serial number of the zone information it currently has so that the master server will send only the changes to the zone that have happened since that serial number. If the difference is too large to fit in a single UDP datagram, the two servers negotiate a TCP connection to transfer the data.

5.2.4.5 Remote control

BIND additionally has the ability to perform various operations in response to commands received over the network. It can drop zones, reload zones, and create zones, among other things. There are definitely security implications to enabling this feature. It allows, however, for a separation of privileges whereby a junior administrator could be charged with managing routine zone data on a server where she does not normally have any sort of login access.

In order to manage djbdns, she would have to have permissions to log in on the DNS server, and run some commands as root, perhaps through a mechanism such as sudo. This is not to imply that it is impossible to arrange the same zone management structure in a djbdns system. The difference that we are pointing out is that, as with many things in djbdns, you are given some good tools, some sparse documentation, and then you are left to roll your own updating mechanism. With BIND, you get integrated support for this kind of remote maintenance whether you want it or not.

5.2.4.6 Summary

Perhaps the most relevant way to summarize the differences between BIND and djbdns is to look at how they most affect your workload as the system administrator. BIND gives you many features, whether you need them or not. In order to use many of the features safely, you must configure cryptography support in BIND and understand how to create security keys. It is relatively easy with nothing more than BIND and its accompanying tools to set up a server, enable secure, automatic updating with another server, and remotely manage it. You must remain vigilant with BIND, however, given its history of vulnerabilities. There are many more resources, books, and web sites that give documentation and hints about how to run BIND than there are giving hints about djbdns.

With djbdns, you are likely to be able to sleep more easily in terms of security. There are no known vulnerabilities. Despite the fact that it implements less DNS functionality than BIND, you will probably only use a small subset of its features. The biggest drawback is that maintenance is all manual and must be automated by you, the administrator. Documentation is scarce, too. BIND is so large that it can hardly help but to contain vulnerabilities. On the other hand, djbdns is so small that it shifts a significant amount of the security burden to you. Djbdns leaves it up to you to implement secure replication, secure remote management, and to set up all the different servers on different systems or IP addresses. There are documents and example configurations to start from, but they must be customized to fit your environment, and you have to know what to customize. There is plenty of room for you to make mistakes in these ancillary tasks; you must be careful not to create non-DNS vulnerabilities on your servers.

Proponents of djbdns argue that the dynamic updates, NOTIFY, and IXFR features are either buggy, unnecessary, or less efficient than existing alternatives. There definitely were bugs in early versions of dynamic updates. They have improved to production quality now. Many companies rely on them. The djbdns alternative to NOTIFY and IXFR is to use a program like rsync (http://rsync.samba.org/) over a secure channel established through ssh. The cryptography is certainly strong, and it handles very large files efficiently. Of course, there have been errors in both rsync and OpenSSH over the years, too. Nothing is bulletproof.

We think that hardening BIND 9 is probably the best first step if you are making the transition from experienced administrator to experienced, security-minded administrator. If you look at the documentation for djbdns and you think "I can handle that," then you will probably be more secure for choosing djbdns. Remember, however, that security is measured relative to the hostility that you face; and no increased security posture comes for free.

     < Day Day Up > 


    Mastering FreeBSD and OpenBSD Security
    Practical Guide to Software Quality Management (Artech House Computing Library)
    ISBN: 596006268
    EAN: 2147483647
    Year: 2003
    Pages: 142
    Authors: John W. Horch

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net