bind_intro man page on DigitalUNIX

Printed from

bind_intro(7)							 bind_intro(7)

       bind_intro  -  Introduction to the Berkeley Internet Name Domain (BIND)

       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.


       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,	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
		( 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‐

       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 is chicago, the fol‐
       lowing  is  the	fully	qualified   domain   name   for	  that	 host:

       In  this example, com is the top level domain, is a sub‐
       domain of com, and chicago is a host name. The zone,,  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


       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
       subdomain.  But they do know which server to contact for	 the  informa‐

       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‐

       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

   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

   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 nameserver nameserver

   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.

       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


List of man pages available for DigitalUNIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net