bind_intro - Introduction to the Berkeley Internet Name
Domain (BIND) service
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 Tru64 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 eight
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
int International (Treaty) Organizations. This
domain currently holds the IPv6 subdomain
(ip6.int) for reverse AAAA IPv6 records.
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 the American Registry
for Internet Numbers (ARIN) for more information about
them. See Network Administration: Connections for information
on contacting ARIN.
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 [Toc] [Back]
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
Slave Stub Caching-only Forward-only
Note
Documentation for BIND prior to Version 8.1.1 referred to
the master server as a primary server and the slave server
as a secondary server. Though the terminology has changed,
master and slave servers are still referred to as having
primary and secondary authority, respectively, for zones.
Master Servers [Toc] [Back]
A master server is the authority for a zone, and maintains
the zone's BIND databases. A zone can include one or more
domains.
A master 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.
One type of master server is a root server, which 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 forward-only
server) can pass along the request to a root server.
The list of root servers changes periodically, and you
should periodically update the root servers from ARIN.
See Network Administration: Connections for information on
contacting ARIN.
Slave Servers [Toc] [Back]
A slave server receives its authority and its database
from the master server. When a slave 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 master server to check that the
database is still up to date.
Once the slave server is running, it waits for the master
server to indicate that the database files have been
updated. When a change occurs, the slave server updates
its local database files appropriately.
A server can be the master server for some domains and a
slave server for others. It is recommended that each BIND
domain have at least one master and one or more slave
servers. The slave servers act as backup servers in the
event that the master server fails, is overloaded, or is
down.
Stub Servers [Toc] [Back]
A stub server is like a slave server, except that it does
not retain any information in its configuration files
about the machines in a specified subzone. It is implemented
to allow the administrator for a given subzone to
change the configuration of the subzone without affecting
the configuration file on the master server.
The master server becomes a stub server for the subzone by
delegating authority for it to a server local to the subzone.
Instead of searching the master DNS database, the
master server queries the local server for information
about machines in the subzone.
Caching-only Servers [Toc] [Back]
All servers cache the information they receive for use
until the data expires. However, caching-only 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-only 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.
Forward-only Servers [Toc] [Back]
Forward-only 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,
they use forwarders, which can be either master or slave
servers, to resolve their queries. These forwarders are
able to obtain information not held in their local caches
from servers in other zones, including root servers.
A forward-only server forwards queries to the list of forwarders
specified in its configuration (boot) file, until
the list is exhausted or the query is satisfied. As forward-only
servers request new information from forwarders,
they accumulate it in their cache. Forward-only servers do
not receive complete zones from master servers, like slave
servers do; they accumulate data per request.
Because forwarders receive many requests from forward-only
servers, they tend to have a larger local cache than forward-only
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 [Toc] [Back]
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 [Toc] [Back]
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. An application requests host name resolution
and uses the gethostbyname library routine. 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. The library routine contacts the
forward-only server and asks for the host name and
address. The forward-only 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 configuration
file (the default is named.conf) one at a time, until
the query is resolved or the list is exhausted. The
server returns the result to the forward-only 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. The forward-only server passes
the result back to the gethostbyname library routine. The
gethostbyname library routine passes the result back to
the application.
Commands: bindconfig(8), named(8), nslookup(8), svcsetup(8)
Files: named.conf(4), resolv.conf(4), svc.conf(4)
Networking: bind_manual_setup(7)
Network Administration: Connections
Network Administration: Services
bind_intro(7)
[ Back ] |
