The Berkeley Internet Name Domain (BIND) service is a distributed database lookup service that allows you to distribute the hosts database networkwide. A network running BIND does not have to be connected to the Internet; if it is, however, BIND allows systems on your network to resolve the names and addresses of hosts on the Internet.
This chapter describes the BIND environment, how to plan for BIND, how to configure your system for BIND, and how to manage BIND servers and clients.
For introductory information on BIND, see bind_intro(7).
In the BIND environment, systems can have the following roles:
This system runs the named daemon, answers requests from clients and other servers, caches information, and distributes the databases to secondary servers.
This system runs the named daemon, provides backup for the primary server, answers requests from clients and other servers, and caches information.
This system runs the named daemon and answers queries from other servers and clients from its authoritative data and cache data. If the information is not present, it forwards queries to a list of systems called forwarders specified in its named.boot file. The queries are forwarded to each forwarder system until the list is exhausted or the query is satisfied. Slave servers store the information they receive until the data expires.
BIND runs on each system in your network. You must decide what role each system will play within the BIND environment that you are creating. For each domain, select one host to be the primary server; there can be only one primary server for each domain. Select one or more hosts to be secondary, slave, and caching servers. The rest of the hosts should run as BIND clients.
Figure 6-1 shows a domain in which there are two servers, one on each subnet, and multiple clients. The Host A server has primary authority for the zone and maintains the database files for the zone. The Host B server has secondary authority for the zone, obtaining a copy of the zone database from Host A and answering queries from clients.
Figure 6-2 shows a domain in which there are three zones: mktg.corp.com, eng.corp.com, and acct.corp.com. Host B has primary authority for zone mktg.corp.com and secondary authority for each of the other two zones. Host C has primary authority for zone eng.corp.com and secondary authority for each of the other two zones. Host D has primary authority for zone acct.corp.com and secondary authority for each of the other two zones. Host A is both a router and a caching server. As a caching server, it caches information it receives from queries out of the parent domain.
Appendix A contains a worksheet that you can use to record the information that you need to provide to configure BIND. If you are viewing this manual online, you can use the print feature to print a copy of this part of the worksheet.
Figure 6-3 shows Part 5 of the Configuration Worksheet. The following sections explain the information you need to record in Part 5 of the worksheet.
For a server that is a secondary authority for information about a zone, the pathname of the file that is to contain zone information obtained from the primary server. This is optional, but useful when the server is restarted. Instead of waiting to obtain information from a primary server, which might not be available, the secondary can restart using the information in the data file.
Digital recommends that you use the BIND Configuration application of the Common Desktop Environment (CDE) Application Manager for configuring BIND on systems with graphics capabilities. You can configure the following systems:
See bindconfig(8X) for more information on the BIND Configuration application.
To invoke the BIND Configuration application, log in as root and do the following:
Note
You must first set up the primary server; then, you can configure the other systems in any order.
To exit the BIND Configuration application, choose File then Exit.
Note
For systems without graphics capabilities, you can use the bindsetup utility. See bindsetup(8) for more information.
The BIND Configuration application also has an extensive online help system. You can use it instead of the instructions in this section to configure BIND on your system.
To configure a server, do the following:
Alternatively, you can run the svcsetup script to customize service order selection. See Section 6.4 and svcsetup(8) for information on modifying the svc.conf file.
If you do not want to start the named daemon now, use the following command to start the daemon manually in a terminal window after you are finished with the BIND Configuration application:
#
/sbin/init.d/named start
You can also modify your server configuration. See the BindConfig application online help and bindconfig(8X) for more information.
If your system is a primary authority for information about a zone or domain and you want to create the database from an existing hosts file, do the following:
To create the source file from which the hosts database will be created, update the primary server's local /etc/hosts file and then copy it into the /etc/namedb/src directory. Note that if a system, host1 for example, is in your BIND domain and is running BIND but is not included in the primary server's hosts database, other systems in the domain cannot obtain the IP address of host1.
Example 6-1 is a list of sample /etc/hosts file entries.
127.0.0.1 localhost 120.105.5.1 host1 120.105.5.2 host2 120.105.5.3 host3 120.105.5.4 host4 120.105.5.5 host5
Note
Note that the file that you copy into the /etc/namedb/src directory must be named hosts.
#
cd /etc/namedb
#
make hosts
To configure a BIND client, do the following:
The addresses are placed in the /etc/resolv.conf file, where the resolver uses them to determine the IP addresses of name servers it should query.
Alternatively, you can run the svcsetup script to customize service order selection. See Section 6.4 and svcsetup(8) for information on modifying the svc.conf file.
You can also modify your client configuration. See the BindConfig application online help and bindconfig(8X) for more information.
You can modify the /etc/svc.conf file without running the BIND Configuration application. To do this, you invoke the svcsetup script using the following command:
#
/usr/sbin/svcsetup
Once invoked, use the following steps to edit the /etc/svc.conf file:
Option 2 corresponds to the hosts database.
Listing local first means that the local /etc/hosts file is searched first for the requested information. If the information is not found locally, then BIND servers, NIS servers, or both, are queried, depending on which options you choose.
Note
Digital recommends that local be the first service that your system queries for all databases, regardless of what services you are running.
Choose option 3, 4, 5, or 6 to configure the svc.conf file so that BIND serves hosts information.
The svcsetup script indicates that it is updating the /etc/svc.conf file. When svcsetup is finished updating the file, notifies you and returns you to the system prompt (#).
Occasionally you may need to update the BIND data files; for example, you may need to add a host to the data files. To do this, use the bindconfig application as follows:
Alternatively, to update a data file, you can do the following:
#
make hosts
#
make all
After you edit the hosts file and enter the make command, the BIND conversion scripts (which are in the /etc/namedb/bin directory) do the following for you:
Note
If you have manually entered mail exchanger (MX) records in the hosts.db file, these records are lost. You will have to edit the hosts.db file and add the MX records.
The BIND database conversion scripts also increment the serial number field of the start of authority (SOA) entry in the database file. When the secondary servers poll the primary server and see that the serial number field has changed, they know to refresh their data.
The process is the same for all of the valid files in the primary server's /etc/namedb/src directory.
Scripts are provided to create the following databases: hosts.db and hosts.rev.
There are several ways that you can obtain information about host names, IP addresses, and user information from a system using the BIND service. The following sections provide an introduction to two commands: nslookup and whois.
You can use the nslookup command to noninteractively and interactively query the BIND service for information about hosts on the local, as well as remote, domains. You can also find information about BIND resource records such as mail exchanger (MX), name server (NS), and so forth.
For a noninteractive query, use the following syntax:
nslookup hostname
The output is the server name and address and the host name and address.
For an interactive query, use the following syntax:
nslookup
The output is the default server name and address and the nslookup prompt, a greater than sign (>).
For example, to obtain information about MX, you need to query nslookup interactively, supplying a valid domain name. The following example shows how to find who takes mail for the domain corp.com:
#
nslookup
Default Server: localhost Address: 127.0.0.1
Server: localhost Address: 127.0.0.1 findmx.corp.com preference = 100, mail exchanger = gateway.corp.com gateway.corp.com inet address = 128.54.54.79> [Ctrl/D]
A good way to learn how to use the nslookup command is to experiment with it. To obtain a list of the interactive nslookup command options, enter a question mark (?) at the nslookup prompt. For further information, see nslookup(1).
The Network Information Center (NIC) whois service allows you to access the following information about a domain:
For example, to use the NIC whois service to obtain information about a domain named digital.com, use the whois command and specify the domain name as follows:
#
whois digital.com
Digital Equipment Corporation (DIGITAL2-DOM) 250 University Avenue Palo Alto, CA 94301-1616 Domain Name: DIGITAL.COM
.
.
.
The InterNIC Registration Services Host ONLY contains Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information.