Upgrading BIND
David Conrad Can you dynamically update your DNS zone files? Do you have a need to create an internal view of the DNS and a more limited view for people external to your organization? Do you want to use thread-safe DNS resolver library functions? Do you want to experiment with the recently standardized DNS security enhancements? More importantly, does your boss want any of these? If any of the answers to these questions were “yes”, you'll probably want to upgrade to the latest version of BIND, version 8.2.2. This article provides a cookbook describing how you can upgrade your domain name server to the most current version available from the Internet Software Consortium, BIND version 8.2.2. BIND 8.2.2 provides a wealth of new features and enhancements and can significantly increase the security of your DNS service. With the tools provided in BIND version 8 and following the steps described here, the conversion can be done in less than half an hour with minimal interruption of your DNS services. Why Upgrade? If you are currently using a version of BIND prior to BIND 4.9.7 or are running BIND version 8.1.1 or 8.2.1, we strongly recommend you upgrade as there are numerous security and correctness issues that can result in unpleasantness of many flavors, up to and including well-known remote root access exploits. If you are currently using BIND version 4.9.7, we recommend upgrading, because BIND version 4 is officially deprecated by the Internet Software Consortium, and 4.9.7 does have DNS protocol conformance issues that may result in less than desired behavior. We have no plans to make any future feature releases of BIND version 4 to correct these issues, albeit we will make releases to address any significant security concerns should they arise. On the positive side, the following major features were included with the release of BIND version 8.2.2:
• Bug fixes and performance enhancements too numerous to mention • RFC 2308 (negative caching) support • Preliminary DNSSEC support • Transaction signature (TSIG) support • Enhanced IXFR, Notify, and Dynamic update support • Greatly enhanced “ndc” BIND management program • Support for multiple virtual name servers • Support for more than 16 million zones • Thread safe resolver library • “Split DNS” via a new zone type “forward”
Finally, BIND 8.2.2 is the last planned release in the version 8 series. The Internet Software Consortium is now developing BIND version 9. Version 9 will support IPv6 and full DNSSEC, have a clean separation between the protocol engine and the backend database(s) so alternative (such as disk-based or SQL) databases can be used, support multi-processor scaling, and be fully thread safe. As such, efforts toward upgrading today won't be wasted by having to upgrade between now and the release of BIND version 9, scheduled for May 2000. The 13-Step Process to Upgrading Anytime you're mucking about with a critical part of your network infrastructure, it is generally a good idea to have a cookbook for each step and a way of backing out back to your initial state should you encounter problems. In keeping with this philosophy, a 13-step cookbook approach follows. We recommend upgrading your secondary first (you do, of course, have control over the primary and at least one secondary, right?), letting it run for a while, then upgrading the primary, but such an approach is not mandatory. Step 1: Determining Whether the Exercise is Worth your While In many situations, the old saw “if it ain't broke, don't fix it” applies. If your name service meets your needs and is secure, it is most likely unnecessary to upgrade. However, if you are using an insecure version or if any of the features described previously look useful or important to you, upgrading would be the right choice. As hinted at previously, BIND versions prior to 8.2.2 have had various security and correctness issues. A brief list of those issues may help you determine whether upgrading tooa new version of BIND is a top priority or something to do in your spare time. A short list of some of the more significant issues and the versions that exhibit them are:
• In all BIND versions up to 4.9.7 and 8.1.1, it is essentially trivial to insert bogus information into a server's cache resulting in the ability to redirect any hostname to any IP address • In BIND versions 4.9.6 and 8.1.1, a stack overflow bug exists that can be used to gain root access when IQUERY support is turned on • In BIND version 8.2 and 8.2.2, there are a multitude of denial of service attacks that can deafen your domain name server to all incoming queries
Additionally, BIND has traditionally played a bit fast and loose with conformance to the RFC specifications. Until very recently, this didn't matter because BIND was essentially the only domain name server in use on the Internet. However, the increasing use of Microsoft's DNS server has pointed out areas in which BIND does not conform to the RFCs. Many of these conformance issues have been addressed in BIND 8.2.2. Assuming you want to upgrade, you should make sure you can compile BIND and that it works on your architecture. BIND has been compiled and runs on almost every known UNIX system and many non-UNIX systems, such as Windows NT (new with 8.2.2), QNX, AS/400, LynxOS, OpenVMS, and others. If BIND does not work in your environment, send mail to bind-bugs@isc.org, because we'd be interested in hearing about it. Because BIND is distributed in source form, you'll need to ensure you have various compilation utilities and other tools available to you. Specifically, you'll need:
• GNU's gunzip • An ANSI/ISO standard C compiler and library • A yacc • A lex
Additionally, you will most likely want to have PGP version 2.6.2 installed and configured to verify the archives have not been corrupted. Step 2: Downloading the Software BIND version 8 has been broken into three separate archives, the source for the server, the resolver libraries, and the ISC-supported utilities (bind-src), the documentation archive (bind-doc), and contributed software (bind-contrib). The URLs for these archives are: BIND server and resolver library:
ftp://ftp.isc.org/isc/bind/src/cur/bind-8/bind-src.tar.gzBIND documentation:
ftp://ftp.isc.org/isc/bind/src/cur/bind-8/bind-doc.tar.gz Contributed software:
ftp://ftp.isc.org/isc/bind/src/cur/bind-8/bind-contrib.tar.gz Download each of these archives using your favorite browser or an ftp client. You'll need about 50 MB of disk space for the uncompressed source files, the object files after compilation, and the documentation. You'll also want to pull down the PGP signature files, which end in “.asc”, that are associated with each archive to ensure the archives are unmodified since ISC distributed them. You are, of course, free to put the downloaded archives anywhere you like, but for the purposes of this article, I'll assume the download directory is /usr/src/local/bind. Step 3: Verifying the Software has not been Modified ISC signs our software distribution with PGP to provide some level of assurance that our archives have not been tampered with. To verify the distribution you received, you'll need ISC's PGP key on your key ring and a configured version of PGP 2.6.2. If you do not already have our key, download it from http://www.isc.org/isckey.txt and use pgp -ka to add the key to your key ring (feel free to contact us to verify the key you downloaded is the correct key). To verify the integrity of the source distribution, invoke the PGP command from the download directory:
% pgp /usr/src/local/bind/bind-src.tar.gz.asc This command will ask you for the filename of the material that the signature applies to, and you should enter /usr/src/local/bind/bind-src.tar.gz and hit return. If you get a result other than:
Good signature from user "Internet Software Consortium <pgpkey@isc.org>". Signature made [date/time] there is a problem with your distribution and you should not use it. Fetch a new version from ISC directly, and if you are still unable to get a good signature response from PGP, contact ISC as soon as possible. If the signature is correct, you can verify the signatures of bind-doc.tar.gz and bind-contrib.tar.gz using the same procedure. Step 4: Unpacking BIND The only catch with this step is that, for historical reasons, BIND unpacks into the current directory. The command:
% gunzip -c /usr/src/local/bind/bind-src.tar.gz | tar xvf - will result in the creation of a src directory, which (not surprisingly) contains the source for the BIND server and resolver libraries. If you do:
% gunzip -c /usr/src/local/bind/bind-doc.tar.gz | tar xvf - % gunzip -c /usr/src/local/bind/bind-contrib.tar.gz | tar xvf - you'll unpack the archives for documentation (doc) and contributed software (contrib) in /usr/src/local/bind as well. Step 5: Compilation The first thing to do in this step is decide whether you will be building for multiple platform/architectures. The BIND makefiles are set up so you can create alternate object directories to facilitate building multiple architectures simultaneously. To do this, you'll need to create a set of symbolic links by:
% cd /usr/src/local/bind/src % make DST=/your/destination/here SRC=`pwd` links % cd /your/destination/here where /your/destination/here varies depending on the architecture (e.g., /var/obj/i386-freebsd, /var/obj/sparc-solaris7, etc.). If you simply want to build for a single platform (or you are running Linux, which may have trouble with the way BIND sets up symbolic links) you can dispense with building the multiple architecture links and simply do:
% cd /usr/src/local/bind/src % make stdlinks By default, BIND will build in /var/obj/bind. If this is not appropriate for your environment, you can use the “make DST=... links” method described above to specify an alternative object directory for compilation. Next, it is a good idea to ensure there is nothing lying around from previous build attempts:
% make clean Then, update the makefile dependencies:
% make depend and finally:
% make When this step finishes, the BIND server, various utilities included in the base distribution, and the resolver libraries will have been created. Compilation of the BIND sources (not including contributed software) on a unloaded Pentium 133 MHz machine with 128 MB of memory running FreeBSD 3.2-Release took about 15 minutes. Your mileage may vary. Step 6: Testing Unfortunately, neither the BIND server nor the resolver libraries are particularly easy to test in a formal way. Ideally, to test the server, you would take a machine that does not run a name server and install and run your new version of BIND on it. You could then use dig, nslookup, or host to send a variety of queries to both the new server and your regular name server and compare the results. If there are any differences, you can investigate them to determine whether they will negatively affect your environment. However, if you do not have a spare machine lying around, the next best option would be to start up your new version of BIND on a different port. BIND version 8.2.2 supports the ability to listen on an arbitrary port for DNS queries, so you can run your old name server on the regular DNS port (port 53) and your new server on an arbitrary port (say 5353) simultaneously. To do this, you'll need a minimal configuration file, a root “hints” file, and a zone file or two to do the queries on. Because BIND ships with a root zone hints file and zone data files for localhost and its reverse in src/conf/recursive, we'll use those to create a minimal configuration file:
options {
directory "/usr/src/local/bind/src/conf/recursive";
listen-on port 5353 { // use port 5353 to not
Copying the configuration information above into a file (e.g., /tmp/named.conf.test) will allow you (as root) to start up your new name server via:
# /usr/src/local/bind/src/bin/named/named/tmp/named.conf.test If the program does not immediately fail, you should look in the file syslog is configured to write messages (e.g., “/var/log/messages”). You should see something along the lines of:
starting. named 8.2.2 [date/time] [who compiled it/from where] Ready to answer queries. If you do not see messages between the “starting.” and “Ready” lines that indicate some sort of problem, then your new BIND 8 name server should be able to answer queries authoritatively for “localhost” and “1.0.0.127.in-addr.arpa” on port 5353. You can now use “ndc” to check the status of your name server, restart it, stop it, or reconfigure as you see fit. After you've convinced yourself that your new name server is working correctly, /usr/src/local/bind/src/ndc/ndc stop it in preparation for installing it. Step 7: Preparing the Configuration File If you are upgrading from BIND version 4, the major issue you will face will be converting your named.boot configuration file into the newer named.conf format. As you may have guessed from the minimal configuration file described above, the BIND version 8 configuration language is radically different from what you might be used to for BIND version 4. To aid in the conversion, BIND version 8 ships with a translator shell script, named-bootconf. Because named-bootconf is a filter, its usage is straightforward (and safe):
# src/named-bootconf/named-bootconf \ < /etc/named.boot > /etc/named.conf While named-bootconf is pretty good at translating configuration files correctly, it can have problems with comments, so you'll probably want to look at the output to make sure everything looks okay. If you are upgrading from an earlier version of BIND version 8, you most likely will not need to do anything because BIND 8.2.2 configuration files are backward compatible with earlier versions of BIND 8. If you are upgrading to BIND version 8 from a non-BIND name server, you can simply expand on the minimal configuration file provided above. Specifically, you'll need to create “zone” statements for each zone you will be master or slave for, and you'll want to remove the “listen-on” statement from the “options” section. We have supplied some sample configuration files in the bind-src distribution in src/conf/recursive and src/conf/workstation which may be of help in expanding your configuration file. Step 8: Modifying your Zone Files As the zone file format is specified in the DNS RFCs, you should not need to significantly modify your zone files. However, BIND version 8 is a bit more picky about conforming to those RFCs than BIND version 4, so if you are upgrading from version 4 and are using “questionable features” (read: bugs) of BIND version 4, you may get syntax errors when the zone file is loaded. Regardless of what version you are upgrading from, one minor change you may want to make in your zone files is to insert a $TTL directive to specify a default time to live. Previous versions of BIND used the “MinTTL” field of the SOA resource record for this. However, starting in BIND 8.2, MinTTL was redefined to mean the negative cache time to live in keeping with the new negative caching DNS extension described in RFC 2308. The message generated is just a warning, however, so it is safe to ignore. If you will be modifying your zone files, make sure to save a copy of your current zones in the event you need to back out of the upgrade. Step 9: Testing the Name Server on Live Data This step is similar to the testing done in Step 6 described above, except that instead of using a minimal configuration file, you'll be using the configuration and zone files you expect to use in production. To ensure that you don't conflict with your existing name server, run it on a different machine or port. If you don't have a spare machine lying around, make sure the line:
listen-on port 5353 { *; };
exists in the “options” section of the configuration file, adding it if necessary. To start BIND, execute the named command:
# /usr/src/local/bind/src/bin/named/named Check your “messages” file to make sure you have no errors in your configuration file. In particular, check for the word “rejected”, because BIND version 8 attempts to load your zone files. As mentioned previously, BIND version 8 is a bit more picky about syntax errors in zone files, so some of the things that have slid by in earlier versions may be noticed and rejected. If everything looks okay, use dig, nslookup, or host to check the validity and consistency of your zone(s). After you have convinced yourself your new BIND 8 name server is doing the right thing, kill it with ndc stop and remove or modify the “listen-on” statement to get rid of the alternate port (5353) as appropriate. The next time you start up named, it will be for real. Step 10: Save your Old BIND Installation Unfortunately, the installation process defined in the makefiles will happily overwrite your existing binaries and manual pages without saving a copy. To be safe, save them before installing the new ones. If you are upgrading from BIND version 4, save the binaries and manual pages for addr, nslookup, dig, dnsquery, host, named, named-xfer, and ndc. If upgrading from earlier versions of BIND version 8, save the same binaries and manual pages as in BIND version 4 as well as nsupdate, mkservdb, named-bootconf, and (for upgrading from 8.2 or later), irpd, and dnskeygen. Additionally, you'll want to archive resolver-related manual pages and the configuration file format manual pages (specifically, gethostbyname(3), inet_cidr(3), resolver(3), hesiod(3), getnetent(3), tsig(3), getaddrinfo(3), resolver(5), irs.conf(5), named.conf(5), hostname(7), mailaddr(7)). With respect to libraries and include files, if you are upgrading from BIND 4, you do not need to do anything special. BIND version 8 does not muck about with the system include files and libraries as BIND version 4 did, so the installation process won't touch your existing BIND version 4 header files and libraries. If you are upgrading from an earlier version of BIND version 8, however, you'll most likely want to save the header files and libraries. The easiest way to do this is to simply rename the appropriate directories where those files are located. Step 11: Install BIND Version 8.2.2 At this point, you can finally install BIND version 8.2.2. BIND is fairly clever about where to put binaries, figuring out the appropriate path based on the operating system and architecture you are building it on. (Although this feature can be overridden, that is something you probably don't want to do without good reason.) To install BIND 8.2.2, simply (as root)
# cd /usr/src/local/bind/src # make install # cd ../doc/man # make install Because BIND 8 does not build shared libraries and the installation of BIND 8 doesn't touch system libraries like libc.a, programs that wish to use the resolver will not automatically make use of the new BIND 8 resolver. By and large, this should not matter. However if for some reasons you want those applications to use the new resolver libraries, you will need to include them explicitly in both compile time (you must include -I/usr/local/bind/include) and link time (you must include -lbind). Finally, if you are upgrading from BIND version 4, you may want to ensure that the boot scripts your operating system uses test for the existence of /etc/named.conf instead of /etc/named.boot. Step 12: Restart named Now you're ready for the moment of truth. At this point, you'll need to kill off the old named and start up the new one. Using the old version of ndc (saved in Step 10), issue the stop command:
# ndc.old stop or simply find the pid of named using ps and kill it with kill -9. When the old named is no longer running, start up the your BIND 8.2.2 named using the new ndc command:
# ndc start If everything goes according to plan (i.e., named didn't segfault on you or cause your machine to explode), your new BIND 8.2.2 name server should be providing DNS services to all and sundry. Note that if things haven't gone according to plan and you need to back out, you will have to restore your zone files such that they do not include the $TTL directive or earlier versions of BIND will reject those zones. Step 13: Cleaning Up How much you clean up is a matter of taste. You'll probably want to remove the object directory (or directories) you created in Step 5. You can do this by simply issuing the rm command on the directory. If you wish to leave the source around for reference, the following:
# cd /usr/src/local/bind/src # make clean will remove all the temporary files and symbolic links produced during the compilation phase. If disk space is tight, you may want to keep merely the compressed archives around. If disk space is really tight, you can always fetch the archives (including previous versions) from ISC, so it would be safe to delete those as well. If you like to live dangerously, the saved binaries and manual pages of the previous version may be superfluous and thus removable, but you'll probably want to keep them around for a bit in case you run into problems. Conclusions Upgrading to BIND version 8.2.2 is a relatively simple exercise that will make available a wide variety of new features and functionality that have been implemented as a result of the continuing evolution of the DNS protocol suite. The 13-step procedure outlined here should provide systems administrators with a way to plan and implement the upgrade. As the DNS is a critical part of any organization's Internet infrastructure, much care should be taken to ensure there is no loss of service while upgrading. However, upgrading to BIND version 8 is a relatively painless task and with proper precautions, no difficulties should arise.
About the AuthorDavid Conrad is the Executive Director of the non-profit Internet Software Consortium that is chartered to support the development of Open Source implementations of core Internet Protocols. In his copious spare time, he is also the President/CEO of Internet Engines, Inc., a Silicon Valley startup that provides commercial support for ISC software. He is looking forward to sleeping sometime early in his next life. |