IBM - Linux-powered Networking, Part 1_ Build a DNS Server With ISC BIND

Linux-powered networking, Part 1 Presented by developerWorks, your source for great tutorials ibm.com/developerWorks

Table of contents If you're viewing this document online, you can click any of the topics below to link directly to that section.

1. Before you start ....................... ................................... ........................ ........................ ........................ ........................ ............2 2 2. Introduction to the domain name system (DNS) ........................ .................................. .......... 3 3. 13 steps for configuring ISC BIND ....................... ................................... ........................ .................... ........ 5 4. Summary and resources ....................... ................................... ........................ ........................ .................... ........ 15

Linux-powered networking, Part 1

Page 1 of 16

ibm.com/developerWorks

Presented by developerWorks, your source for great tutorials

Section 1. Before you start About this tutorial Running your own name server such as ISC BIND has many advantages, including redundancy and speed. Your network will also become more resilient to upstream name server outages. You are also likely to see an improvement in response time to name server queries. In addition, you have the ability to name the devices attached to your network (such as printer1.somedomain.com). This tutorial is the first in a three-part series that demonstrates how to leverage Linux# to get the most from your network. This tutorial describes how to set up DNS with Internet Systems Consortium (ISC) BIND in order to name the devices on your network. This tutorial also shows how to run the name server securely. Sample code and configuration files are provided throughout to aid understanding.

Prerequisites The network described in this tutorial is intentionally small so that you can easily duplicate the examples on a home or lab network. For this setup, I used a typical home broadband router with a built-in firewall. The Linux distribution is Fedora Core 1, but the setup described here works on other Linux distributions or UNIX® variants, such as AIX, Solaris, and HP-UX. The ISC software is free and you can get it in a number of ways. I recommend that you get a precompiled version (via RPM, for example) from your Linux vendor's FTP mirror. You can also download the source from the Internet Systems Consortium (http://www.isc.org) . This tutorial is intended for readers with moderate UNIX or Linux familiarity and an understanding of basic IP networking concepts.

About the author Keith Robertson is an Advisory Software Engineer at IBM in Research Triangle Park, NC. He is pursuing a master's degree in computer networking at North Carolina State University in Raleigh, NC. His background includes experience with networking technologies and software-development techniques. He has a working knowledge of low-level telecom networking protocols (such as SIP and MEGACO) and IP networking management protocols (such as SNMP and ICMP). He is also skilled at C/C++ and the Java programming language. You can contact Keith at [email protected] .

Page 2 of 16




Section 2. Introduction to the domain name system (DNS) What is the DNS? The domain name system (DNS) resembles a tree data structure. Each node in the tree is essentially a server that is authoritative for a particular zone (such as ibm.com). The following example shows an iterative name resolution of mail.ibm.com by linus.somedomain.com. (It does not account for advanced concepts such as caching or recursive name resolution.)

The network layout The network described in this tutorial is intentionally small and easy to duplicate on a home or lab network. As mentioned in Prerequisites on page 2, I used a typical home broadband router with a built-in firewall and the Fedora Core 1 Linux distribution. The following diagram briefly outlines the tutorial's network layout.


Page 3 of 16



Defining the zone The zone described in this tutorial is appropriate for labs or home networks. It describes a situation in which the authoritative name server for our router's external subnet does not delegate authority to our subdomain (for instance, somedomain.com). This effectively hides the hosts on our zone's subnet. Hosts on our subnet, however, should see a performance gain from having a private name server in close proximity. The following diagram illustrates our zone.

The following 13 steps will help you properly configure ISC BIND.

Page 4 of 16




Section 3. 13 steps for configuring ISC BIND In a nutshell Here are the 13 steps to configure ISC BIND: 1. Step 1. Install ISC BIND on page 5 2. Step 2. Run ISC BIND securely on page 5 3. Step 3. Set logging and other runtime options on page 7 4. Step 4. Create your configuration file (named.conf) on page 7 5. Step 5. Create the forward zone file on page 8 6. Step 6. Create the reverse zone file on page 9 7. Step 7. Create the loopback zone file on page 10 8. Step 8. Get the root hints zone file on page 10 9. Step 9. Update /etc/hosts and /etc/resolv.conf on page 11 10.Step 10. Secure the daemon on page 11 11.Step 11. Configure the firewall on page 12 12.Step 12. Start the daemons on page 13 13.Step 13. Test everything on page 13

Step 1. Install ISC BIND To install ISC BIND: 1. Check to see if your Linux distribution already has ISC BIND installed. Issue the following command at a terminal: rpm -qa | grep bind

If you do not get a response of bind-9.x.x, you should either upgrade or install anew (which is described next). 2. If you don't have ISC BIND, go to your distribution's mirror and download a binary package. In my case, I went to the Fedora mirror list (http://fedora.redhat.com/download/mirrors.html) and downloaded bind-9.2.2.P3-9.i386.rpm. Then, I issued the following command: rpm -Uvh

bind-9.2.2.P3-9.i386.rpm

.

Step 2. Run ISC BIND securely To protect the integrity of your Linux server and guard against attacks, you should run your ISC BIND daemon in a chroot jail. For Fedora (or Red Hat) Linux distributions, installing the ISC BIND RPM will create a chroot directory hierarchy under /var. Some users find the created hierarchy is incorrect. For those users (and for users on other distributions), I've listed the commands to create the proper structure in /var. Linux-powered networking, Part 1

Page 5 of 16



Also, since you will not be running as root, you must create a user to run your BIND daemon with. Verify/create a user for your BIND daemon. Your BIND daemon will be run by user named. Sometimes this user is already there, so check by issuing the following command at a terminal: grep named /etc/passwd

You should get a response similar to this: named:x:25:25:Named:/var/named:/sbin/nologin

If you don't, issue the following command as root: useradd -r -d /var/named -s /sbin/nologin named

Now, it's time to create the chroot jail. If you already have a directory hierarchy in /var and don't want to use it, execute this: rm -rf /var/named

Then issue the following commands: mkdir mkdir mkdir mkdir

-p -p -p -p

/var/named/chroot/dev /var/named/chroot/etc /var/named/chroot/var/run /var/named/chroot/var/named

Next, give the proper permissions to the directories, like so: chown -R root:named /var/named chmod -R 750 /var/named chmod -R 770 /var/named/chroot/var

Then, create some special character devices that the ISC BIND daemon needs: mknod chmod mknod chmod chown

/var/named/chroot/dev/null c 1 3 660 /var/named/chroot/dev/null /var/named/chroot/dev/random c 1 9 640 /var/named/chroot/dev/random root:named /var/named/chroot/dev/*

ISC BIND will need access to the local time from within its chroot jail: cp /etc/localtime /var/named/chroot/etc chmod 640 /var/named/chroot/etc/localtime chown root:named /var/named/chroot/etc/localtime

Then, create the PID file:

Page 6 of 16




touch /var/named/chroot/var/run/named.pid chown named:named /var/named/chroot/var/run/named.pid

Step 3. Set logging and other runtime options The final preparatory steps for installing ISC BIND are setting the runtime and logging options. We need to tell ISC BIND the directory we want it to run in, and we need to add hooks so that our ISC BIND can log to syslog. Fedora users can simply edit /etc/sysconfig/named so that it contains the following one line of content: ROOTDIR=/var/named/chroot

(Note: By default, /etc/init.d/named assumes that ISC BIND will be run as user named, so you do not need to include options for that.) As a result of editing /etc/sysconfig/named , when ISC BIND is started by the startup script /etc/init.d/named, it will have the following parameters: /usr/sbin/named -u named -t /var/named/chroot

Next, add hooks so that ISC BIND can log to syslog by editing /etc/sysconfig/syslog so that it is started with the following option: -a /var/named/chroot/dev/log

To do this, append to the SYSLOGD_OPTIONS variable: SYSLOGD_OPTIONS="-m 0 -a /var/named/chroot/dev/log"

Step 4. Create your configuration file (named.conf) This file will tie together all of your zone data files and perform various other tasks. It is responsible for telling the daemon where to find the zone data files, where to put a PID file, and various other things. The named.conf file for your domain (somedomain.com) is shown with comments. Create this file in /var/named/chroot/etc and then execute the following: chmod 660 named.conf chown root:named named.conf

Contents of /var/named/chroot/etc/named.conf: 1. 2. 3. 4.

; ; ; ;

This block essentially tells ISC BIND where to look for the zone data files for somedomain.com and where to write its PID (process id) file to. Note: these are relative to our chroot jail /var/named/chroot.


Page 7 of 16



5. options { 6. directory "/var/named/"; 7. pid-file "/var/run/named.pid"; 8. }; 9. 10. ; The next block is used to authenticate the control utility, rndc. 11. ; The block says that only connections originating from localhost with the correct 12. ; HMAC-MD5 encryption algorithm key can connect. 13. controls { 14. inet 127.0.0.1 port 953 allow { localhost; } keys { rndc.key; }; 15. }; 16. 17. ; The next block says that we are authoritative for somedomain.com 18. ; and that BIND should look in /var/named/somedomain.com.zone 19. ; for name-to-address mappings (i.e. forward mapping) 20. zone "somedomain.com" { 21. type master; 22. file "somedomain.com.zone"; 23. }; 24. 25. ; The next block says that we are authoritative for 192.168.1/16 and 26. ; that ISC BIND should look in "/var/named/1.168.192.in-addr.arpa.zone 27. ; for address-to-name mappings (i.e. reverse mapping) 28. zone "1.168.192.in-addr.arpa" { 29. type master; 30. file "1.168.192.in-addr.arpa.zone"; 31. }; 32. 33. ; The next block says that we are authoritative for loopback. You could 34. ; operate without it but we'll be pedantic. 35. zone "0.0.127.in-addr.arpa" { 36. type master; 37. file "0.0.127.in-addr.arpa.zone"; 38. }; 39. 40. ; This block is important for our domain because we're hidden. This allows 41. ; hosts on our network to resolve hosts on our company's or ISP's internal network. 42. ; When our name server receives a request for any host at mycompany.com it will 43. ; simply forward to one of the two IP addresses listed. For example, this would 44. ; allow a host on somedomain.com to resolve an internal web server 45. ; server1.mycompany.com. 46. zone "mycompany.com" { 47. type forward; 48. forwarders { 172.16.1.201; 172.16.1.202; }; 49. }; 50. 51. ; This special file tells our name server where the servers are for the root zone. 52. zone "." { 53. type hint; 54. file "cache.zone"; 55. };

Step 5. Create the forward zone file This file handles the name-to-address mappings for your domain (for instance, somedomain.com). The first block of text, lines 2 - 8, is the start of authority record (SOA). This block contains a few caching parameters for ISC BIND and a contact for your domain. The contact listing is slightly cryptic, but if you replace hostmaster. with hostmaster@ , you get [email protected].

Page 8 of 16




Line 11 says that our primary name server for somedomain.com is ns1.somedomain.com. Lines 14 - 16 map names to addresses. Enter the addresses for all static devices on your network (devices such as printers, Web servers, etc.). Be sure to put a period at the end of every .com; otherwise, you'll have serious problems. Create this file in /var/named/chroot/var/named and then execute the following: chmod 660 somedomain.com.zone chown root:named somedomain.com.zone

Contents of /var/named/chroot/var/named/somedomain.com.zone: 1. $TTL 86400 2. somedomain.com. IN SOA ns1.somedomain.com. hostmaster.somedomain.com. ( 3. 10 ; serial 4. 28800 ; refresh 5. 14400 ; retry 6. 3600000 ; expire 7. 86400 ; ttl 8. ) 9. 10. ; The name server for somedomain.com 11. somedomain.com. IN NS ns1.somedomain.com. 12. 13. ; Name-to-address mappings 14. localhost.somedomain.com. IN A 127.0.0.1 15. linus.somedomain.com. IN A 192.168.1.10 16. gateway.somedomain.com. IN A 192.168.1.1 17. printer1.somedomain.com IN A 192.168.1.11 18. 19. ; My name server is running on the same host as my web server/samba server but, 20. ; I want them to each have different names so we'll add an alias. 21. ns1.somedomain.com. IN CNAME linus.somedomain.com.

Step 6. Create the reverse zone file The reverse zone file handles address-to-name mappings for your domain. Its syntax is somewhat counterintuitive. The first block, lines 2 - 8, are the SOA record. Notice that our network 192.168.1/24 has been reversed in the SOA record and appended with in-addr.arpa (1.168.192.in-addr.arpa.). This reversing is related to the way IP addresses are resolved with DNS and is beyond the scope of this tutorial. Line 13 identifies ns1.somedomain.com. as the name server for our network. Lines 16 - 18 map static addresses to their names for our network. Notice how the IP addresses are all reversed. Create this file in /var/named/chroot/var/named and then execute the following: chmod 660 1.168.192.in-addr.arpa.zone chown root:named 1.168.192.in-addr.arpa.zone


Page 9 of 16



/var/named/chroot/var/named/1.168.192.in-addr.arpa.zone: 1. $TTL 86400 2. 1.168.192.in-addr.arpa. IN SOA ns1.somedomain.com. hostmaster.somedomain.com. ( 3. 4 ; serial 4. 28800 ; refresh 5. 14400 ; retry 6. 3600000 ; expire 7. 86400 ; ttl 8. ) 9. 10. 11. 12. ; The name server for somedomain.com 13. 1.168.192.in-addr.arpa. IN NS ns1.somedomain.com. 14. 15. ; Address-to-name mappings 16. 1.1.168.192.in-addr.arpa. IN PTR gateway.somedomain.com. 17. 10.1.168.192.in-addr.arpa. IN PTR linus.somedomain.com. 18. 11.1.168.192.in-addr.arpa. IN PTR printer1.somedomain.com.

Step 7. Create the loopback zone file This file is in the same format as the reverse zone file for your network (0.0.127.in-addr.arpa.zone), and it defines the loopback network. Create this file in /var/named/chroot/var/named and then execute the following: chmod 660 0.0.127.in-addr.arpa.zone chown root:named 0.0.127.in-addr.arpa.zone

Contents of /var/named/chroot/var/named/0.0.127.in-addr.arpa.zone: 1. $TTL 86400 2. 0.0.127.in-addr.arpa. IN SOA ns1.somedomain.com. hostmaster.somedomain.com. 3. ( 4. 4 ; serial 5. 28800 ; refresh 6. 14400 ; retry 7. 3600000 ; expire 8. 86400 ; ttl 9. ) 10. 11. 12. 13. ; Name servers for somedomain.com 14. 0.0.127.in-addr.arpa. IN NS ns1.somedomain.com. 15. 16. ; Address-to-name mappings 17. 1.0.0.127.in-addr.arpa. IN PTR localhost.

Step 8. Get the root hints zone file Page 10 of 16




This file tells your daemon how to get to the root servers for the root zone. It is maintained by InterNIC, and there are two ways to get it. The first is to FTP to ftp.rs.internic.net, then change into the domain subdirectory and get the file named.root. Rename the file to cache.zone and put it into /var/named/chroot/var/named. Then, execute the following commands: chmod 660 cache.zone chown root:named cache.zone

The second way to get it is to use a utility called dig (a replacement for nslookup). Simply change into /var/named/chroot/var/ and type the following: dig @e.root-servers.net . ns > cache.zone

Periodically, the root hits will change. It is your responsibility to keep your server updated.

Step 9. Update /etc/hosts and /etc/resolv.conf These two files control how names are resolved on your Linux box. You should update them to reflect your new network settings. After you have made the changes to /etc/hosts and /etc/resolv.conf, you should restart your computer or reboot your interface. Notice how your server linus is known by two different names ( linus and ns1 ) in /etc/hosts. This is not absolutely necessary, but to be prudent, you should tell the host that it is known by more than one name (that it has an alias). You do that like this: Contents of /etc/hosts: 1. 2. 3. 4.

# Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost 192.168.1.10 linus linus.somedomain.com ns1.somedomain.com

Contents of /etc/resolv.conf 1. nameserver 192.168.1.10 2. domain somedomain.com 3. search somedomain.com

Step 10. Secure the daemon By default, named opens two ports. The first, port 53, is reserved as a "well-known" port by the Internet Assigned Numbers Authority for the DNS protocol. The second port, 953, is a control channel for the daemon and is used by the daemon's control utility rndc. Linux-powered networking, Part 1

Page 11 of 16



Secure the control channel so that only connections from the local host with the proper encryption key can control your daemon. The first step is to place a controls statement in your named.conf file, lines 10 - 15 of Step 4. Create your configuration file (named.conf) on page 7. The controls statement allows only connections from the local host using a key from the key file rndc.key. The second step is to create a configuration file, rndc.confk, and a key file for the rndc control utility. Execute the following commands to create a key file: cd /var/named/chroot/etc/ rndc-confgen -a

Next, create a file named rndc.conf and place it in /etc. Fill it with the following contents: Contents of /etc/rndc.conf/ 1. options { 2. default-port 953; 3. default-server localhost; 4. default-key "rndckey"; 5. }; 6. 7. server localhost { 8. key "rndckey"; 9. }; 10. 11. include "/var/named/chroot/etc/rndc.key";

Step 11. Configure the firewall Most UNIX and Linux distributions ship with some type of firewall. This step shows how to open a hole in Fedora's firewall utility, iptables, for the DNS protocol. The iptables firewall utility is the default firewall utility for the vast majority of Linux distributions, so the information here applies to other Linux distributions. The DNS protocol uses port 53 by default. This panel describes how to add a rule to a firewall configuration file to allow all UDP traffic on port 53. Fedora's firewall configuration file is /etc/sysconfig/iptables. You will add a line to the configuration script that will only allow DNS traffic emanating from your network. This is important, because you do not want to allow hosts on other networks to use your DNS server. Insert the line -A RH-Firewall-1-INPUT -p udp -s 192.168.1.0/24 -d 192.168.1.10/32 --dport 53 -j ACCEPT

into /etc/sysconfig/iptables anywhere above the default reject rule (usually the last line). You may need to change the source network and destination address to match Page 12 of 16




your own network.

Step 12. Start the daemons You have now finished editing the required configuration files. All that remains is to restart syslogd and to start your name server. You need to restart syslog, because of the changes you made to its runtime parameters back in Step 3. Set logging and other runtime options on page 7. Issue the following commands: /etc/init.d/syslog restart /etc/init.d/named start

Check your logs to ensure that everything started correctly. If ISC BIND didn't start, you can try manually running it in the foreground for more information, like this: named -f

-u named -t /var/named/chroot/

Step 13. Test everything Testing is simple and essential. First, try to look up the IP of your gateway. The gateway is a good choice, because it is explicitly named in your forward zone; however, you could substitute any host you mapped there. Do it like so: nslookup -sil gateway

You should see that nslookup uses 192.168.1.10 to resolve the gateway to 192.168.1.1. Next, try to resolve ns1.somedomain.com with this: nslookup -sil ns1.somedomain.com

Notice that ns1.somedomain.com gets resolved to linus.somedomain.com. This is because of your alias, line 21, in the forward zone file. Why didn't we just use linus.somedomain.com instead of aliasing the name server to ns1.somedomain.com ? Because, if you ever decide to run ISC BIND on a server other than linus.somedomain.com , you will not need to update all of the static hosts on your network to point to ns1.somedomain.com . Next, try to resolve a host on your company's/ISP's domain like this: nslookup -sil somehost.mycompany.com

This should work because of the forwarding statement, lines 39 - 42, you put in to named.conf. Finally, try to resolve a host on the public Internet like this: nslookup -sil www.ibm.com

This should work because of the root hints you added to named.conf, lines 45 - 48. Linux-powered networking, Part 1

Page 13 of 16



Hopefully everything worked; if it didn't, see if you can go back and troubleshoot where the problem is. Now just sit back and enjoy the speed and control you have over your own private network.

Page 14 of 16




Section 4. Summary and resources Summary By installing and running your own name server, in this case ISC BIND, you can: ° Improve redundancy ° Increase speed, including response times to name server queries ° Assume the ability to name devices attached to your network The 13 steps in this tutorial showed you how to deploy ISC BIND as a name server on your system. The next tutorial in this series on getting the most out of Linux describes how to implement a Dynamic Host Configuration Protocol (DHCP) server -- a protocol that is used to dynamically assign IP addresses to network clients -- using the Internet Systems Consortium (ISC) DHCP.

Resources ° Read Part 2 of this tutorial series, which shows how to set up a Dynamic Host Configuration Protocol (DHCP) server with Internet Systems Consortium (ISC) DHCP. ° Read Part 3 of this tutorial series, which shows how to set up and configure Samba with your system, so that you can integrate your Linux and Windows networks. ° You can also download the ISC source from the Internet Systems Consortium (http://www.isc.org) . ° Be sure to read the UNIX man pages for DNS (http://www.mcsr.olemiss.edu/cgi-bin/man-cgi?dns+7) and BIND (http://www.mcsr.olemiss.edu/cgi-bin/man-cgi?bind) . ° DNS and BIND, 4th Ed., by Paul Albitz and Cricket Liu (O'Reilly and Associates, Inc., 2001) gives a detailed background on these two important Internet standards. ° Using The Domain Name System -- A Primer (developerWorks, April 2003) introduces DNS. ° The Windows-to-Linux roadmap series is a powerful introduction to Linux with solid information on IP networking. ° The Programming Linux sockets tutorial (developerWorks, October 2003) provides an excellent introduction to IP networking. ° Find more resources for Linux developers in the developerWorks Linux zone (http://www.ibm.com/developerworks/linux/) . ° Download no-charge trial versions of IBM middleware products that run on Linux, including WebSphere Studio Application Developer, WebSphere Application Server, DB2 Universal Database, Tivoli Access Manager, and Tivoli Directory Server, and explore how-to articles and tech support, in the Speed-start your Linux app section of developerWorks. ° Get involved in the developerWorks community by participating in Linux-powered networking, Part 1

Page 15 of 16



developerWorks blogs (http://www.ibm.com/developerworks/blogs/) . ° Purchase Linux books at discounted prices in the Linux section of the Developer Bookstore.

Feedback Please let us know whether this tutorial was helpful to you and how we could make it better. We'd also like to hear about other tutorial topics you'd like developerWorks to cover. For questions about the content of this tutorial, contact the author, Keith Robertson, at [email protected] .

Colophon This tutorial was written entirely in XML, using the developerWorks Toot-O-Matic tutorial generator. The open source Toot-O-Matic tool is an XSLT stylesheet and several XSLT extension functions that convert an XML file into a number of HTML pages, a zip file, JPEG heading graphics, and two PDF files. Our ability to generate multiple text and binary formats from a single source file illustrates the power and flexibility of XML. (It also saves our production team a great deal of time and effort.) For more information about the Toot-O-Matic, visit www-106.ibm.com/developerworks/xml/library/x-toot/ .

Page 16 of 16


IBM - Linux-powered Networking, Part 1_ Build a DNS Server With ISC BIND

Recommend Documents