#ToC Index Previous

Apache Server Survival Guide asgxe.htm

Previous Page TOC

_________________________________________________________________

* DNS: the Domain Name System

* What Is DNS?
+ Top-Level Domain Designations in the United States
+ Geographical Domain Designations
* How named Works
* Running Your Own Domain Name Server
* DNS Configuration Files
+ Reverse Lookups: IP to Hostname, the IN-ADDR.ARPA Domain
+ SOA Record
+ NS Records
+ Address and Alias Records
* The db.IP File
+ PTR Records
+ The Loopback Interface
+ The named.root File
+ The /etc/named.boot File
* Starting named
* Testing Your Name Server
* Configuring a Secondary Name Server
* Configuring Hosts in Your Network to Use the Name Server
* Summary
_________________________________________________________________

DNS and BIND Primer

The Internet is a vast collection of networks. Before a computer can

talk to another, it needs an address. This address typically takes the
form of a name because names are easier for people to remember.
Computers, on the other hand, prefer numbers.

Without the Domain Name System (DNS), your computer would need to have
a huge address book of names and addresses that included every
computer on the Internet. If you wanted to send e-mail to a user at
host.foo.com, the system would have to figure out that you wanted to
talk to the machine at address 1.2.3.4 and do its thing.

This approach has several problems, including the following:

* Your address book would always have to be up-to-date. An old
address book would not have entries that were recently added; or
worse, if a host changed addresses, you would no longer be able to
communicate with that host.
* Your address book would have to include every address for every
system that you wanted to communicate with.
* No two hosts could share the same name.

What a mess! Believe it or not, this was the way that it was until
1984. A large host table (HOSTS.TXT) was maintained in one server at
the Stanford Research Institute Network Information Center (the NIC).
With more and more networks going online, it b ecame almost impossible
to keep the host list up-to-date. Before the list would be downloaded
by all hosts, someone would have introduced a change that would
require downloading yet another new list!

Vestiges of this address book are still used by your system to look up
hosts in your local network- the /etc/hosts file.

DNS: the Domain Name System

A new system developed by Paul Mockapetris of USC's Information

Sciences Institute was proposed as a replacement for HOSTS.TXT.
Mockapetris's system addressed the network-load and consistency
problems that the infamous HOSTS.TXT system had. Mockapetris 's system
boasted the following capabilities:
1. The elimination of the single repository for host information
would eliminate network traffic problems caused by network
administrators downloading an updated version of the HOSTS.TXT
file.
2. It would also introduce a name-based domain system, where each
domain would have its own internal context; thus allowing for
hosts in different domains to have the same name.
3. And most importantly, it would allow for delegation of host
information management. The responsibility for managing each
network and each network's subdomain was handed to the local
administrator for the zone in question, which made the task of
keepin g information up-to-date much more manageable. Local host
information could be made available globally through the
client/server nature of the system, insuring that each request was
answered with reliable data from an authoritative source.

The original DNS system was described in the 1983 Request for Comment
(RFC) documents 882 and 883. Both have been updated and superseded in
1987 by RFCs 1034 and 1035, and again in 1990 by RFCs 1101 and 1183,
which implement the current specification o f the DNS. In software,
DNS is implemented on UNIX systems as the Berkeley Internet Name
Domain (BIND) system. BIND is shipped in almost every UNIX box.

The current BIND release is composed of several programs including:

named, named-xfer, named.restart, named.reload, ndc, nslookup, and the
resolver libraries. The resolver libraries provide routines for
programs to query DNS name servers, so you can de sign programs that
make use of the DNS. Here's a list of the entire distribution and what
each does:

dig A domain information groper; a command line tool that can be used
to gather information from a DNS server. It has zillions of options.
dnsquery A program that uses the BIND resolver library calls to query
name servers.
host A program that does reverse DNS lookups. Instead of specifying a
hostname to find its IP address, you supply the IP, and host returns
the hostname.
named-xfer A tool for doing zone transfers. Usually this program is
called by other software. It can also be used to debug a zone transfer
problem. But more than likely you won't use it at all.
named The Internet domain name server daemon, and the focus of my
attention in this appendix.
named.reload A convenience program to restart the named daemon and
force the server to reload and update its database files, if
necessary. This program uses a hangup (SIGHUP) signal.
 named.restart A convenience program to restart the named daemon and to
force the server to reload and update its database files, if
necessary. This program kills the name server by using a kill
(SIGKILL) signal and then starts a new server.
ndc A cool program that allows you to send various signals to the
named daemon. This command allows you to monitor the status of the
server as well as to force database reloads. It has many other
options.

What Is DNS?

DNS is a distributed database. By distributed I mean that no single

repository contains complete information regarding other domains. A
program called name server is responsible for implementing the server
portion of the equation. When a machine is configured to use DNS,
client programs making calls to the gethostbyname() and
gethostbyaddr() library routines use the resolver library. This
library allows them to query a name server across a network instead of
looking up information in the /etc/host file.

The structure of the Internet domain system is similar to that of the

UNIX file system. There's a root domain and a series of directories
called top-level domains. In turn, top-level domains are composed of
other subdirectories or subdomains. Ea ch domain or subdomain is
separated by a dot (.). Each second-level domain can have up to 26
characters. Subdomain labels can have up to 63 characters in length.
The root domain is null, meaning there's no label, and is usually
represented by empty quotes (""). Unlike a file path, domain names are
written and read from the bottom up:

host.subdomain.domain.topleveldomain

The host label is the name of the machine.

The subdomain label is a subdivision of a domain. Typically subdomains

are used to create logical groupings of machines to match some
internal organization criteria. Don't be surprised if you ever see
more than one subdomain. As a matter of fact , subdomains are common
under geographical domain designations.

The domain is the domain name of the organization, usually matching

the organization's name, such as IBM, APPLE, and NEXT.

The topleveldomain is a classification of the domain.

Top-Level Domain Designations in the United States

COM Reserved for commercial organizations such as Digital Equipment

Corporation (digital.com) or Hewlett-Packard Corporation (hp.com).
EDU Used by educational organizations such as the University of
Wisconsin (uw.edu).
GOV Used by U.S. government organizations and agencies such as NASA
(nasa.gov) or the Federal Bureau of Investigation (fbi.gov).
MIL Reserved for use by the U.S. Armed Forces such as the Air Force
(af.mil) or the Navy (navy.mil).
NET Reserved for networking organizations and leased line providers
such as Internet Connect (inc.net), a regional Internet service
provider in Wisconsin.
ORG Reserved for noncommercial organizations such as the popular
Electronic Frontier Foundation (eff.org).
INT International organizations such as NATO (nato.int)
ARPA This is a historical domain that was used during transition from
the host tables to the DNS. Organizations and networks originally
found under this domain have since migrated to their appropriate
locations on one of the previous subdomains.

Fig. E.1. The U.S. Top-Level Domains. Domains are shown in ovals. A
machine is shown as a box

This statement is actually not the full truth. The original

classifications originated before the Internet became an international
entity. Given its incredible and unexpected success everywhere,
additional classifications emerged-geographical desi gnations.

Geographical Domain Designations

Geographical designations follow the ISO 3166 standard, which

establishes a two-letter abbreviation for country names. The only
inconsistency is Great Britain, which goes by UK instead of GB. The
United States also has a geographical designation, US, w hich is not
yet as widely used as the others. The U.S. geographical domain is
supposed to accommodate U.S. state and local government agencies,
schools, libraries, museums, and individuals.

Geographical domains are at the same hierarchical level as the

standard U.S. domains and are properly registered with the NIC.
However, administration of those domains is handled by different
organizations in various countries.

The subdomains for the U.S. domain follow postal abbreviation's

conventions for the states and territories. Each state can then
further subdomain according to an individual city name, locale, plus
the hostname.

In addition to the state subdomains, there are two other categories:

FED for agencies of the federal government and DNI for Distributed
National Institutes or organizations that span state, regional, and
other organization boundaries that are national in scope.

Within each state's subdomain there are locality names. These can be
cities, counties, or local names. The locality can be a CI for city or
CO for county:

hostname.CI.locality.state.US -> pear.CI.CEDARBURG.WI.US

hostname.CO.locality.state.US -> apple.CO.MILWAUKEE.WI.US

A state subdomain, groups the following subdomains:

K12 For public schools. Private schools add the PVT name,
schoolname.PVT.K12.state.US.
CC For community colleges: collegename.CC.state.US.
TEC For technical colleges: collegename.TEC.state.US.
LIB For libraries: library.LIB.state.US.
STATE For state government agencies: agency.STATE.state.US.
GEN For General Independent Entity. For anything that doesn't fit in
the other categories.
Fig. E.2. The U.S domain. Notice that other countries and standard U.S
top level domains share the same level.

Table E.1 lists all the top-level domains known at the time of this
writing. However, this may be outdated by now. This table is a
reflection on the dynamics of our world: New countries are formed, and
new countries join the Internet c ommunity.

Table E.1. Geographical domains.

Domain Country or Organization

AD Andorra
AE United Arab Emirates
AF Afghanistan
AG Antigua and Barbuda
AI Anguilla
AL Albania
AM Armenia
AN Netherlands Antilles
AO Angola
AQ Antarctica
AR Argentina
AS American Samoa
AT Austria
AU Australia
AW Aruba
AZ Azerbaijan
BA Bosnia and Herzegovina
BB Barbados
BD Bangladesh
BE Belgium
BF Burkina Faso
BG Bulgaria
BH Bahrain
BI Burundi
BJ Benin
BM Bermuda
BN Brunei Darussalam
BO Bolivia
BR Brazil
BS Bahamas
BT Bhutan
BV Bouvet Island
BW Botswana
BY Belarus
BZ Belize
CA Canada
CC Cocos (Keeling) Islands
CF Central African Republic
CG Congo
CH Switzerland
CI Cote D'Ivoire (Ivory Coast)
CK Cook Islands
CL Chile
CM Cameroon
CN China
CO Colombia
CR Costa Rica
CS Czechoslovakia (former)
CU Cuba
CV Cape Verde
CX Christmas Island
CY Cyprus
CZ Czech Republic
DE Germany
DJ Djibouti
DK Denmark
DM Dominica
DO Dominican Republic
DZ Algeria
EC Ecuador
EE Estonia
EG Egypt
EH Western Sahara
ER Eritrea
ES Spain
ET Ethiopia
FI Finland
FJ Fiji
FK Falkland Islands (Malvinas)
FM Micronesia
FO Faroe Islands
FR France
FX France, Metropolitan
GA Gabon
GD Grenada
GE Georgia
GF French Guiana
GH Ghana
GI Gibraltar
GL Greenland
GM Gambia
GN Guinea
GP Guadeloupe
GQ Equatorial Guinea
GR Greece
GS S. Georgia and S. Sandwich Isls.
GT Guatemala
GU Guam
GW Guinea-Bissau
GY Guyana
HK Hong Kong
HM Heard and McDonald Islands
HN Honduras
HR Croatia (Hrvatska)
HT Haiti
HU Hungary
ID Indonesia
IE Ireland
IL Israel
IN India
IO British Indian Ocean Territory
IQ Iraq
IR Iran
IS Iceland
IT Italy
JM Jamaica
JO Jordan
JP Japan
KE Kenya
KG Kyrgyzstan
KH Cambodia
KI Kiribati
KM Comoros
KN Saint Kitts and Nevis
KP Korea (North)
KR Korea (South)
KW Kuwait
KY Cayman Islands
KZ Kazakhstan
LA Laos
LB Lebanon
LC Saint Lucia
LI Liechtenstein
LK Sri Lanka
LR Liberia
LS Lesotho
LT Lithuania
LU Luxembourg
LV Latvia
LY Libya
MA Morocco
MC Monaco
MD Moldova
MG Madagascar
MH Marshall Islands
MK Macedonia
ML Mali
MM Myanmar
MN Mongolia
MO Macau
MP Northern Mariana Islands
MQ Martinique
MR Mauritania
MS Montserrat
MT Malta
MU Mauritius
MV Maldives
MW Malawi
MX Mexico
MY Malaysia
MZ Mozambique
NA Namibia
NC New Caledonia
NE Niger
NF Norfolk Island
NG Nigeria
NI Nicaragua
NL Netherlands
NO Norway
NP Nepal
NR Nauru
NT Neutral Zone
NU Niue
NZ New Zealand (Aotearoa)
OM Oman
PA Panama
PE Peru
PF French Polynesia
PG Papua New Guinea
PH Philippines
PK Pakistan
PL Poland
PM St. Pierre and Miquelon
PN Pitcairn
PR Puerto Rico
PT Portugal
PW Palau
PY Paraguay
QA Qatar
RE Reunion
RO Romania
RU Russian Federation
RW Rwanda
SA Saudi Arabia
SB Solomon Islands
SC Seychelles
SD Sudan
SE Sweden
SG Singapore
SH St. Helena
SI Slovenia
SJ Svalbard and Jan Mayen Islands
SK Slovak Republic
SL Sierra Leone
SM San Marino
SN Senegal
SO Somalia
SR Suriname
ST Sao Tome and Principe
SU USSR (former)
SV El Salvador
SY Syria
SZ Swaziland
TC Turks and Caicos Islands
TD Chad
TF French Southern Territories
TG Togo
TH Thailand
TJ Tajikistan
TK Tokelau
TM Turkmenistan
TN Tunisia
TO Tonga
TP East Timor
TR Turkey
TT Trinidad and Tobago
TV Tuvalu
TW Taiwan
TZ Tanzania
UA Ukraine
UG Uganda
UK United Kingdom
UM U.S. Minor Outlying Islands
US United States
UY Uruguay
UZ Uzbekistan
VA Vatican City State (Holy See)
VC Saint Vincent and the Grenadines
VE Venezuela
VG Virgin Islands (British)
VI Virgin Islands (U.S.)
VN Vietnam
VU Vanuatu
WF Wallis and Futuna Islands
WS Samoa
YE Yemen
YT Mayotte
YU Yugoslavia
ZA South Africa
ZM Zambia
ZR Zaire
ZW Zimbabwe
COM U.S. commercial
EDU U.S. educational
GOV U.S. government
INT International
MIL U.S. military
NET Network
ORG Nonprofit organization
ARPA Old style Arpanet
NATO NATO field

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 eff ectively 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 nonauthori tative 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 o f 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:

1. Figure out where in the domain hierarchy your organization falls.
2. Find a domain name that is not in use by another site in that
domain hierarchy.
3. If you are not on the Internet yet, find someone that will host a
temporary name server for you.
4. Fill out an application.
5. 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 f ind 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 dur ing 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 do mreg@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 abo ut 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/re lease/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 wit h an older
version of the software, you really should upgrade. The installation
steps are as follows:
1. FTP the source.
2. Unpack the source.
3. Change your directory to the BIND distribution directory.
4. Create a build directory by issuing a make DST=build links.
5. Cd to the build directory you just created.
6. Set the appropriate options, if any, in conf/options.h.
7. 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 inst alled,
set the DEST (for destination) variable to a path more palatable
to you.
______________________________________________________________

NOTE: 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.
______________________________________________________________

1. 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 with out 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 o ld 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 except ion 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) a ctually 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 cr eated 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 a nd 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 recor d 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

YYYY is the year: 1996.

MM is the month: 06.

DD is the day: 30.

R is the number of the revision (in case you modify the file more than
 once on the same day): 1.

The refresh interval tells the secondary server how often to check for
updates on this file.

The retry interval tells the secondary server how long to wait before
trying to reach the primary server, if the initial attempt failed.

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, an d 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 i t 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.
______________________________________________________________
 NOTE: 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 wh om
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:

1. Install the software as you did for your primary name server.
2. Copy /etc/named.boot to the other computer's /etc directory.
3. Copy /usr/local/named/named.root and db.127.0.0 to
/usr/local/named/ on the other computer.
4. 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 docum entation 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 expla ining 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.

Previous Page Page Top TOC