Man page of bind_intro
Section: Environments, Tables, and Troff Macros (7)
Return to Main Contents
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
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
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
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:
|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
for information on contacting InterNIC.
Assuming a host name in the domain cities.dec.com
the following is the fully qualified domain name for that host:
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
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.
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:
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
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
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
InterNIC determines the root servers.
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
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.
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 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.
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.
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:
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 slave server and asks for the host name and
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.
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.
The slave server passes the result back to the gethostbyname
The gethostbyname library routine passes the result back
to the application.
Commands: bindconfig(8X), bindsetup(8),
named(8), nslookup(8), svcsetup(8)
Files: resolv.conf(4), svc.conf(4)
- BIND Servers
- Master Servers
- Caching Servers
- Slave Servers
- BIND Clients
- Resolving Queries
- RELATED INFORMATION
This document was created by
using the manual pages.
Time: 02:40:18 GMT, October 02, 2010