Unix Web Hosting for Developers

Parentheses While technically the SOA record should be on a single line, if it were, it would be difficult to read. Instead, standard zone files have this broken up into several lines, with the first opening parenthesis (or round bracket) indicating the line break. Each of the next five lines is part of the SOA record, with the record ending with the closing parenthesis. Serial Number The first piece is the serial number, which indicates the zone file’s version (|). While the serial number can be whatever you choose, it’s most convenient to use the date. You’ll usually see the date in YYYYMMDD format with two extra digits at the end. This serial number, 20010601, represents June 1, 2001. The extra two numbers in the serial number represent the number of times the file has changed in a day. For example, there have been times that I’ve had to update one domain a dozen times in one day, with each change requiring a serial number bump. Here’s how this works: Say I create the zone file on May 9, 2002, with the first serial number 2002050901. If I change the zone file on June 8, the serial number changes to 2002060801. If I then change the zone file a second time on that same day, the serial number changes to 2002060802. This system allows up to 100 changes in a day, or roughly one change every 15 minutes. If this isn’t enough for you, you need to rethink your work processes. The serial number is important, because every so often a slave server will contact the master server to see if the zone has updated. It determines whether there’s been an update by comparing the serial number of its cached copy to the master zone file’s serial number. If the master zone file’s serial number is greater than the one on the slave, the slave server determines that the zone file has been updated and downloads the latest domain information. Note If your secondary nameservers haven’t updated their zone files from the master nameserver, it’s probably a serial number problem. Even if you swear up and down that you incremented the serial number, increment the serial number again and try once more. It’ll probably work. Refresh The next number is the refresh value, in seconds (}). This number determines how frequently slave servers will contact the master server to check for an updated master file. In the localhost.rev file, a secondary nameserver would update every 3,600 seconds, or 60 minutes. If the slave cannot check its data against the master in a refresh attempt, it keeps giving answers with its current record that’s what a backup nameserver is for, after all! We’ll see exactly how this works in the “Refresh, Retry, and Expire in Practice” section. Retry The next number is the retry value, also in seconds (~). If the slave cannot reach the master nameserver, it will retry at this interval. Our sample file has a 900 second (15 minute) retry. If the secondary nameserver cannot update at the 1 hour mark, it will keep trying every 15 minutes until the master nameserver answers. Again, we’ll see exactly how this works in the “Refresh, Retry, and Expire in Practice” section. Expire Next we have the expire value, in seconds ( ). If a slave nameserver cannot update its records for this many seconds, it stops giving out its cached information. It’s at this point that the administrator thinks bad information is worse than no information. In our example we have 3,600,000 seconds (1,000 hours, or a little over 41 days). Minimum TTL The last number is the minimum time to live (j). In older implementations of BIND, this was used for the time to live for absolutely everything. Today, it’s only used for the TTL for negative answers. (Nameservers can cache negative answers.) For example, if you look up givememymoneyback. http://www.absolutebsd.com/, your nameserver will learn that there’s no such host. In localhost.rev, negative answers will be cached for 3,600 seconds (1 hour). 284

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services

| 20010601 ; Serial } 3600 ; Refresh ~ 900 ; Retry 3600000 ; Expire j 3600 ) ; Minimum IN NS satariel.blackhelicopters.org. 1 IN PTR localhost.blackhelicopters.org. ………………………………………………………………………………………. First of all, remember that anything that begins with a semicolon is a comment. (Comment your zone files liberally; it’ll help you figure out later what the heck you were doing.) $TTL: Time to Live We’ll skip on through this file to the first line of real interest, the $TTL statement (v). This statement is the zone’s default time to live, in seconds (3,600 seconds, in this case), and it dictates how long other servers will cache information from this zone. You can give data in the zone any time to live you choose. This is actually a fairly short time; a good average is 10,800, or 3 hours. Choosing a TTL is something of a black art; stick with the default, and you’ll be fine for most purposes. Start of Authority Next is the Start of Authority (SOA) record. This is a brief description of the zone, and of how its characters and servers should treat it. Every zone has exactly one SOA record. The SOA does not include information about what is in the domain, merely information about how long this information lasts. The @ sign The at symbol (@), which begins the SOA record (w), is a special character that’s shorthand for “whatever named.conf says this file is for,” and in this case, named.conf says that this file holds data for the zone 0.0.127.in-addr.arpa. When named reads named.conf and loads this file into memory, it makes this substitution. Using the actual domain name would be less confusing for new users, but you’ll see this in most nameservers and will need to be familiar with it. You could use the full domain name in this file instead of the @ symbol if you wished, but almost nobody does that. The Data Type and Label The IN represents the type of data (x), Internet data in this case, and SOA means that this is a Start of Authority record ($). Both elements will appear in every DNS record you create. Machine Name The next part is the name of the machine where the master file lives (z). (This file was created on satariel.blackhelicopters.org.) Responsible Party Then we have the email address of the person responsible for this zone ({). Since the make-localhost script defaults to root@hostname, the email address lacks the @ sign, because the @ sign had already been assigned to mean the zone name from named.conf.[1] (Were we to put the @ in, the email address would become http://root0.0.127.in-addr.arpa.satariel.blackhelicopters.org/. That would be worse than http://root.satariel.blackhelicopters.org/, wouldn’t it?) This is important when you create your own zone files for your domains. Replace the @ in the email address with a period. In many cases, the nameserver doesn’t have a mail server on it. To follow best current practices on the Internet, replace the email address with hostmaster. and your domain name. Every domain is expected to have a “hostmaster” email address to respond to DNS issues. 283

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

must be preserved. Files in the slave zone aren’t exactly garbage, but their loss is no big deal. If you expect to serve thousands of domains, you might want to divide your master zone files still further. I use a set of 36 directories under the master directory, one for each letter and number. Of course, you can create any arrangement of directories that fits your needs. Just remember that you’re going to either live with this arrangement or go through some annoyance changing it. Taking this to the logical extreme, your zone entry could look like the following: ………………………………………………………………………………………. zone “AbsoluteBSD.com” { type master; file “master/clients/a/absolutebsd.com”; }; ………………………………………………………………………………………. Most people do not need this number of subdirectories, but you could do it if you needed to. Zone Files At this point we have a configuration file that tells named what domains it’s responsible for, and where the files that contain the information on those domains live. But we still need to make those files! Zone files have a rather obscure syntax because, much like sendmail, BIND was assembled by programmers who were more interested in efficiency than ease of use. Unlike sendmail, zone file configuration is not blatantly user-hostile, though some parts of zone files appear inconsistent. To learn how to work with zone files, follow the given examples and you should be all right. And any time you find yourself scratching your head and wondering why they did something a certain way, just remember that you’re digging through the primordial ooze of the Internet. (If DNS were invented today, zone files would probably look very different.) Here’s a simple example of configuring a zone file. FreeBSD includes a shell script to create the localhost file, make-localhost. To create the localhost file, all you have to do is go to /etc/namedb and type this: ………………………………………………………………………………………. # sh make-localhost ………………………………………………………………………………………. And poof! The file localhost.rev appears. We’ll dissect this file as our first example. ………………………………………………………………………………………. ; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90 ; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $ ; ; This file is automatically edited by the `make-localhost’ script in ; the /etc/namedb directory. ; v $TTL 3600 w @ x IN y SOA z satariel.blackhelicopters.org. { root.satariel.blackhelicopters.org. ( 282

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services

Setting Up a Slave Perhaps the easiest task in DNS is to set up a slave domain. The entry will look much like the entries for the root zone and the localhost zone. You need to know the name of the domain you want to slave, and the IP address of the master nameserver. To set up a slave domain, copy the localhost zone entry and change it slightly. The configuration for the slave server for http://absolutebsd.com/, for example, looks like the following, which closely resembles the root and localhost zones. ………………………………………………………………………………………. v zone “AbsoluteBSD.com” { w type slave; x file AbsoluteBSD.com.db; y masters {209.69.178.18;}; } ……………………………………………………………………………………………….. We have the domain name (v), a label for the type of zone it is (w), and a filename (x). The filename is where the information for the domain is kept. It’s traditional in DNS to give these files the same name as the domain, with a “.db” extension. (Despite what the extension might imply, these files are in no way databases.) This file will be created when the slave downloads the domain data from the master. We then have the IP address of the master server (y). The slave will request the domain’s DNS information from the master at regular intervals. (We’ll see what sort of intervals later.) The master nameserver must be listed by IP address; after all, the DNS server must be able to bootstrap its records before it knows the IP of anything! Setting Up a Master The named.conf configuration you need when you want a server to be a master is even simpler than the setup for a slave zone: ………………………………………………………………………………………. v zone “AbsoluteBSD.com” { w type master; x file AbsoluteBSD.com.db; } ………………………………………………………………………………………. Once more there’s the domain name (v), a label for the type of zone it is (w), and a filename (x). Unlike a slave domain, you’ll have to create this file. We’ll look at how to create that file in the “Zone Files” section. Setting Up Multiple Zones If you’re managing high-end Internet nameservers, you may be responsible for thousands of domains. If you screw up, you will have a lot of people very angry with you. Therefore, before you set up hundreds of zones, think about how you’re going to arrange them. One thing that can make your life easier when setting up multiple zones is to divide a server’s zone files between those that the server is the master for and those that the server just backs up. I usually do this with two directories, master and slave. Files in the master directory are sacred, and 281

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

The Root Zone The nameserver uses the root zone when it has no information on a requested domain or host. These queries are recursed to a root nameserver. Here’s the named.conf entry for the root zone: ………………………………………………………………………………………. zone v “.” { w type hint; x file “named.root”; }; ………………………………………………………………………………………. The first entry (v) tells which domain this entry is for. The dot, in quotes, indicates that this is for the entire Internet. The type (w) is an indicator that says what sort of domain this is. The root zone is special, and it is the only one with the type of hint. Finally, the file keyword (x) tells named which file contains the information for this domain. Named will look in the directory specified in the directory option for a file of this name, and will assign its contents to this zone. We’ll look at these files later. Localhost Zones The localhost zones (IPv4 and IPv6) are used for the local host; they provide DNS services for the loopback IP address, 127.0.0.1. Without them, each system call that tried to look up the hostname for the local host would have to wait to time out, slowing the system immeasurably. Each looks much like the root zone, with a different filename. Here’s the configuration for the IPv4 localhost zone. You’ll find it in named.conf, just under the root zone: ………………………………………………………………………………………. zone v “0.0.127.IN-ADDR.ARPA” { w type master; x file “localhost.rev”; }; ……………………………………………………………………………………………….. Looks pretty similar to the options statement and the root zone in the previous section, doesn’t it? The zone name (v) appears in quotes after the word zone. Because this zone is used for reverse DNS, we see IN-ADDR.ARPA. (If you reverse the IP address, you’ll see it’s actually for the 127.0.0 group of IP addresses.) The type (w) indicates whether this nameserver is a master or a slave for this domain. Every nameserver is a master for the localhost zones. Finally, the file keyword (x) tells the nameserver where the file of information on this domain can be found. The information on this zone is contained in the file localhost.rev, found in the directory specified in the directory option. 280

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services

There are two types of entries in named.conf: options and zones. Everything in your configuration file should be either an option, a zone, or a comment. A zone is a fancy name for a domain (while they aren’t, strictly speaking, identical, they’re close enough for our purposes). Options control how BIND operates. Options If you ignore the comments in the default named.conf, the file opens with a list of options, most of which are obscure and are commented out by default. You use options by putting them in the options section of the file, which contains the word options and a set of curly brackets. The actual options go between the brackets and are separated from one another by semicolons. Here’s a very simple options section from a named.conf file: ………………………………………………………………………………………. options { directory “/var/named”; listen-on {127.0.0.1; 209.69.178.18; }; }; ………………………………………………………………………………………. In this example, the option directory has the value /var/named , and the listen-on option lists two IP addresses. Let’s first look at the directory option, which specifies the directory where named.conf will look for and store DNS files. Beginning here will make setting up your server more straightforward. The default directory (/etc/namedb) should be fine if all you want to do is provide a nameservice for a couple of domains. However, if you are providing DNS for dozens or hundreds of clients, this directory will quickly become painfully full and will be unable to live on the root partition. The standard alternative to /etc/namedb is /var/named, which is the location for nameservice files on larger servers. I generally use /var/named even when I have just a few domains to serve, as these files tend to accumulate. The listen-on option controls which IP addresses named will accept connections on. If you have dozens of IP addresses on a single network card, you might want to confine your named to attaching to only one of those addresses. (This is particularly valuable if you have jails on your system.) BIND supports many more options, but these are perhaps the most popu- lar. You can check the full BIND Operators Guide (at http://www.isc.org/) for the complete list of options and their usage. Zones The default named.conf defines three zones, or domains, that the nameserver handles by default: the root zone, the IPv4 localhost, and the IPv6 localhost. Each of these zones has an entry in named.conf, beneath the options list. You shouldn’t need to tweak the default zones in fact, if you’re thinking of changing them, you’re almost certainly doing something wrong. But we’ll discuss what these zones are for and what they do. 279

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

In-addr.arpa There’s one major difficulty with PTRrecords: Often, when they appear, they’re listed backwards. You see, DNS checks hosts from left to right. When you check for the host http://www.absolutebsd.com/, the nameserver first looks for a nameserver for .com. It then checks under .com for http://absolutebsd.com/, then under http://absolutebsd.com/ for http://www.absolutebsd.com/. The biggest units are on the left, but in an IP address, the biggest unit is on the right. To check the IP address, we have to reverse it. For example, we turn 66.80.60.21 into 21.60.80.66. It’s very easy to confuse a forward IP address with a reversed IP address, so DNS uses a special marker to indicate that an IP address is reversed. Reversed IP addresses have the string in-addr.arpa on the end of them. (The reasons for this date back several years and are quite boring, so we won’t go into them.) The bottom line is that our 66.80.60.21 becomes 21.60.80.66.in-addr.arpa. So why not just leave the IP address forward, and use the in-addr.arpato indicate it’s a reverse DNS check? Glad you asked. The preceding address is a simple one, and if you ran dig, it would check a very limited space. If you’re running a large network, you might need to run a DNS query of a much larger range of IP addresses, like 118.168.192.in-addr.arpa, which would translate to everything under 192.168.118. You might even need to run 168.192.in-addr.arpa, or even 192.in-addr.arpa. Each is a check of an increasingly large space much like doing dig .com. (You’ll probably never need to run dig .com, but Internet backbone engineers do, and backbone engineers are the ones who write this sort of program. One of the problems with using professional-strength tools is that they’re geared toward, well, professionals.) Note If you’re looking for quick-and-dirty answers, host(1) does this reversal for you. Dig also does this for you, if you use the -x option. Don’t be confused when you see in-addr.arpa, however. Configuring Named Before you can start named, you need to set it up. The directory /etc/namedb contains the basic named configuration files. named.root One file that must be present, but that doesn’t need editing, is named.rooti, which lists the root nameservers. If a nameserver receives a query for a site it doesn’t have in its cache, it asks these nameservers. (This file changes rarely the last update was in August 1997.) You may need to edit this file if your system is not on the Internet and if you have a private root server. named.conf The other important file is named.conf, named’s central file. If your named.conf file is broken, your nameserver is hosed. The syntax of named.conf resembles C code. If you don’t know C, though, don’t worry, because the rules are very simple, and the examples demonstrate everything you need to know. Any line beginning with two slashes (//) is a comment. Similarly, any text contained within old-fashioned C comment marks (/* and */) is a multi-line comment. 278

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services

http://ralph.glblnet.com/ is both a master and a slave nameserver, but for different domains. Forward and Reverse DNS You may have heard of or otherwise encountered the concepts of forward and reverse DNS. Forward DNS is what you do when you have a hostname and you look up an IP address. You saw examples of forward DNS in the A records in our dig examples: ………………………………………………………………………………………. nostarch.com. 2h13m2s IN A 66.80.60.21 ………………………………………………………………………………………. The A means that this is an address record, or forward DNS. This is known as an A record or an address record. Reverse DNS is what you do when you have an IP address and want a hostname. For example, suppose your system logs show that someone keeps trying to connect to your SSH server from the IP address 66.80.60.21, and you want to know the name of that host. You can look up IP addresses using dig’s -x option. Much of the output will look the same as a forward lookup, but the answer is considerably different: ………………………………………………………………………………………. # dig x 66.80.60.21 … ;; ANSWER SECTION: 21.60.80.66.in-addr.arpa. 2h24m IN PTR www.megapathdsl.net. # ………………………………………………………………………………………. Examining this output we see that, for historical reasons we won’t delve into, IP addresses are displayed in reverse order and as part of the domain in-addr.arpa when you’re doing a reverse lookup. Next we have the usual time-to-live data and the IN for Internet data. The interesting part is the PTR or pointer record, which tells us that an IP address “points to” a name. Basically, this is the canonical, most correct hostname for an IP address. This is much like a phone system; again, while many people can share a phone number, it’s only registered to one person. Forward and reverse DNS are generally expected to match, but since many hosts can share one IP address, an A record does not necessarily need a matching PTR record. For example, we saw earlier that http://nostarch.com/ has an IP of 66.80.60.21, but the hostname associated with that IP address is http://www.megapathdsl.net/. The part that must match is the A record for http://www.megapathdsl.net/. If the hostname given by a reverse lookup does not have a matching forward record, DNS is not correctly configured, and the tools that rely upon DNS checking, such as certain configurations of TCP wrappers, will reject connections from this system. Fortunately, automated tools exist to check forward and reverse DNS matches. 277

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services

something like this: ………………………………………………………………………………….. 192.168.1.2 mail.mycompany.com mail ftp www dns dns ………………………………………………………………………………….. Using this /etc/hosts entry, the desktop could find that host (mail.mycompany.com) with either the full domain name or any of the brief aliases listed (such as ftp.mycompany.com, www.mycompany.com, and so on). If you find that you need more than two or three hosts entries, or that maintaining hosts files is becoming a problem, it’s a sign that you need to build a nameserver to handle your hosts data. A nameserver is far more scalable than a hosts file on each machine, and it’s much simpler to maintain once you set it up. The Named Daemon The most popular DNS server software is BIND (Berkeley Internet Name Daemon). (The actual server program is called named(8).) BIND is actually a suite of tools that includes named and supporting programs such as dig. BIND is maintained by the Internet Software Consortium (http://www.isc.org/) and is released under a BSD-style license. While there are competitors, such as djbdns (/usr/ports/net/djbdns), BIND is considered the nameservice reference implementation, so we’ll focus on it. The concepts used in BIND are generally applicable to any nameserver programs. Because BIND has been the target of malicious hackers over the last several years, its most recent version was completely rewritten with a focus on security. It includes some very powerful security features and extremely defensive programming. Masters and Slaves No matter what nameserver daemon you use, you’ll keep running into the terms masters and slaves. Every domain needs at least two nameservers, but only one can be the master; the rest are slaves. A master nameserver is the final authority on a domain. When you make changes to a domain, you make the changes on the master nameserver. The slaves take their information from the master nameserver for that domain. One nameserver can be both a master for some domains and a slave for others. For example, http://absolutebsd.com/ has two nameservers, http://blackhelicopters.org/ and http://ralph.glblnet.com/; http://blackhelicopters.org/ holds the original reference files for this domain, and any changes are to be made on that system. That makes http://blackhelicopters.org/ the master nameserver. Every so often, http://ralph.glblnet.com/ updates its records for this domain from http://blackhelicopters.org/, making it the slave. If the blackhelicopters.org system is abducted by aliens, http://ralph.glblnet.com/ would continue to serve DNS information for http://absolutebsd.com/. On the other hand, http://ralph.glblnet.com/ holds the master records for many other domains, and other nameservers update their records for these domains from http://ralph.glblnet.com/. Therefore, 276

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services

The Nameserver List Now that your resolver knows which domains to try by default, you can tell it which nameservers to use. List each nameserver on a single line, in the order of preference. The nameservers will be tried in order. It would look something like this: ………………………………………………………………………………….. nameserver 127.0.0.1 nameserver 209.168.70.3 nameserver 192.168.87.3 ………………………………………………………………………………….. Note that the first entry in this list is the “loopback” IP address 127.0.0.1. You’ll need this entry if the machine is a nameserver because it tells the resolver to check the local host’s nameserver. While in some rare instances you might not want to use the local nameserver, you don’t have to, but in most cases it’s a waste of network bandwidth not to. With nameserver entries and either domain or search keywords, your /etc/resolv.conf is complete. DNS Information Sources To truly manage Internet services, you must be able to control your own domain naming service. While many ISPs will provide this service for you, you don’t want to have to coordinate with their staff to make a vital change in your infrastructure. Now that you know how to look at DNS data, and how the chain of DNS authority works, you can start building your own nameserver. FreeBSD includes all the software you need to run a DNS server; all you have to do is configure it and turn it on. We’ll do so by building the two possible sources of hostname and IP address information: the hosts file and the named daemon. Each is configured separately. The Hosts File The /etc/hosts file matches Internet addresses to hostnames for a single host. However, while the hosts file is very simple, its contents are only effective on a single machine. One system cannot use the hosts file from another system, without some unpleasant tricks. Dynamic nameserver programs have largely superseded /etc/hosts, but the hosts file is still useful on small networks or behind a Network Address Translation (NAT) device. For example, the hosts file is just fine if you have one or two servers and if someone else is responsible for managing your public nameservice. If you have multiple servers that would each have to be maintained separately, you should investigate using a full-fledged nameserver. Each line in /etc/hosts represents one host. The first entry on each line is an IP address, and the second is the fully qualified domain name of the host, such as mail.mycompany.com. Following these two entries you can list an arbitrary number of aliases for that host. For example, a small company might have a single server that handles mail, FTP, Web services, DNS, and a variety of other functions. A desktop on that network might have a hosts entry 275

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Cheap Web Hosting services