bind_intro(7)						 Miscellaneous Information Manual					     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 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 Pro-
       tocol (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  sepa-
       rated 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 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
       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
       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 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
       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 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 over-
       loaded, 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
       searching 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 mas-
       ter  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
       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 for-
       warders 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
       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 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 con-
       tacts 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.

RELATED INFORMATION

       Commands: bindconfig(8), named(8), nslookup(8), svcsetup(8).

       Files: named.conf(4), resolv.conf(4), svc.conf(4).

       Network Administration delim off

																     bind_intro(7)