How named Works
named (pronounced name-d) is the BIND name server daemon. This software answers queries about hostnames and IP addresses. When named doesn't know the answer to a query, it asks other servers (typically in the top-level domains) that provide information on how to contact other name servers responsible for the domain in question. named caches this information in case there's a need to find another host near that domain. This allows it to ask a closer name server for the answer in future queries. This effectively skips the top-level name servers from the process and reduces the overall effort required to obtain the new address.
There are three types of name servers:
- Primary
- Secondary
- Caching-only
Name servers are distinguished by the source of their information and if the server providing the information is authoritative for the domain. Authoritative name servers provide information that is "guaranteed" to be correct. While nonauthoritative answers are usually correct, primary and secondary servers for a domain are the only servers authoritative for the information. Caching-only name servers are never authoritative, although they help speed up the process a great deal.
I should qualify the guaranteed qualifier I used in the last paragraph. It is possible for information provided by a secondary name server to be stale. Unless the System Administrator manually updates the secondary servers, it is possible for secondary servers to distribute stale information until their refresh period expires. A refresh period forces secondary name servers to check for changes on the domain database file after the period of time specified by the Administrator managing the domain is complete. Typically this period is no longer than six hours.
If you were wondering about the reliability of cached information, it will satisfy your curiosity to learn that DNS information is usually cached for a little while. Cached information only exists until the Time To Live (TTL) delay expires. The TTL for DNS-cached records is usually set to one day. You should also be aware that the top-level and sometimes second-level domain name servers never cache information. Otherwise, top-level information could be vulnerable to tainted information. Also, because of the amount of information they handle, their caches would quickly grow and bloat, which increases the computational load required to find an answer.
Running Your Own Domain Name Server
Before you proceed, you will need to register your domain name with the InterNIC if your domain falls into any of the ORG, NET, EDU, GOV, and COM domains. If you want to register a U.S. domain, go to http://www.isi.edu/in-notes/usdnr.
Registering your domain involves a few steps:
- Figure out where in the domain hierarchy your organization falls.
- Find a domain name that is not in use by another site in that domain hierarchy.
- If you are not on the Internet yet, find someone that will host a temporary name server for you.
- Fill out an application.
- Wait for the application to be approved.
Registering your own domain can be a great thing. It establishes your identity in the Internet, and it makes you available to the world. To search for names that have not been taken, you can visit http://rs.internic.net for searches involving ORG, NET, EDU, GOV, and COM domains. To search in the U.S. subdomain, visit http://www.isi.edu/in-notes/usdnr).
Choose the registration services link. Once on that page, choose the Whois registration tool. This page gives you a Web interface to the whois program. The whois program allows you to research domain name information among other things. If you find a match, your name is in use. Some things to keep in mind: domain names cannot be longer than 26 characters and can only contain letters, digits, and dashes.
Once you find a name that is not in use, you can go ahead and complete the World Wide Web application form. You will need to have the address for two name servers that supply information about your domain. The machines you list in the application will be queried for information about your domain, so you need to make sure that they are reachable or if your network is not up, that someone runs DNS for you temporarily. Usually your service provider can help with this. If the name servers are not found during the verification process, your application will be delayed.
Once you complete the online form, a copy of the application will be mailed to you. Please note that the application you filled online is not processed. To process the request you need to e-mail the form back to domreg@internic.net.
A small charge is associated with registering a domain name. New registrations cost $100, and the registration is good for two years. Subsequent renewals are $50/year. If you don't pay your registration fee, the top-level domain servers will forget about your domain, and no one will be able to reach you. That's power!
Once your domain is approved, you are ready to set up your own domain name server. Approvals can take anywhere from one day to three weeks depending on load and other things.
To run a domain name server, you will need to install BIND. The source for BIND can be found at http://www.isc.org/isc or from ftp://ftp.vix.com/pub/bind/release/bind.tar.gz. For your convenience, a copy has been included on the CD-ROM that accompanies this book.
Once you obtain the source, you should follow the compilation instructions in the package. The official release at the time I grabbed my copy was 4.9.3. As usual, running outdated software creates a source of security problems. If your system comes with an older version of the software, you really should upgrade. The installation steps are as follows:
- FTP the source.
- Unpack the source.
- Change your directory to the BIND distribution directory.
- Create a build directory by issuing a make DST=build links.
- Cd to the build directory you just created.
- Set the appropriate options, if any, in conf/options.h.
- Configure the makefile for settings appropriate for your machine/os. This is easily done by removing the # from all the lines under the section that describes your operating system. If you have special locations where you want the binaries installed, set the DEST (for destination) variable to a path more palatable to you.
To avoid confusion, keep the default paths and rename your distribution copies of named and nslookup that came with your system to named.dist and nslookup.dist, respectively. This way you can keep your original binaries in case you run into trouble and you need to revert to something known to work.
- Type make to build everything.
If compilation fails, you may want to add ./bin to your path. You can do this simply enough on a csh by issuing the following:
set path = (./bin $path)
After make builds everything, you will want to verify which files are going to be installed. Issue a make -n install to see where make wants to install everything. This will list all the commands that are going to be executed by the install target without actually running them. You should then backup or rename any remaining files that are going to be replaced with an .orig extension.
If you are running SunOS 4.1.x, NetBSD-1 or Solaris 2.x, you can integrate the new client-side resolver library into your system shared libraries. This will upgrade all dynamically linked programs to use the new libraries instead of the old ones. For more information, read the information included in the shres directory of the BIND release.
If the installation proceeded properly, BIND should now be installed in your system. Congratulations!
DNS Configuration Files
The first step in setting up your DNS database is to convert your existing /etc/hosts file into its equivalent DNS format. To configure DNS you'll need to create a few databases and startup files. I placed everything in /usr/local/named with the exception of /etc/named.boot. named looks by default for its boot file in /etc/named.boot. To get things running, you'll need to create a few files (replace DOMAIN with your domain name, and IP with your network IP address):
- /etc/named.boot
- /usr/local/named/db.DOMAIN
- /usr/local/named/db.IP
- /usr/local/named/db.127.0.0
The db files: db.DOMAIN and db.IP, contain hostname-to-IP and IP-to-hostname translation tables, respectively. The basic components for these files are
- SOA Record
- NS Records
- Address and Alias Records
- PTR Records
While the structure of the db files is similar, there's one significant difference. I mentioned that the db.DOMAIN maps hosts to IP addresses. Data in DNS is indexed by name, including addresses. Mapping from an IP address to a hostname (the reverse) actually turns out to be a little more difficult. Given the current design, searching for a name would require searching the entire database until a match was found. Obviously, this would not be very efficient. To solve the problem, the designers of DNS created a special domain that uses IP addresses as names. This domain is called the IN-ADDR.ARPA domain.
Reverse Lookups: IP to Hostname, the IN-ADDR.ARPA Domain
The IN-ADDR.ARPA domain has four levels of subdomains. Each level represents one of the octets in a 32-bit IP address. Each level has 256 (from 0 to 255) subdomains, each named after each possible octet value.
The IN-ADDR.ARPA domain has enough room for every host on the Internet given the current 32-bit (four-octet) IP representation.
Remember the domain names are read from the bottom up, like host.domain.dom. Because of this, IN-ADDR.ARPA domains are represented with their IP addresses in reverse.
If your host IP address is 1.2.3.4, your host number is 4, and the IN-ADDR.ARPA name would be written as 4.3.2.1.IN-ADDR.ARPA.
This way the name server can group, organize, and retrieve IP-to-hostname queries as efficiently as the regular name-based queries.
Before you proceed, you may want to create your db.DOMAIN and db.IP files. I created mine in /usr/local/named and renamed DOMAIN and IP to the name of my domain and network IP, respectively (db.ACCESSLINK.COM and db.204.95.222).
SOA Record
A start of authority (SOA) resource record is the first entry in a db file. This record indicates that the name server is authoritative. An authoritative name server provides the most accurate and reliable information about a domain. A single SOA record is required at the beginning of each db.DOMAIN and db.IP file.
A SOA record looks like this:
domain.dom IN SOA hostname.domain.dom. root.domain.dom. {
1 ; Serial ID
10800 ; Record Refresh in seconds (3 hours)
3600 ; Retry after one hour (in seconds)
604800 ; Expire after one week (in seconds)
86400 ) ; Minimum TTL (Time to live) of one day
On your db.DOMAIN file, replace domain.dom with the name of your domain (for example, acme.com).
IN stands for Internet. There are other possible values, but for this example, and more likely for your needs, this will fit the bill.
Replace hostname.domain.dom. with the fully qualified domain name of the host where you are creating this data. Note that the trailing period needs to be there.
Replace root.domain.dom. with a valid e-mail address for the person managing your DNS. Replace the @ sign on the e-mail address with a period. Again, note that there's a trailing period after the address.
The serial id of the record is very important. Any time you update any of the database files, you must increment this number. If for some reason you forget to increment the serial id, the secondary name servers won't realize that you have modified the database and won't update their information. Secondary name servers use this number to determine if their copy of the db file is up-to-date. A good strategy is to put the current date in a format such as YYYYMMDDR where
If the secondary server repeatedly fails to contact the primary after the expire interval, data on the database is going to be considered stale, and the secondary server will stop responding to requests for the domain.
The TTL value specifies how long resource records served from this file will remain in a caching server's cache. After the TTL expires, the server will have to requery your server for information about your domain.
NS Records
Next, you need to specify the names of domain name servers in your domain. You do this by using name server (NS) resource records. They look like this:
"domain.dom IN NS hostname.domain.dom."
All domain name servers that you list here will be designated authoritative for the domain. Replace domain.dom and hostname.domain.dom. with the name of your domain (don't forget the period) and the fully qualified domain name of the domain name server. An example of this is as follows:
ACCESSLINK.COM IN NS ns1.ACCESSLINK.COM.
ACCESSLINK.COM IN NS ns2.ACCESSLINK.COM.
Address and Alias Records
Now you'll create name-to-address mappings. Resource records for address and Alias records look like this:
; Host Addresses
localhost IN A 127.0.0.1
router IN A 204.95.222.100
www IN A 204.95.222.200
hydrogen IN A 204.95.222.1
lithium IN A 204.95.222.3
; Aliases
mailhost IN CNAME hydrogen.ACCESSLINK.COM.
ns1 IN CNAME hydrogen.ACCESSLINK.COM.
ns2 IN CNAME lithium.ACCESSLINK.COM.
ftp IN CNAME hydrogen.ACCESSLINK.COM.
The db.IP File
The db.IP file stores an IP-to-name lookup table. The main difference between the two is that instead of listing regular IP addresses, it uses the funny IN-ADDR.ARPA notation.
Like the db.DOMAIN file, the db.IP file has a SOA Record. The only difference is that the name of the domain is specified as IN-ADDR.ARPA domain notation:
222.95.204.IN-ADDR.ARPA IN SOA hostname.domain.dom. root.domain.dom. {
1 ; Serial ID
10800 ; Record Refresh in seconds (3 hours)
3600 ; Retry after one hour (in seconds)
604800 ; Expire after one week (in seconds)
86400 ) ; Minimum TTL (Time to live) of one day
The db.IP file also lists NS resource records. These are also specified in IN-ADDR.ARPA domain notation:
1.222.95.204.IN-ADDR.ARPA. IN NS ns1.ACCESSLINK.COM.
3.222.95.204.IN-ADDR.ARPA. IN NS ns2.ACCESSLINK.COM.
In addition, the db.IP file also lists its reverse version of the Address Records (IN A entries, in your db.DOMAIN file). These are called PTR Records.
PTR Records
The DNS resource records used for IP-to-name mappings are called Pointer (PTR) Records. There's one record for each IP address on your network. All IP addresses are specified using the IN-ADDR.ARPA domain notation:
1.222.95.204 IN PTR hydrogen.ACCESSLINK.COM.
3.222.95.204 IN PTR lithium.ACCESSLINK.COM.
100.222.95.204 IN PTR router.ACCESSLINK.COM.
200.222.95.204 IN PTR www.ACCESSLINK.COM.
The Loopback Interface
In addition to the db.DOMAIN and db.IP files, the server will need a db.IP file for the loopback interface. This is a special IP address that hosts use to route traffic to themselves. The address of the loopback network is (almost always) 127.0.0.0, and the host number for the localhost is 127.0.0.1.
The file is pretty standard. If you copy your other db.IP file, you'll only need to delete all PTR records and insert a new PTR record pointing to the localhost, the last line in the following listing:
222.95.204.IN-ADDR.ARPA IN SOA hostname.domain.dom. root.ACCESSLINK.COM. {
1 ; Serial ID
10800 ; Record Refresh in seconds (3 hours)
3600 ; Retry after one hour (in seconds)
604800 ; Expire after one week (in seconds)
86400 ) ; Minimum TTL (Time to live) of one day
; Name Servers
;
1.222.95.204.IN-ADDR.ARPA. IN NS ns1.ACCESSLINK.COM.
3.222.95.204.IN-ADDR.ARPA. IN NS ns2.ACCESSLINK.COM.
;
; localhost
1.0.0.127.IN-ADDR.ARPA. IN PTR localhost.
The named.root File
In addition to knowing all the gory details about your network, DNS needs to know how to contact the name servers for the root domain. Your BIND release should have included a copy of this file. If not, you can find a copy at
ftp://ftp.rs.internic.net/domain/named.root
This file is only used at startup. After named is able to contact the top-level name servers, it updates its internal information.
The /etc/named.boot File
If you are following at the terminal, you have now developed and downloaded all the files you need to get named going. However, you need to create a configuration file that can tell named where to find all its files. If you have followed my example and created your files in /usr/local/named, your boot file will look like this:
directory /usr/local/named
primary domain.dom db.DOMAIN
primary xxx.xxx.xxx.IN-ADDR.ARPA db.IP
primary 0.0.127.IN-ADDR.ARPA db.127.0.0
cache . named.root
Here's how my boot file looks after I replace the placeholders with the naming convention described earlier:
directory /usr/local/named
primary ACCESSLINK.COM db.ACCESSLINK
primary 222.95.204.IN-ADDR.ARPA db.204.95.222
primary 0.0.127.IN-ADDR.ARPA db.127.0.0
cache . named.root
Starting named
To start the name server as root on a terminal, type:
/etc/named.
If you located your boot file somewhere other than in the default /etc/named.boot, you can tell named where to look for it by using the -b flag, /etc/named -b pathtobootfile.
If there were any errors in your configuration files, named will log an error using syslog, and if the error is bad enough, it will quit. To see where named will log any errors, type in the following:
grep daemon /etc/syslog.conf
This will print the name of the file where named will log errors to. In my case, the result of this command is /usr/adm/messages, yours may be /usr/var/messages or something like that. Please note that by default named logs a restart message whenever it starts. It is very likely that if you made a typo or forgot to enter a field, named will complain by saying ...Unknown type:... or ...unknown field 'foo'.... Look for the offending line and compare it to the examples.
Testing Your Name Server
If named started correctly, then you can use nslookup to see if it is serving information correctly. If your machine was not on the Internet before, chances are that you have not set the domainname for it. On some systems this is done with the hostname command. Other systems use domainname. To check if your system has been set up, type hostname (or domainname) on a terminal.
If the domainname has not been set up, the superuser can set it up by giving the command an argument:
domainname domain.dom
Replace domain.dom with the name of your domain. You may want this to happen automatically at the system startup time. Just include the line domainname domain.dom on your /etc/rc.local or equivalent system startup file.
To see if it is all working correctly, type the following:
% nslookup lithium
Server: ns1.ACCESSLINK.COM
Address: 204.95.222.1
Name: lithium.ACCESSLINK.COM
Address: 204.95.222.3
You may want to also see if you can use nslookup to find a machine out of your network::
% nslookup www.next.com
Server: ns1.ACCESSLINK.COM
Address: 204.95.222.1
Non-authoritative answer:
Name: ftp.next.com
Address: 129.18.1.3
Aliases: www.next.com
A final test involves querying a remote name server to see if it can obtain your address. You can do this easily with nslookup by specifying the address of the remote name server after the host you are looking for:
% nslookup lithium.accesslink.com beta.inc.net
Server: ns1.inc.net
Address: 204.95.160.2
Name: lithium.ACCESSLINK.COM
Address: 204.95.222.3
If it works, then you'll probably want named to be started up when you reboot the computer. You can accomplish this easily enough by putting an entry such as the following in your /etc/rc.local file:
if -f [/etc/named.boot]; then
echo "starting named …"
/usr/etc/named
fi
The preceding script will check to see if your /etc/named.boot file exists in the /etc directory. If it does, then name server is started.
If when you Telnet or FTP to other machines, you find that there's a long lag (10 seconds or so) between connecting and receiving a login prompt, more than likely your reverse DNS lookups are not working properly. It is possible that your ISP, to whom your IP addresses are registered, is not providing the proper information. Have them check their DNS information.
Congratulations, your primary name server is now running.
Configuring a Secondary Name Server
Configuring a secondary name server is a lot less work. You should strongly consider running a secondary name server on your site or have someone else run one for you. It is even better have someone else run DNS for you at another site, and remember to add the address of that name server to your domain registration form. This will ensure that if your name servers go down, your network doesn't grid to a halt.
To build a secondary name server, follow these steps:
- Install the software as you did for your primary name server.
- Copy /etc/named.boot to the other computer's /etc directory.
- Copy /usr/local/named/named.root and db.127.0.0 to /usr/local/named/ on the other computer.
- Edit the file /etc/named.boot on your secondary server. Change all instances of primary to secondary, with the exception of the line referring to db.127.0.0. This name server is also primary for the loopback address; it is its own loopback address.
And that's it. To finish, copy the startup commands you put in your primary server's rc.local file.
On starting the secondary server, it will transfer a copy of all the databases to the /usr/local/named directory.
Configuring Hosts in Your Network to Use the Name Server
Before any client in your network can use your name server, you'll need to create the /etc/resolv.conf file. This file contains a list of all the name servers in your network and the order they are queried in. The basic format is as follows:
search domainname...
nameserver ipaddress
Ours looks like this:
seach accesslink.com
nameserver 204.95.222.1
nameserver 204.95.222.2
Summary
Because the intention of this appendix was to provide you with a basic reference and to help you quickly set up DNS, the information is by no means complete. DNS is not particularly complicated. However, complex networks require complex DNS setups, and as should be expected, powerful software cannot be mastered in an appendix; DNS keeps the Internet running. This appendix gets your DNS running; it is not an absolute reference on the subject. For more information, I would suggest that you read the documentation included with your release of DNS. If you FTPed the package, it contains excellent documentation as well as a frequently asked questions (FAQ) list. As for printed information, the following might be helpful.
DNS and BIND, by Paul Albitz & Cricket Liu, is published by O'Reilly and Associates, Inc. ISBN 1-56592-010-4. It's a great book. However, some of the information is a little out-of-date.
For an excellent UNIX system administration book, the best this author has ever seen, check out UNIX System Administration Handbook, now in its second edition. While it is impossible to cover UNIX in one volume, it does an excellent job of explaining the art of UNIX system administration. It has more than enough detail to get you going. This book was written by Evi Nemeth, Garth Snyder, Scott Seebass, and Trent R. Hein. It is published by Prentice Hall, ISBN 0-13-151051-7.
Page Top
| 
