A Crash Course: DNS & BIND If you are familiar with the DNS and operating BIND, then this appendix is probably irrelevant to you. But if you have never set up a name server before, doing so may be a daunting task. To get started, this section provides the absolutely necessary basics, so you might get away without reading some more advanced documentation, like Albitz’ and Liu’s “DNS and BIND” [2] or the “BIND 9 Administrator Reference Manual” [73] for now. To keep things simple, we ignore IPv6 and just focus on IPv4 addresses. A.1 Domain Name System (DNS) Basics The domain name system (DNS) takes a domain name and uses it to look up resource records (RRs) associated with that name. Each RR consists of a domain name,arecord type,arecord class which is always IN for “Internet” for our purposes, a time to live (TTL) that specifies how long the entry may be cached, and finally the associated data. If we want to surf “www.example.com”, our web server uses the resolver li- brary to send a forward query to a name server, asking for the “type A” records associated with the domain name “www.example.com.”tolearnaboutthe IP address of the web server with that name. The web server, when accepting the connection from the web browser, may use the IP address used by the browser to do a reverse lookup, making the resolver turn the IP address into a funny-looking domain name that can be queried for the associated “type PTR” record. This record should contain the host name of the machine we run the web browser on. To make the DNS scalable, names are structured hierarchically. The root domain,“.” contains all names. Most importantly, it contains the top-level domains,like“net.”or“org.”. These domains contain the second-level domains like “benedikt-stockebrand.net.” or the one we use here for our demonstration purposes, “example.com.”. Within these domains we may have additional subdomains as well as RRs that actually contain data. 350 A Crash Course: DNS & BIND Reverse lookups convert IP addresses into domain names in the pseudo do- main “in-addr.arpa.” by reverting the order of address bytes, thus turning 192.0.2.80 into “80.2.9.192.in-addr-arpa.”. If you look closely, you see that a domain name always ends in a trailing dot.Thisshowsthatitisafully qualified domain name (FQDN )andisrooted in the root zone. A name without a trailing dot is an unqualified domain name and a default domain name needs to be appended to form the FQDN. If we configure our system to use “example.com.” as the default domain, then we can use “www” as an abbreviation for “www.example.com.”. To make the DNS scale, a domain may delegate a zone to another name server or set of servers. A zone is like a subdomain, except that it doesn’t contain the zones it delegates itself. The root servers delegate the “com.” zone to some other servers, so “example.com.” is still within the root domain, but not within the root zone. Every RR belongs to a single zone but to an entire series of domains. (Later on we’ll learn about the two exceptions from this rule necessary to delegate a zone.) To make the DNS scale to Internet proportions it is necessary to main- tain forward and reverse zones independently of each other. This is a major nuisance in many cases but can’t be helped. For every zone there is a primary name server (sometimes called the mas- ter for historical reasons) and a set of secondary name servers (or slaves). The zone data is actively maintained on the primary and from there distributed to the secondaries. These servers are called authoritative name servers because they are assumed to hold correct data at all times. In contrast to that, name servers are called non-authoritative if they only provide cached data for the zone in question. They have either queried an authoritative name server themselves or asked another “upstream” caching name server called a forwarder. Normally, programs always use a caching name server, which builds up a rich cache that takes a lot of load from the authoritative servers while providing for fast DNS lookups. All name servers, even authoritative ones, usually also operate as a caching server. A.2 The BIND Name Server The standard name server software used with Unix is called BIND, short for Berkeley Internet name domain. It consists of the actual name server daemon called named and a set of additional tools. A.2.1 Installation To set up a name server, we may first need to install some additional packages: A.2 The BIND Name Server 351 Debian Sarge The name server proper is in package bind9 and some es- sential tools like dig in dnsutils. FreeBSD 6.1 Here the name server is part of the core system, so no ad- ditional packages are necessary. But we need to build some of the default configuration by doing # cd /etc/namedb # sh make-localhost example.com to make our name server usable. Solaris 10 The name server service manifest and the name server proper are in the packages SUNWbindr and SUNWbind. Depending on the subrelease and patchlevel, we may also need to install patch 119783 (SPARC) or 119784 (x86) and reboot the machine to fix a bug1. 136 If you want to use an existing BIND installation, make sure the version of BIND is at least 9.2.3 or up; otherwise you will run into problems later on. A.2.2 Base Configuration The named daemon maintains its configuration in a file called named.conf. Authoritative name servers store the data of their zones in separate zone files. Unfortunately, different Unixen have not only complex but also widely differing default configurations. The named.conf file may reside in /etc (So- laris 10), /etc/bind (Debian Sarge), /etc/namedb (FreeBSD 6.1) or wherever else an installation chooses to put it. Additionally, the name server daemon named is sometimes run in a chroot environment, adding more problems: The configuration may actually reside in the chroot environment instead of /etc while a symlink in /etc points to the actual location, usually somewhere within /var—this can prove disastrous if our backup doesn’t include these files. In other cases, the boot scripts copy the configuration files from /etc to the chroot environment whenever we restart named—as a result, they may happily overwrite any changes we applied there directly, and restarting the named directly will keep it running with the old configuration. This leaves you a difficult choice: Either abandon all the standard configu- ration and start from scratch or adapt the default configuration accordingly. If you want to start from scratch, a complete albeit minimal configuration may look like this: named.conf options { directory "/var/named/zonedata"; pid-file "/var/run/named.pid"; allow-query { "any"; }; }; 1 On an unpatched system a reboot will disable the DNS service again. 352 A Crash Course: DNS & BIND It tells the name server that all the zone data files are kept in the directory /var/named/zonedata, to keep the PID file in a standard place and to allow queries from any address. At this point the named worksasacaching-only server that is not authoritative for any zones. Debian Sarge The configuration options for named are kept in a sepa- rate file /etc/bind/named.conf.options while the zone configurations go to /etc/bind/named.conf.local. You need to adapt the following examples accordingly. FreeBSD 6.1 The named.conf fileislocatedin/etc/namedb/. Solaris 10 The packages don’t include a default configuration, so we create afile/etc/named.conf with the minimal configuration shown above and a directory /var/named/zonedata to hold the zone files. 137 A.2.3 Forwarder Configuration and Fake Root Zones Next we need to tell the name server how to deal with requests for data that it isn’t authoritative for. It is easiest to ask our provider for the IP address of their DNS server and add another line to the options section of named.conf that reads something like named.conf options { [...] forwarders { 192.0.2.1; }; [...] } given that the IP address of our provider’s DNS server is 192.0.2.1.Theal- ternative approach, using a hints file that contains the addresses of root name servers, is beyond the scope of this crash course—see the BIND literature, for example Albitz and Liu [2, pages 67–69] if you want to do this. In an isolated test network without Internet connectivity this doesn’t work, because we can’t reach a forwarder or root name server. Section 5.2.3 has a solution to deal with this problem: Setting up a fake server for the root zone will ensure that all requests will be served without waiting for a timeout, but possibly with a negative result. A.2.4 Starting the Name Server Nowweenablethenamed daemon. Debian Sarge The bind9 package automatically installs the appropriate boot scripts; we just run /etc/init.d/bind9 start or reboot our machine. A.2 The BIND Name Server 353 FreeBSD 6.1 We add a line /etc/rc.conf named_enable=YES to /etc/rc.conf andeitherrebootorrun/etc/rc.d/named start by hand. Solaris 10 We run the command svcadm enable dns/server. 138 At this point we should have a running name server. Checking that it works is reasonably straightforward: Check with ps that the named process is running.