 |
» |
|
|
|
|  | |
The Berkeley Internet Name Domain (BIND) is the Berkeley
implementation of DNS (Domain Name System). It is a database, distributed
across the Internet, which maps host names to internet addresses, maps
internet addresses to host names, and facilitates internet mail routing. This
section describes the components of BIND and how they work. It contains
the following sections: Benefits of Using BIND | |
This section explains the advantages of BIND over the other name services
available on HP-UX (NIS and the /etc/hosts file). You store information for only the hosts in your local domain. You configure
the hosts in your own domain, and you configure the addresses of name servers
in other domains. Your name server can contact these other name servers when it
fails to resolve a host name from its local database. If you use the /etc/hosts file or the NIS hosts database for host name
resolution, you must explicitly configure every host you might need to contact. You can store all host information on one host. You configure one machine as
a name server, and all other machines query the name server. Information must
be kept up to date on only one host instead of many. If you use the /etc/hosts file for host name resolution, you must keep an
up-to-date copy of it on every host in your domain. If you use NIS, you must
make sure that your NIS slave servers receive regular updates from the master
server. You can contact almost any host on the Internet. Because BIND spans
network boundaries, you can locate almost any host on the network by starting at
the root server and working down. An NIS server can serve only the hosts on its local LAN. NIS clients send out
broadcasts to locate and bind to NIS servers, and broadcasts do not cross
network boundaries. Each NIS server must be able to answer all the host name
queries from the hosts on its local LAN.
Many people use BIND for host information and NIS for other configuration
information, like the passwd and group databases. NIS has the advantage
that it can easily manage many different types of information that would
otherwise have to be maintained separately on each host. However, NIS does
not easily span networks, so the hosts in an NIS domain do not have access
to information from other domains. The DNS Name Space | |
The DNS name space is a hierarchical organization of all the hosts on the
internet. It is a tree structure, like the structure of UNIX directories. The root
of the hierarchy is represented by a dot (.). Underneath the root, top-level
internet domains include com (commercial businesses), edu (educational
institutions), gov (government agencies), mil (military and defence), net
(network-related organizations), and org (other organizations). Under each
top-level domain are subdomains. For example, the edu domain has
subdomains like purdue, ukans, and berkeley. In turn, each subdomain
contains other subdomains. For example, the purdue subdomain could
contain econ, cs, and biol subdomains. At the deepest level of the hierarchy, the "leaves" of the name space are
hosts. A fully qualified host name begins with the host's canonical
name and continues with a list of the subdomains in the path from the host to
the root of the name space. For example, the fully qualified host name of
host arthur in the cs domain at Purdue University would be arthur.cs.purdue.edu. Figure 4-1 “Structure of the DNS Name Space” shows the hierarchical structure of the DNS name space. How BIND Works | |
When a user who is logged into host venus in the nmt.edu domain types
the following command, the following events occur: The telnet process calls gethostbyname to get the internet address of indigo.div.inc.com. The gethostbyname routine invokes the BIND resolver, a set of routines for
querying name servers. The resolver constructs a query and sends it to a name server. If the local host is
not running a name server, it should have a file called /etc/resolv.conf,
which contains one or more internet addresses for name servers that serve the
local domain. If the local host does not have an /etc/resolv.conf file, the
resolver sends the query to the local name server. The name server daemon, named, receives the query from the resolver. Since the
name server has information about only the hosts in its local domain (nmt.edu),
it cannot answer the query with the information in its local database. The local name server queries a root name server to find the address of indigo.div.inc.com. A root name server serves the root domain. It
typically stores information about hosts and name servers one and two levels
below the root. If the root name server cannot resolve the host name, it returns the address of a
name server for the inc.com domain. The local name server queries the server for the inc.com domain to find the
address of indigo.div.inc.com. The name server for the inc.com domain may not have information for the div.inc.com domain. If it does not, it returns the address of a name server for
the div.inc.com domain. The local name server queries the server for the div.inc.com domain to find
the address of indigo.div.inc.com. The server for the div.inc.com domain returns the address of indigo.div.inc.com to the local name server. The local name server passes host indigo's address to the resolver, which
passes it to gethostbyname, which returns it to the telnet process.
The local name server in the nmt.edu domain caches the addresses of
remote name servers, so the next time a local user needs the address of a host
in the inc.com domain, the local name server sends its query directly to the
name server for inc.com instead of querying the root name server. How BIND Resolves Host Names | |
Because complete domain names can be cumbersome to type, BIND allows
you to type host names that are not fully qualified (that is, that do not contain
every label from the host to the root and end with a dot). This section
describes how the name server resolves host names. | | | |  | NOTE: It is always correct to use a name that contains all of the labels from the host to the
root and does not end with a dot. Names that end in a dot are not allowed in the
following places: mail addresses, the hostname command, and network-related
configuration files. Names that contain all of the name components and end in a dot
are used with commands like nslookup, ping, and telnet, to facilitate the
lookup process. | | | | |
If the input host name ends with a dot, BIND looks it up as is, without appending
any domains to it. If the input host name contains at least the number of dots specified by the ndots
option in the /etc/resolv.conf file,
BIND looks it up as is, before appending any domains to it. (The default value of ndots is 1, so if the input
host name contains at least one dot, it will be looked up as is before any domains
are appended to it.) If the input host name consists of a single component (contains no dots), and you
have set up a host aliases file, BIND looks in your aliases file to translate the alias
to a fully qualified host name. You can create a host aliases file for frequently typed host names, like the
following example file: The alias (the first field on each line) must be all one word, with no dots. To use the file, set the HOSTALIASES environment variable to the name of the
file, as in the following example: If the input host name does not end with a dot, BIND looks it up with domain
names appended to it. The domain names that BIND appends to it can be
configured in four places: The LOCALDOMAIN environment variable. The hostname command. The search option in the /etc/resolv.conf file. The domain option in the /etc/resolv.conf file.
If a user has set the LOCALDOMAIN variable, as in the following example, the LOCALDOMAIN variable overrides the hostname and any search or domain option in /etc/resolv.conf,
for BIND requests made within the context of the user's shell environment. The input host name is looked up in each of the domains in the variable, in the order they are listed. If the local hostname is set to a fully qualified domain name, and the search
and domain options are not specified in /etc/resolv.conf, the input host
name is looked up in the domain configured in the fully qualified hostname. The search option specifies a list of domains to search.
Following is an example of a search option in /etc/resolv.conf: You can set the search option to any list of domains,
but the first domain in the list must be the domain of the local host. BIND looks up host names in each domain, in the order they are listed. BIND uses the search option only if the LOCALDOMAIN variable is not set. The domain option specifies the local domain.
If you use the domain option, BIND will search only the specified domain to resolve host names. BIND uses
the domain option for host name lookups only if the LOCALDOMAIN variable
is not set and the search option is not specified. (Do not use the domain and search options together in the same /etc/resolv.conf file.
If you do, the one that appears last in the file will be used, and any previous ones will be
ignored.)
For more information on how BIND resolves host names, type man 5
hostname or man 4 resolver at the HP-UX prompt. |
Printable version
