Overview of the BIND Name Service

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 or 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 or NIS+ for other configuration information, like the passwd and group databases. NIS or 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 defense), 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 3-1 “Structure of the DNS Name Space” shows the hierarchical structure of the DNS name space.

Figure 3-1 Structure of the DNS Name Space

DNS Change Notification

Starting with BIND 8.1.2, DNS notification, also known as DNS notify is supported. This allows master servers to inform slaves that new information is ready. The original DNS protocol required slave servers (secondaries) to poll a master at an interval defined in the Start of Authority (SOA) record. At these defined intervals, the slave checked the SOA record on the master to see whether the serial number had changed. If a change was detected, the slave initiated a zone transfer. The disadvantage of this approach is that slaves might not get new information in a timely fashion.

DNS notify provides a way for a master to notify servers that a zone transfer is necessary. The DNS notify operating users a new DNS opcode. Currently, DNS Notify can be used only when a zone's SOA record changes. The notification is sent to every host listed as a name server in nameserver records for the zone. In addition BIND 8.1.2 lets you list additional servers to accommodate stealth servers that may not be listed in any name server records. You can use the zone statement to list these additional servers in the configuration file, /etc/named.conf.

When a slave server receives the notify packet, it sends an acknowledgment. It then behaves as if its refresh timer for that zone has expired, going through the same process used at expiration time - first retrieving the SOA record from the master, then initiating a zone transfer if the record has changed.

The DNS Notify feature is enabled in the master server by default. In some environments, the master server in a zone might be an 8.1.2 server with DNS notify enabled, while the other servers in the zone are 4.x servers (without the DNS notify feature). In such environments, whenever the master changes and sends a notification to the other servers, the 4.x servers will ignore this notification as they do not understand the notify protocol.

How BIND Works

When a user who is logged into host venus in the nmt.edu domain types the following command,

telnet indigo.div.inc.com

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.

Round-Robin Address Rotation

Round-robin address rotation can provide an inexpensive load-balancing solution. A virtual host name can map to the addresses of multiple systems. When the name server supplies address information for a virtual host name, it rotates the returned order of the addresses. This provides a mechanism for load-balancing network traffic to each host.

For example, the virtual host name rainbow is created for three systems named red, blue, and green. The host name rainbow maps to the IP addresses of red, blue, and green. When applications/services call gethostbyname()for rainbow, an array of IP addresses is returned and applications typically use the first IP address in the array. With round-robin address rotation, the name server rotates the order of the addresses returned, so connections to rainbow will be balanced among red, blue, and green.

Round-robin address cycling can also affect multi-homed hosts (hosts with multiple IP addresses). However, if a multi-homed host belongs to multiple subnets, the address records will be sorted by the resolver to favor the addresses to which the querying host is directly connected, or those that correspond to the networks in the querying host's sortlist (specified in /etc/named.boot).

Also note that for multi-homed hosts with multiple interfaces attached to the same subnet, no load sharing is done for outbound traffic. The transport software will select an interface for outbound traffic according to the target IP address and use that interface consistently, regardless of the interfaces on which it is receiving inbound traffic from the target IP address.

Round-robin address cycling is enabled by default. However, with BIND 4.9.3, if you do not want to use this feature, you can disable it by adding the following entry to the named boot file, /etc/named.boot: options no-round-robin.

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:
john zircon.chem.purdue.edu melody fermata.music.purdue.edu
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:
export HOSTALIASES=/home/andrea/myaliases
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,
export LOCALDOMAIN="nmt.edu div.inc.com inc.com"
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:
search div.inc.com inc.com
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.