 |
Click this button to go to the index for this section. |
bind_intro(7)
NAME
bind_intro - Introduction to the Berkeley Internet Name Domain (BIND)
service
DESCRIPTION
The Berkeley Internet Name Domain (BIND) service is a host name and address
lookup service for the Internet network. The BIND service is based on the
client-server model. It allows client systems to obtain host names and
addresses from BIND servers. In the DIGITAL UNIX system, BIND is used to
distribute only the hosts database.
Note
Depending on which naming services your Local Area Network (LAN) is
running, the hosts file can be located in the /etc, /var/yp/src, or
/etc/namedb/src directory.
You can use the BIND service to replace or supplement the host table
mapping provided by the local /etc/hosts file or Network Information
Service (NIS). The BIND service is composed of a software interface
(called the resolver) and a server.
The software interface consists of a group of routines that reside in the
/usr/lib/libc.a C library. The resolver exchanges query packets with a
BIND server.
All BIND servers run a name server daemon, named, which services queries on
a given network port. The standard port for User Datagram Protocol (UDP)
and Transmission Control Protocol (TCP) is specified in the /etc/services
file.
To understand how the BIND service works, you must be familiar with
Internet Protocol (IP) addressing.
The BIND service divides the Internet into a hierarchy of domains, similar
to a tree structure. Each domain is given a label. The name of the domain
is the concatenation of all the labels of the domains, from the root to the
current domain, listed from right to left and separated by periods (.).
For example, xyz.abc.com. A label must be unique within its domain.
The entire BIND Internet hierarchy is partitioned into several zones, each
starting at a domain and extending down to the leaf domains (individual
host names), or to domains where other zones start. A zone is a
subdivision of a domain and is a discrete, nonoverlapping entity. Each
zone is an area of authority for which a master server is responsible.
(See the section on Master Servers for a discussion of master servers.)
Zones usually represent an administrative boundary.
The BIND hierarchy in the United States contains seven top-level domains
shown in the following table:
________________________________________________________________
Domain Description
________________________________________________________________
arpa The Arpanet (gradually being phased out)
com Commercial institutions
edu Educational institutions
gov U.S. government
mil Military organizations
net Network-type organizations, such as network centers
centers, consortia, and information centers
org Miscellaneous organizations, such as professional
societies and similar nonprofit organizations
________________________________________________________________
In addition to these, there are several top-level domains for individual
countries. Contact InterNIC for more information about them. See Network
Administration for information on contacting InterNIC.
Assuming a host name in the domain cities.dec.com is chicago, the following
is the fully qualified domain name for that host:
chicago.cities.dec.com.
In this example, com is the top level domain, cities.dec.com is a subdomain
of com, and chicago is a host name. The zone, dec.com, has one primary
server and consists of multiple domains.
The period (.) at the end of the domain name indicates that the domain name
is fully qualified and is absolute. No further BIND extensions are to be
appended to the name.
BIND Servers
A BIND server is a system running the named daemon. BIND servers perform
the following functions:
· Store information locally
· Process requests that cannot be satisfied locally
· Forward queries about top-level domains
Servers maintain databases containing information about host names and
addresses. When client systems need information they do not have, they ask
the servers for it.
The BIND service has the following types of servers:
· Master
--
Root
--
Primary
--
Secondary
· Caching
· Slave
Master Servers
A master server is the authority for a zone, and maintains the zone's BIND
databases. A zone can include one or more domains. BIND has the following
types of master servers:
· A root server knows about all the top-level domains on the Internet
network. From these top-level domains, information is gathered about
hosts on subdomains. The root servers, for example, do not necessarily
know about the cities.dec.com subdomain. But they do know which server
to contact for the information.
If a client requests information about a host in a domain other than
its own, any server (other than a slave) can pass along the request to
a root server.
The following seven root servers currently exist in the continental
United States:
--
ns.nasa.gov.
--
nic.ddn.mil.
--
a.isi.edu.
--
gunter-adam.af.mil.
--
aos.brl.mil.
--
terp.umd.edu.
--
c.nyser.net.
The period (.) at the end of each root server name indicates that this
is the absolute domain name and that no BIND name extensions are to be
appended. Without the period, the server name is relative to the
current domain.
InterNIC determines the root servers.
See Network Administration for information on contacting InterNIC.
· A primary server loads its database from a file on disk. This server
can also delegate to other servers in its zone the authority to answer
queries for its domain space.
· A secondary server receives its authority and its database from the
primary server. When a secondary server boots, it loads the data for
the zone from a backup file, if possible (assuming you configured your
BIND service this way). It then consults a primary server to check
that the database is still up to date.
After the secondary server is running, it polls the primary server
every five minutes (by default) to be sure that its database
information is current. If the database files have been modified, it
updates its information. Because of the polling interval, a lag could
occur between the time when changes are made in the primary server's
databases and when they are pulled over to the secondary servers.
A server can be a master server for multiple domains. It can be the
primary server for some domains and a secondary server for others. It is
recommended that each BIND domain have at least two master servers: one
primary and one or more secondary servers. The secondary servers act as
backup servers in the event that the primary server fails, is overloaded,
or is down.
Caching Servers
All servers cache the information they receive for use until the data
expires. However, caching servers have no authority for any zone, so they
have no databases to maintain. These servers service BIND queries by
asking other servers who have authority, such as a master server, for the
information. Caching servers store the information until it expires. The
expiration is based on a time-to-live (ttl) field, which is attached to the
data when the caching server receives it.
Slave Servers
Slave servers do not have access to the Internet, so they cannot interact
directly with root servers to get information that is not in their local
cache. Instead, slave servers use forwarders, which can be either primary
or secondary servers, to resolve their queries. A slave server forwards
queries to the list of forwarders specified in its boot file, until the
list is exhausted or the query is satisfied. (See the section on
Forwarders for information about forwarders.)
As the slave servers request new information from forwarders, they
accumulate it in their cache. Slave servers do not receive complete zones
from primary servers, like secondary servers do, but accumulate data per
request.
Forwarders
A forwarder can be any BIND server (primary, secondary, or caching) that
has Internet access. Forwarders are able to obtain information not held in
their local caches from servers in other zones. Any server can make use of
forwarders.
Slave servers do not have access to the Internet nor do they have a large
local cache. Therefore, they rely on forwarders to resolve host name and
address queries. The configuration files on the slave servers define which
systems the slaves access as forwarders.
Because forwarders receive many requests from slave servers, they tend to
have a larger local cache than slave servers. All the hosts on the domain
benefit from this larger cache, which reduces the total number of queries
from that site to servers outside the domain. For this reason, a LAN is
typically set up so all systems forward their requests to a caching server.
BIND Clients
A BIND client is any system that uses the BIND service to resolve host
names and addresses. BIND clients make queries, but they never resolve
them locally. Instead, BIND servers resolve the clients' requests.
BIND clients do not run the named daemon. Instead, BIND clients have a
resolver file, /etc/resolv.conf, which tells the resolver the IP address of
the BIND servers that can service the client's BIND requests. The
following is an example of a /etc/resolv.conf file:
domain dec.com
nameserver 128.11.22.33
nameserver 128.11.22.44
Resolving Queries
The following steps describe how a BIND query is resolved. In this case,
an application on a slave server generates a query for a host name and
address. The process is similar for other servers.
1. An application requests host name resolution and uses the
gethostbyname library routine.
2. The gethostbyname library routine looks at the /etc/svc.conf file to
determine which service to use to resolve the query. If the routine
has local BIND, it looks at the /etc/hosts file first. If the request
cannot be answered, the routine calls the BIND resolver code, which
checks the /etc/resolv.conf file for the name of a server. In this
case, it is localhost.
3. The library routine contacts the slave server and asks for the host
name and address.
4. The slave server receives a query for a host name resolution and
checks its own cache to see if it can answer the query. If it cannot,
it forwards the query to the servers listed as forwarders in its BIND
boot file (the default is named.boot) one at a time, until the query
is resolved or the list is exhausted.
5. The server returns the result to the slave server, even if the result
shows the resolution was unsuccessful. If the result is successful,
the slave server adds the information to its local cache.
6. The slave server passes the result back to the gethostbyname library
routine.
7. The gethostbyname library routine passes the result back to the
application.
RELATED INFORMATION
Commands: bindconfig(8X), bindsetup(8), named(8), nslookup(8), svcsetup(8)
Files: resolv.conf(4), svc.conf(4)
Network Administration