*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> bind_intro (7)              



NAME    [Toc]    [Back]

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

DESCRIPTION    [Toc]    [Back]

       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

       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


       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

       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

       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

   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   nameserver

   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.

SEE ALSO    [Toc]    [Back]

       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

[ Back ]
 Similar pages
Name OS Title
bind_manual_setup Tru64 Describes how to manually set up the Berkeley Internet Name Domain (BIND) service on your network.
whois OpenBSD Internet domain name and network number directory service
whois FreeBSD Internet domain name and network number directory service
rpcb_rmtcall NetBSD library routines for RPC bind service
rpcbind IRIX library routines for RPC bind service
rpcb_getaddr FreeBSD library routines for RPC bind service
rpcbind NetBSD library routines for RPC bind service
rpcb_getaddr NetBSD library routines for RPC bind service
rpcb_gettime FreeBSD library routines for RPC bind service
rpcb_unset NetBSD library routines for RPC bind service
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service