bind_intro(7)bind_intro(7)NAMEbind_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 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, sim‐
ilar 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 (indi‐
vidual 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 cen‐
ters centers, consortia, and information centers
org Miscellaneous organizations, such as profes‐
sional societies and similar nonprofit organiza‐
tions
──────────────────────────────────────────────────────────
In addition to these, there are several top-level domains for individ‐
ual 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 fol‐
lowing 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 sub‐
domain 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 per‐
form 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
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 informa‐
tion.
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 periodi‐
cally update the root servers from ARIN. See Network Administration:
Connections for information on contacting ARIN.
Slave Servers
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 appropri‐
ately.
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
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 search‐
ing the master DNS database, the master server queries the local server
for information about machines in the subzone.
Caching-only Servers
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 informa‐
tion 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
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 speci‐
fied in its configuration (boot) file, until the list is exhausted or
the query is satisfied. As forward-only servers request new informa‐
tion 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 for‐
ward 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. An appli‐
cation 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.
SEE ALSO
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)