| Previous | Contents | Index |
The DIGITAL TCP/IP Services for OpenVMS software supports the Berkeley Internet Name Domain (BIND) service, which is a popular implementation of the Domain Name Service (DNS). BIND has been ported to many platforms including UNIX, Windows NT, and OpenVMS. DIGITAL TCP/IP Services for OpenVMS Version 5.0 implements the Internet Software Consortium's (ISC) BIND 8.1.2.
Before you add BIND servers to your network, it is useful to understand basic BIND service concepts as they apply to the TCP/IP Services for OpenVMS product. This chapter describes:
DNS has a hierarchical, distributed namespace that makes it easy for you to remember and locate the many hosts located throughout the internet. Since computers remember and locate the same hosts through a numerical address, computers need a method for converting the host name to a numerical address.
BIND is a lookup service that maps host names to IP addresses and IP addresses to host names in response to queries from other BIND servers and clients in the network. BIND can also provide information on available mail servers and well-known services for a domain.
Based on a client/server model, BIND servers maintain databases of host names, IP addresses, mail records, text records, and other network objects. When client systems require this information, they query the servers.
The Internet Network Information Center (InterNIC) provides the Internet community with services for domain registration, directories and databases, and other information. See Appendix A for information about network and domain registration.
3.2 BIND Service Components
The BIND service contains two parts: the BIND resolver and the BIND
server.
The Internet namespace is based on a hierarchical tree structure. Each node on the tree is referred to as a domain or a subdomain. A domain is an administrative entity that allows for the decentralized management of host names, addresses, and user information. Domains can refer to an administrative point on the namespace tree or a specific host. A domain is identified by a domain name and includes the namespace at or below the domain name. For example, in Figure 3-1 the domain widget.com includes the following domains:
A subdomain is a domain that is part of a larger domain. You can consider every domain in the namespace below the root domain to be a subdomain. You can also refer to any subdomain as a domain.
Figure 3-1 illustrates a typical Internet domain hierarchy.
Figure 3-1 Internet Domain Hierarchy
Table 3-1 lists some of the commonly used top-level domains.
| Domain | Description |
|---|---|
| arpa | The Arpanet (gradually being phased out) |
| ca | Canada |
| com | Commercial institutions |
| edu | Educational institutions |
| gov | United States federal government departments or agencies |
| mil | United States military organizations |
| net | Network-type organizations, such as network service centers, consortia, and information centers |
| org | Miscellaneous organizations, such as professional societies and similar nonprofit organizations |
| us | United States |
Countries can register with the InterNIC as top-level domains provided
they name themselves after a two-letter country code listed in the
international standard ISO-3166. If a country code is identical to a
state code that the U.S. Postal Service uses, the country can request a
three-letter code.
3.3.2 Domain Administrator Role
Typically, each domain has a domain administrator responsible for coordinating and managing the domain. The domain administrator registers a second-level or lower domain by interacting with the domain administrator in the next higher level domain.
The domain administrator's duties include:
The domain administrator furnishes users with access to names and
name-related information both inside and outside the local domain.
3.4 Domain Names
The InterNIC assigns names for all top-level domains as well as domains directly below the top-level domains. Individuals are responsible for assigning lower-level domains and host names.
Each domain (or subdomain) has a label. For example, the label for the top-level domain for commercial organizations is com. A label is unique within its parent domain.
The concatenation of all the domain labels from the top-level domain to the lowest-level domains listed from right to left and separated by dots is called a fully qualified domain name. For example, the domain name for a subdomain within the com domain, would be abc.com; abc is the label for the ABC company's subdomain, and com is the label for the commercial domain. This structure allows administration and data maintenance to be delegated down the hierarchical tree.
The term domain name is sometimes used when referring to a specific domain label. The name of the root domain of the namespace is a dot (.) . |
There are two types of domain names: the fully qualified name and the relative name.
chicago.cities.dec.com. |
Hosts and resources often have more than one name that identifies them.
The BIND service supports the use of canonical names and aliases. A
canonical name is a host's or resource's official name, while other
names that identify the same host or resource are considered aliases or
nicknames. Nicknames are useful if a host changes any part of its
canonical name (for example, host name or domain). People who continue
to use the nickname can still reach the right host or resource.
3.4.3 Domain Name Format
Domain and host labels have the following format:
Characters in the range of 128 through 255 are subject to having their high bit cleared because some software does not preserve the high bit. |
Although label names can contain up to 63 characters, it is best to choose names that are 12 characters or less because the canonical (fully qualified) domain names are easier to keep track of if they are short. The sum of all the label characters and label lengths is limited to 255.
Domain names are not case sensitive. However, the case of entered names is preserved whenever possible. |
Read from right to left for the following fully qualified domain name:
euro.sales.widget.com.
For management reasons, a domain can be divided into zones which are discrete, non-overlapping subsets of the domain. A zone usually represents an administrative or geographic boundary and authority for the zone may or may not be delegated to another responsible group or person. Each zone starts at a designated level in the domain name tree and extends down to the leaf domains (individual host names), or to that point in the tree where authority has been delegated to another domain.
A common zone is a second-level domain abc.com, for example. Many second-level domains divide their zones into smaller zones. For example, a university might divide their domain namespace into zones based on departments. A company might divide their domain namespace into zones based on branch offices or internal divisions. Authority for the zone is generally delegated to the department or branch office. The department or branch office then has the responsibility for maintaining the zone data.
All the data for the zone is stored on the master server in zone files.
3.5.1 Zone Hierarchy Example
Figure 3-2 shows the hierarchy of the internet, two top-level domains, and some of the major zones. For example, in Figure 3-2, everything below com is in the com top-level domain; the zones are within the shaded boxes. The host names are depicted by an x.
Figure 3-2 Hierarchy of BIND Zones and Domains on the Internet
When a zone is very large and difficult to manage, authority for a portion of the zone can be delegated to another server and the responsibility for maintaining the zone information is also delegated.
For example, in Figure 3-2 the edu
zone contains many educational organizations. Each organization is
delegated the authority for managing their portion of the edu zone, thereby creating a subzone. In the
example, mit.edu and berkeley.edu are subzones of the edu zone and each organization has the
responsibility for maintaining the zone information and the master and
slave servers for their respective zones.
3.6 Reverse Domain
The internet has a special domain used for locating gateways and
supporting internet address-to-host name lookups. The mapping of
internet addresses to domain names is called reverse translation. The
special domain for reverse translation is the IN-ADDR.ARPA domain.
3.7 BIND Server Functions
If a network consists of relatively few hosts, host name to IP address translations can be accomplished by using a centralized hosts database file.
As soon as a network connects to another network or the number of hosts grows large, there needs to be a more robust method of performing host name to IP address translation. In particular, when a network is part of the worldwide Internet, no single database can keep track of all addressing information. A considerable number of hosts and network domains are added, changed, and deleted every day.
BIND uses several different types of name servers to ensure that all queries are resolved quickly and efficiently:
When a client makes a query, a name server can be in one of three possible states:
The following sections discuss the different types of name servers and
their primary responsibilities in the distributed environment of BIND
and DNS.
3.7.1 Root Name Servers
Root name servers are the master name servers for the top-level domains of the Internet root zone. If they are not the authority for a zone, they know how to find out who is the authority.
If a nonroot server receives a request for a name not within its zone, the server starts name resolution at the root zone and accesses the root servers to get the needed information.
The InterNIC determines root servers for the top-level domain. Table 3-2 lists valid root servers.
| Current Server Name | Former Server |
|---|---|
| A.ROOT_SERVERS.NET | ns.internic.net |
| B.ROOT_SERVERS.NET | ns1.isi.edu |
| C.ROOT_SERVERS.NET | c.psi.net |
| D.ROOT_SERVERS.NET | terp.umd.edu |
| E.ROOT_SERVERS.NET | ns.nasa.gov |
| F.ROOT_SERVERS.NET | ns.isc.org |
| G.ROOT_SERVERS.NET | ns.nic.ddn.mil |
| H.ROOT_SERVERS.NET | aos.arl.army.mil |
| I.ROOT_SERVERS.NET | nic.nordu.net |
| J.ROOT_SERVERS.NET | |
| K.ROOT_SERVERS.NET | |
| L.ROOT_SERVERS.NET | |
| M.ROOT_SERVERS.NET |
These servers change from time to time, so the servers listed may not be the current list. You can obtain the up-to-date list by:
These servers know about all the top-level DNS domains on the Internet.
You must know about these servers when making queries about hosts
outside of your local domain. The host names and internet addresses of
these machines change periodically. Therefore, check with the InterNIC
periodically to obtain changes and store them in the hints file of the
BIND name servers (usually called TCPIP$ROOT.HINT on a TCP/IP Services system).
3.7.2 Master Name Server
There are two types of master servers: a primary master name server and a slave name server (also called a secondary master name server).
The primary master server is the primary authority for the zone. The primary master server has complete information about the zone. This information is stored in its database files. If network information changes, those changes are captured in the master server's database files.
A server can be a master server for more than one zone, acting as the primary master name server for some zones and a slave name server for others.
It is possible to have more than one master server; however,
maintaining two sets of database files requires making the same changes
to both sets of files. A more efficient solution is to have one master
server and one or more slave servers that obtain their zone information
from the master server.
3.7.3 Slave Name Server
A slave name server is an administrative convenience providing
redundancy of information and sharing the load of the primary name
server. A slave name server receives its authority and zone data from a
primary master name server.
Once running, a slave name server periodically checks with the primary master name server for zone changes. If the slave's serial number is less than the master's serial number, the slave requests a zone transfer.
The slave name servers poll the master server at predetermined
intervals specified in the zone database files. A time lapse between
changing the master server's databases and the slave name servers
requesting the update may exist.
3.7.4 Forwarder Servers
Often it is beneficial to limit the traffic to the Internet. The reason may be a slow internet connection, or you are being charged by the number of packets.
Funneling DNS internet queries through one name server can reduce the number of queries going out to the Internet. A name server that performs this function is a forwarder. The forwarder handles all off-site queries and in doing so builds up a cache of information, which reduces the number of queries that the forwarder needs to make to satisfy a query.
Forwarder servers have access to the Internet and are able to obtain information regarding other servers not currently found in local caches. Because a forwarder server can receive requests from several slave servers, it can acquire a larger local cache than a slave server. All hosts in the domain have more information locally available because the forwarder servers have a large cache. This means that the server sends fewer queries from that site to root servers on networks outside the internet.
Figure 3-3 shows the relationship among root, primary master, slave, forwarder servers, and clients.
Figure 3-3 Relationship of Master/Forwarder Server and Slave Servers
All servers cache the information they receive for use until the data expires. The length of time a server caches the information is based on a time-to-live (TTL) field attached to the data the server receives.
Caching-only servers have no authority for any zone, and thus do not have complete information for any zone. Their database contains information acquired in the process of finding answers to clients' queries.
| Previous | Next | Contents | Index |