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 became 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:
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.
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.
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 keeping 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 of 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 design 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. Each 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.
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 designations.
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, which 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:
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 community.
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 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.
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.DOMAINand db.IPfiles. 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
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, 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:
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:
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:
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:
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.
SHOPPING
JOB BANK
REFERENCE
JOURNAL
COMMUNITY
ABOUT US
