_N_a_m_e _S_e_r_v_e_r _O_p_e_r_a_t_i_o_n_s _G_u_i_d_e _f_o_r _B_I_N_D _R_e_l_e_a_s_e _4._3 Kevin J. Dunlap* Computer Systems Research Group Computer Science Division Department of Electrical Engineering and Computer Sciences University of California Berkeley CA 94720 _1. _I_n_t_r_o_d_u_c_t_i_o_n The Berkeley Internet Name Domain (BIND) Server implements the DARPA Internet name server for the UNIX|- operating system. A name server is a network service that enables clients to name resources or objects and share this information with other objects in the network. This in effect is a distributed data base system for objects in a computer network. BIND is fully intergrated into 4.3BSD network programs for use in storing and retrieving host names and address. The system adminis- trator can configure the system to use BIND as a replace- ment to the original host table lookup of information in the network hosts file /_e_t_c/_h_o_s_t_s. The default confi- guration for 4.3BSD uses BIND. _2. _B_u_i_l_d_i_n_g _A _S_y_s_t_e_m _w_i_t_h _a _N_a_m_e _S_e_r_v_e_r BIND is comprised of two parts. One is the user interface called the _r_e_s_o_l_v_e_r which consists of a group of routines that reside in the C library /_l_i_b/_l_i_b_c._a. Second is the actual server called _n_a_m_e_d. This is a dae- mon that runs in the background and services queries on a ____________________ 9 * The author is an employee of Digital Equipment Corporation's Ultrix Engineering Advanced Development Group and is on loan to CSRG. Ultrix is a trademark of Digital Equipment Corporation. |-UNIX is a Trademark of AT&T Bell Laboratories 9 SMM:11-2 Name Server Operations Guide for BIND given network port. The standard port for UDP and TCP is specified in /_e_t_c/_s_e_r_v_i_c_e_s. _2._1. _R_e_s_o_l_v_e_r _R_o_u_t_i_n_e_s _i_n _l_i_b_c When building your 4.3BSD system you may either build the C library to use the name server resolver routines or use the host table lookup routines to do host name and address resolution. The default resolver for 4.3BSD uses the name server. Building the C library to use the name server changes the way _g_e_t_h_o_s_t_b_y_n_a_m_e(3N), _g_e_t_h_o_s_t_b_y_a_d_d_r(3N), and _s_e_t_h_o_s_t_e_n_t(3N) do their functions. The name server renders _g_e_t_h_o_s_t_e_n_t(3N) obsolete, since it has no concept of a next line in the database. These library calls are built with the resolver routines needed to query the name server. The _r_e_s_o_l_v_e_r is comprised of a few routines that build query packets and exchange them with the name server. Before building the C library, set the variable _H_O_S_T_L_O_O_K_U_P equal to _n_a_m_e_d in /_u_s_r/_s_r_c/_l_i_b/_l_i_b_c/_M_a_k_e_f_i_l_e. You then make and install the C library and compiler and then compile the rest of the 4.3BSD system. For more information see sec- tion 6.6 of ``Installing and Operating 4.3BSD on the VAX|=''. _2._2. _T_h_e _N_a_m_e _S_e_r_v_i_c_e The basic function of the name server is to pro- vide information about network objects by answering queries. The specifications for this name server are defined in RFC882, RFC883, RFC973 and RFC974. These documents can be found in /_u_s_r/_s_r_c/_e_t_c/_n_a_m_e_d/_d_o_c in 4.3BSD or _f_t_ped from sri-nic.arpa. It is also recom- meded that you read the related manual pages, _n_a_m_e_d(8), _r_e_s_o_l_v_e_r(3), and _r_e_s_o_l_v_e_r(5). The advantage of using a name server over the host table lookup for host name resolution is to avoid the need for a single centralized clearinghouse for all names. The authority for this information can be delegated to the different organizations on the ____________________ 9 |=VAX is a Trademark of Digital Equipment Corporation 9 Name Server Operations Guide for BIND SMM:11-3 network responsible for it. The host table lookup routines require that the master file for the entire network be maintained at a central location by a few people. This works fine for small networks where there are only a few machines and the different organizations responsible for them cooperate. But this does not work well for large net- works where machines cross organizational boundaries. With the name server, the network can be broken into a hierarchy of domains. The name space is organ- ized as a tree according to organizational or adminis- trative boundaries. Each node, called a _d_o_m_a_i_n, is given a label, and the name of the domain is the con- catenation of all the labels of the domains from the root to the current domain, listed from right to left separated by dots. A label need only be unique within its domain. The whole space is partitioned into several areas called _z_o_n_e_s, each starting at a domain and extending down to the leaf domains or to domains where other zones start. Zones usually represent administrative boundaries. An example of a host address for a host at the University of California, Berkeley would look as follows: _m_o_n_e_t._B_e_r_k_e_l_e_y._E_D_U The top level domain for educational organizations is EDU; Berkeley is a subdomain of EDU and monet is the name of the host. _3. _T_y_p_e_s _o_f _S_e_r_v_e_r_s There are three types of servers, Master, Caching and Remote. _3._1. _M_a_s_t_e_r _S_e_r_v_e_r_s A Master Server for a domain is the authority for that domain. This server maintains all the data corresponding to its domain. Each domain should have at least two master servers, a primary master and some secondary masters to provide backup service if the primary is unavailable or overloaded. A server may be a master for multiple domains, being primary for some domains and secondary for others. _3._1._1. _P_r_i_m_a_r_y A Primary Master Server is a server that loads its data from a file on disk. This server may also SMM:11-4 Name Server Operations Guide for BIND delegate authority to other servers in its domain. _3._1._2. _S_e_c_o_n_d_a_r_y A Secondary Master Server is a server that is delegated authority and receives its data for a domain from a primary master server. At boot time, the secondary server requests all the data for the given zone from the primary master server. This server then periodically checks with the primary server to see if it needs to update its data. _3._2. _C_a_c_h_i_n_g _O_n_l_y _S_e_r_v_e_r All servers are caching servers. This means that the server caches the information that it receives for use until the data expires. A _C_a_c_h_i_n_g _O_n_l_y _S_e_r_v_e_r is a server that is not authoritative for any domain. This server services queries and asks other servers, who have the authority, for the information needed. All servers keep data in their cache until the data expires, based on a time to live field attached to the data when it is received from another server. _3._3. _R_e_m_o_t_e _S_e_r_v_e_r A Remote Server is an option given to people who would like to use a name server on their workstation or on a machine that has a limited amount of memory and CPU cycles. With this option you can run all of the networking programs that use the name server without the name server running on the local machine. All of the queries are serviced by a name server that is running on another machine on the network. _4. _S_e_t_t_i_n_g _u_p _Y_o_u_r _O_w_n _D_o_m_a_i_n When setting up a domain that is going to be on a public network the site administrator should contact the organization in charge of the network and request the appropriate domain registration form. An organization that belongs to multiple networks (such as _C_S_N_E_T, _D_A_R_P_A _I_n_t_e_r_n_e_t and _B_I_T_N_E_T) should register with only one net- work. The contacts are as follows: _4._1. _D_A_R_P_A _I_n_t_e_r_n_e_t Sites that are already on the DARPA Internet and need information on setting up a domain should contact HOSTMASTER@SRI-NIC._A_R_P_A. You may also want to be Name Server Operations Guide for BIND SMM:11-5 placed on the BIND mailing list, which is a mail group for people on the DARPA Internet running BIND. The group discusses future design decisions, operational problems, and other related topic. The address to request being placed on this mailing list is: _b_i_n_d-_r_e_q_u_e_s_t@_u_c_b_a_r_p_a._B_e_r_k_e_l_e_y._E_D_U. _4._2. _C_S_N_E_T A _C_S_N_E_T member organization that has not registered its domain name should contact the _C_S_N_E_T Coordination and Information Center (_C_I_C) for an application and information about setting up a domain. An organization that already has a registered domain name should keep the _C_I_C informed about how it would like its mail routed. In general, the _C_S_N_E_T relay will prefer to send mail via _C_S_N_E_T (as opposed to _B_I_T_N_E_T or the _I_n_t_e_r_n_e_t) if possible. For an organi- zation on multiple networks, this may not always be the preferred behavior. The _C_I_C can be reached via electronic mail at _c_i_c@_s_h._c_s._n_e_t, or by phone at (617) 497-2777. _4._3. _B_I_T_N_E_T If you are on the BITNET and need to set up a domain, contact INFO@BITNIC. _5. _F_i_l_e_s The name server uses several files to load its data base. This section covers the files and their formats needed for _n_a_m_e_d. _5._1. _B_o_o_t _F_i_l_e This is the file that is first read when _n_a_m_e_d starts up. This tells the server what type of server it is, which zones it has authority over and where to get its initial data. The default location for this file is /_e_t_c/_n_a_m_e_d._b_o_o_t. However this can be changed by setting the _B_O_O_T_F_I_L_E variable when you compile _n_a_m_e_d or by specifying the location on the command line when _n_a_m_e_d is started up. _5._1._1. _D_o_m_a_i_n The line in the boot file that designates the default domain for the server looks as follows: SMM:11-6 Name Server Operations Guide for BIND _d_o_m_a_i_n _B_e_r_k_e_l_e_y._E_d_u The name server uses this information when it receives a query for a name without a ``.''. When it receives one of these queries, it appends the name in the second field to the query name. _5._1._2. _P_r_i_m_a_r_y _M_a_s_t_e_r The line in the boot file that designates the server as a primary server for a zone looks as fol- lows: _p_r_i_m_a_r_y _B_e_r_k_e_l_e_y._E_d_u /_e_t_c/_u_c_b_h_o_s_t_s The first field specifies that the server is a pri- mary one for the zone stated in the second field. The third field is the name of the file from which the data is read. _5._1._3. _S_e_c_o_n_d_a_r_y _M_a_s_t_e_r The line for a secondary server is similar to the primary except for the word secondary and the third field. _s_e_c_o_n_d_a_r_y _B_e_r_k_e_l_e_y._E_d_u _1_2_8._3_2._0._1_0_1_2_8._3_2._0._4 The first field specifies that the server is a secondary master server for the zone stated in the second field. The rest of the line, lists the net- work addresses for the name servers that are pri- mary for the zone. The secondary server gets its data across the network from the listed servers. Each server is tried in the order listed until it successfully receives the data from a listed server. _5._1._4. _C_a_c_h_i_n_g _O_n_l_y _S_e_r_v_e_r You do not need a special line to designate that a server is a caching server. What denotes a caching only server is the absence of authority lines, such as _s_e_c_o_n_d_a_r_y or _p_r_i_m_a_r_y in the boot file. All servers should have a line as follows in the boot file to prime the name servers cache: _c_a_c_h_e . /_e_t_c/_n_a_m_e_d._c_a For information on cache file see section on _C_a_c_h_e _I_n_i_t_i_a_l_i_z_a_t_i_o_n. Name Server Operations Guide for BIND SMM:11-7 _5._1._5. _R_e_m_o_t_e _S_e_r_v_e_r To set up a host that will use a remote server instead of a local server to answer queries, the file /_e_t_c/_r_e_s_o_l_v._c_o_n_f needs to be created. This file designates the name servers on the network that should be sent queries. It is not advisable to create this file if you have a local server run- ning. If this file exists it is read almost every time _g_e_t_h_o_s_t_b_y_n_a_m_e() or _g_e_t_h_o_s_t_b_y_a_d_d_r() is called. _5._2. _C_a_c_h_e _I_n_i_t_i_a_l_i_z_a_t_i_o_n _5._2._1. _n_a_m_e_d._c_a The name server needs to know the server that is the authoritative name server for the network. To do this we have to prime the name server's cache with the address of these higher authorities. The location of this file is specified in the boot file. This file uses the Standard Resource Record Format covered further on in this paper. _5._3. _D_o_m_a_i_n _D_a_t_a _F_i_l_e_s There are three standard files for specifying the data for a domain. These are _n_a_m_e_d._l_o_c_a_l, _h_o_s_t_s and _h_o_s_t._r_e_v. These files use the Standard Resource Record Format covered later in this paper. _5._3._1. _n_a_m_e_d._l_o_c_a_l This file specifies the address for the local loopback interface, better known as _l_o_c_a_l_h_o_s_t with the network address 127.0.0.1. The location of this file is specified in the boot file. _5._3._2. _h_o_s_t_s This file contains all the data about the machines in this zone. The location of this file is specified in the boot file. _5._3._3. _h_o_s_t_s._r_e_v This file specifies the IN-ADDR.ARPA domain. This is a special domain for allowing address to name mapping. As internet host addresses do not fall within domain boundaries, this special domain was formed to allow inverse mapping. The IN- ADDR.ARPA domain has four labels preceding it. These labels correspond to the 4 octets of an Internet address. All four octets must be specified SMM:11-8 Name Server Operations Guide for BIND even if an octets is zero. The Internet address 128.32.0.4 is located in the domain 4.0.32.128.IN- ADDR.ARPA. This reversal of the address is awkward to read but allows for the natural grouping of hosts in a network. _5._4. _S_t_a_n_d_a_r_d _R_e_s_o_u_r_c_e _R_e_c_o_r_d _F_o_r_m_a_t The records in the name server data files are called resource records. The Standard Resource Record Format (RR) is specified in RFC882 and RFC973. The following is a general description of these records: {_n_a_m_e} {_t_t_l} _a_d_d_r-_c_l_a_s_s _R_e_c_o_r_d _T_y_p_e _R_e_c_o_r_d _S_p_e_c_i_f_i_c _d_a_t_a Resource records have a standard format shown above. The first field is always the name of the domain record. For some RR's the name may be left blank; in that case it takes on the name of the previous RR. The second field is an optional time to live field. This specifies how long this data will be stored in the data base. By leaving this field blank the default time to live is specified in the _S_t_a_r_t _O_f _A_u_t_h_o_r_i_t_y resource record (see below). The third field is the address class; there are currently two classes: _I_N for internet addresses and _A_N_Y for all address classes. The fourth field states the type of the resource record. The fields after that are depen- dent on the type of the RR. Case is preserved in names and data fields when loaded into the name server. All comparisons and lookups in the name server data base are case insensitive. _T_h_e _f_o_l_l_o_w_i_n_g _c_h_a_r_a_c_t_e_r_s _h_a_v_e _s_p_e_c_i_a_l _m_e_a_n_i_n_g_s: . A free standing dot in the name field refers to the current domain. @ A free standing @ in the name field denotes the current origin. .. Two free standing dots represent the null domain name of the root when used in the name field. \X Where X is any character other than a digit (0- 9), quotes that character so that its special meaning does not apply. For example, ``\.'' can be used to place a dot character in a label. \DDD Where each D is a digit, is the octet correspond- ing to the decimal number described by DDD. The resulting octet is assumed to be text and is not Name Server Operations Guide for BIND SMM:11-9 checked for special meaning. ( ) Parentheses are used to group data that crosses a line. In effect, line terminations are not recog- nized within parentheses. ; Semicolon starts a comment; the remainder of the line is ignored. * An asterisk signifies wildcarding. Most resource records will have the current ori- gin appended to names if they are not terminated by a ``.''. This is useful for appending the current domain name to the data, such as machine names, but may cause problems where you do not want this to happen. A good rule of thumb is that, if the name is not in of the domain for which you are creating the data file, end the name with a ``.''. _5._4._1. $_I_N_C_L_U_D_E An include line begins with $INCLUDE, starting in column 1, and is followed by a file name. This feature is particularly useful for separating dif- ferent types of data into multiple files. An exam- ple would be: $INCLUDE /usr/named/data/mailboxs The line would be interpreted as a request to load the file /_u_s_r/_n_a_m_e_d/_d_a_t_a/_m_a_i_l_b_o_x_e_s. The $INCLUDE command does not cause data to be loaded into a different zone or tree. This is simply a way to allow data for a given zone to be organized in separate files. For example, mailbox data might be kept separately from host data using this mechan- ism. _5._4._2. $_O_R_I_G_I_N The origin is a way of changing the origin in a data file. The line starts in column 1, and is followed by a domain origin. This is useful for putting more then one domain in a data file. _5._4._3. _S_O_A - _S_t_a_r_t _O_f _A_u_t_h_o_r_i_t_y 9 9 SMM:11-10 Name Server Operations Guide for BIND _n_a_m_e {_t_t_l} _a_d_d_r-_c_l_a_s_s _S_O_A _O_r_i_g_i_n _P_e_r_s_o_n _i_n _c_h_a_r_g_e @ IN SOA ucbvax.Berkeley.Edu. kjd.ucbvax.Berkeley.Edu. ( 1.1 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ) ; Minimum The _S_t_a_r_t _o_f _A_u_t_h_o_r_i_t_y, _S_O_A, record designates the start of a zone. The name is the name of the zone. Origin is the name of the host on which this data file resides. Person in charge is the mailing address for the person responsible for the name server. The serial number is the version number of this data file, this number should be incremented whenever a change is made to the data. The name server cannot handle numbers over 9999 after the decimal point. The refresh indicates how often, in seconds, a secondary name servers is to check with the primary name server to see if an update is needed. The retry indicates how long, in seconds, a secondary server is to retry after a failure to check for a refresh. Expire is the upper limit, in seconds, that a secondary name server is to use the data before it expires for lack of getting a refresh. Minimum is the default number of seconds to be used for the time to live field on resource records. There should only be one _S_O_A record per zone. _5._4._4. _N_S - _N_a_m_e _S_e_r_v_e_r {_n_a_m_e} {_t_t_l} _a_d_d_r-_c_l_a_s_s _N_S _N_a_m_e _s_e_r_v_e_r_s _n_a_m_e IN NS ucbarpa.Berkeley.Edu. The _N_a_m_e _S_e_r_v_e_r record, _N_S, lists a name server responsible for a given domain. The first name field lists the domain that is serviced by the listed name server. There should be one _N_S record for each Primary Master server for the domain. _5._4._5. _A - _A_d_d_r_e_s_s {_n_a_m_e} {_t_t_l} _a_d_d_r-_c_l_a_s_s _A _a_d_d_r_e_s_s ucbarpa IN A 128.32.0.4 IN A 10.0.0.78 The _A_d_d_r_e_s_s record, _A, lists the address for a given machine. The name field is the machine name and the address is the network address. There Name Server Operations Guide for BIND SMM:11-11 should be one _A record for each address of the machine. _5._4._6. _H_I_N_F_O - _H_o_s_t _I_n_f_o_r_m_a_t_i_o_n {_n_a_m_e} {_t_t_l} _a_d_d_r-_c_l_a_s_s _H_I_N_F_O _H_a_r_d_w_a_r_e _O_S ANY HINFO VAX-11/780 UNIX _H_o_s_t _I_n_f_o_r_m_a_t_i_o_n resource record, _H_I_N_F_O, is for host specific data. This lists the hardware and operating system that are running at the listed host. It should be noted that only a single space separates the hardware info and the operating sys- tem info. If you want to include a space in the machine name you must quote the name. Host infor- mation is not specific to any address class, so _A_N_Y may be used for the address class. There should be one _H_I_N_F_O record for each host. _5._4._7. _W_K_S - _W_e_l_l _K_n_o_w_n _S_e_r_v_i_c_e_s {_n_a_m_e} {_t_t_l} _a_d_d_r-_c_l_a_s_s _W_K_S _a_d_d_r_e_s_s _p_r_o_t_o_c_o_l _l_i_s_t _o_f _s_e_r_v_i_c_e_s IN WKS 128.32.0.10 UDP who route timed domain IN WKS 128.32.0.10 TCP ( echo telnet discard sunrpc sftp uucp-path systat daytime netstat qotd nntp link chargen ftp auth time whois mtp pop rje finger smtp supdup hostnames domain nameserver ) The _W_e_l_l _K_n_o_w_n _S_e_r_v_i_c_e_s record, _W_K_S, describes the well known services supported by a particular pro- tocol at a specified address. The list of services and port numbers come from the list of services specified in /_e_t_c/_s_e_r_v_i_c_e_s. There should be only one _W_K_S record per protocol per address. _5._4._8. _C_N_A_M_E - _C_a_n_o_n_i_c_a_l _N_a_m_e _a_l_i_a_s_e_s {_t_t_l} _a_d_d_r-_c_l_a_s_s _C_N_A_M_E _C_a_n_o_n_i_c_a_l _n_a_m_e ucbmonet IN CNAME monet _C_a_n_o_n_i_c_a_l _N_a_m_e resource record, _C_N_A_M_E, specifies an alias for a canonical name. An alias should be unique and all other resource records should be associated with the canonical name and not with the SMM:11-12 Name Server Operations Guide for BIND alias. Do not create an alias and then use it in other resource records. _5._4._9. _P_T_R - _D_o_m_a_i_n _N_a_m_e _P_o_i_n_t_e_r _n_a_m_e {_t_t_l} _a_d_d_r-_c_l_a_s_s _P_T_R _r_e_a_l _n_a_m_e 7.0 IN PTR monet.Berkeley.Edu. A _D_o_m_a_i_n _N_a_m_e _P_o_i_n_t_e_r record, _P_T_R, allows special names to point to some other location in the domain. The above example of a _P_T_R record is used in setting up reverse pointers for the special _I_N- _A_D_D_R._A_R_P_A domain. This line is from the example _h_o_s_t_s._r_e_v file. _P_T_R names should be unique to the zone. _5._4._1_0. _M_B - _M_a_i_l_b_o_x _n_a_m_e {_t_t_l} _a_d_d_r-_c_l_a_s_s _M_B _M_a_c_h_i_n_e miriam IN MB vineyd.DEC.COM. _M_B is the _M_a_i_l_b_o_x record. This lists the machine where a user wants to receive mail. The name field is the users login; the machine field denotes the machine to which mail is to be delivered. Mail Box names should be unique to the zone. _5._4._1_1. _M_R - _M_a_i_l _R_e_n_a_m_e _N_a_m_e _n_a_m_e {_t_t_l} _a_d_d_r-_c_l_a_s_s _M_R _c_o_r_r_e_s_p_o_n_d_i_n_g _M_B Postmistress IN MR miriam _M_a_i_n _R_e_n_a_m_e, _M_R, can be used to list aliases for a user. The name field lists the alias for the name listed in the fourth field, which should have a corresponding _M_B record. _5._4._1_2. _M_I_N_F_O - _M_a_i_l_b_o_x _I_n_f_o_r_m_a_t_i_o_n _n_a_m_e {_t_t_l} _a_d_d_r-_c_l_a_s_s _M_I_N_F_O _r_e_q_u_e_s_t_s _m_a_i_n_t_a_i_n_e_r BIND IN MINFO BIND-REQUEST kjd.Berkeley.Edu. _M_a_i_l _I_n_f_o_r_m_a_t_i_o_n record, _M_I_N_F_O, creates a mail group for a mailing list. This resource record is usually associated with a mail group _M_a_i_l _G_r_o_u_p, but may be used with a _M_a_i_l _B_o_x record. The _n_a_m_e specifies the name of the mailbox. The _r_e_q_u_e_s_t_s field is where mail such as requests to be added to a mail group should be sent. The _m_a_i_n_t_a_i_n_e_r is a mailbox that should receive error messages. This is particularly appropriate for mailing lists when errors in members names should be reported to a Name Server Operations Guide for BIND SMM:11-13 person other than the sender. _5._4._1_3. _M_G - _M_a_i_l _G_r_o_u_p _M_e_m_b_e_r {_m_a_i_l _g_r_o_u_p _n_a_m_e} {_t_t_l} _a_d_d_r-_c_l_a_s_s _M_G _m_e_m_b_e_r _n_a_m_e IN MG Bloom _M_a_i_l _G_r_o_u_p, _M_G lists members of a mail group. An example for setting up a mailing list is as fol- lows: Bind IN MINFO Bind-Request kjd.Berkeley.Edu. IN MG Ralph.Berkeley.Edu. IN MG Zhou.Berkeley.Edu. IN MG Painter.Berkeley.Edu. IN MG Riggle.Berkeley.Edu. IN MG Terry.pa.Xerox.Com. _5._4._1_4. _M_X - _M_a_i_l _E_x_c_h_a_n_g_e_r _n_a_m_e {_t_t_l} _a_d_d_r-_c_l_a_s_s _M_X _p_r_e_f_e_r_e_n_c_e _v_a_l_u_e _m_a_i_l_e_r _e_x_c_h_a_n_g_e_r Munnari.OZ.AU. IN MX 0 Seismo.CSS.GOV. *.IL. IN MX 0 RELAY.CS.NET. _M_a_i_n _E_x_c_h_a_n_g_e_r records, _M_X, are used to specify a machine that knows how to deliver mail to a machine that is not directly connected to the network. In the first example, above, Seismo.CSS.GOV. is a mail gateway that knows how to deliver mail to Munnari.OZ.AU. but other machines on the network can not deliver mail directly to Munnari. These two machines may have a private connection or use a different transport medium. The preference value is the order that a mailer should follow when there is more then one way to deliver mail to a single machine. See RFC974 for more detailed information. Wildcard names containing the character ``*'' may be used for mail routing with _M_X records. There are likely to be servers on the network that simply state that any mail to a domain is to be routed through a relay. Second example, above, all mail to hosts in the domain IL is routed through RELAY.CS.NET. This is done by creating a wildcard resource record, which states that *.IL has an _M_X of RELAY.CS.NET. 9 9 SMM:11-14 Name Server Operations Guide for BIND _5._5. _S_a_m_p_l_e _F_i_l_e_s The following section contains sample files for the name server. This covers example boot files for the different types of servers and example domain data base files. _5._5._1. _B_o_o_t _F_i_l_e _5._5._1._1. _P_r_i_m_a_r_y _M_a_s_t_e_r _S_e_r_v_e_r ; ; Boot file for Primary Master Name Server ; ; type domain source file or host ; domain Berkeley.Edu primary Berkeley.Edu /etc/ucbhosts cache . /etc/named.ca primary 32.128.in-addr.arpa /etc/ucbhosts.rev primary 0.0.127.in-addr.arpa /etc/named.local _5._5._1._2. _S_e_c_o_n_d_a_r_y _M_a_s_t_e_r _S_e_r_v_e_r ; ; Boot file for Primary Master Name Server ; ; type domain source file or host ; domain Berkeley.Edu secondary Berkeley.Edu 128.32.0.4 128.32.0.10 128.32.136.22 cache . /etc/named.ca secondary 32.128.in-addr.arpa 128.32.0.4 128.32.0.10 128.32.136.22 primary 0.0.127.in-addr.arpa /etc/named.local _5._5._1._3. _C_a_c_h_i_n_g _O_n_l_y _S_e_r_v_e_r 9 9 Name Server Operations Guide for BIND SMM:11-15 ; ; Boot file for Primary Master Name Server ; ; type domain source file or host ; domain Berkeley.Edu cache . /etc/named.ca primary 0.0.127.in-addr.arpa /etc/named.local 9 9 SMM:11-16 Name Server Operations Guide for BIND _5._5._2. _R_e_m_o_t_e _S_e_r_v_e_r _5._5._2._1. /_e_t_c/_r_e_s_o_l_v._c_o_n_f domain Berkeley.Edu nameserver 128.32.0.4 nameserver 128.32.0.10 _5._5._3. _n_a_m_e_d._c_a ; ; Initial cache data for root domain servers. ; . 99999999 IN NS USC-ISIC.ARPA. 99999999 IN NS USC-ISIB.ARPA. 99999999 IN NS BRL-AOS.ARPA. 99999999 IN NS SRI-NIC.ARPA. ; Prep the cache (hotwire the addresses). SRI-NIC.ARPA. 99999999 IN A 10.0.0.51 USC-ISIB.ARPA. 99999999 IN A 10.3.0.52 USC-ISIC.ARPA. 99999999 IN A 10.0.0.52 BRL-AOS.ARPA. 99999999 IN A 128.20.1.2 BRL-AOS.ARPA. 99999999 IN A 192.5.22.82 _5._5._4. _n_a_m_e_d._l_o_c_a_l @ IN SOA ucbvax.Berkeley.Edu. kjd.ucbvax.Berkeley.Edu. ( 1 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS ucbvax.Berkeley.Edu. 1 IN PTR localhost. 9 9 Name Server Operations Guide for BIND SMM:11-17 _5._5._5. _H_o_s_t_s 9 9 SMM:11-18 Name Server Operations Guide for BIND ; ; @(#)ucb-hosts 1.1 (berkeley) 86/02/05 ; @ IN SOA ucbvax.Berkeley.Edu. kjd.monet.Berkeley.Edu. ( 1.1 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS ucbarpa.Berkeley.Edu. IN NS ucbvax.Berkeley.Edu. localhost IN A 127.1 ucbarpa IN A 128.32.4 IN A 10.0.0.78 ANY HINFO VAX-11/780 UNIX arpa IN CNAME ucbarpa ernie IN A 128.32.6 ANY HINFO VAX-11/780 UNIX ucbernie IN CNAME ernie monet IN A 128.32.7 IN A 128.32.130.6 ANY HINFO VAX-11/750 UNIX ucbmonet IN CNAME monet ucbvax IN A 10.2.0.78 IN A 128.32.10 ANY HINFO VAX-11/750 UNIX IN WKS 128.32.0.10 UDP syslog route timed domain IN WKS 128.32.0.10 TCP ( echo telnet discard sunrpc sftp uucp-path systat daytime netstat qotd nntp link chargen ftp auth time whois mtp pop rje finger smtp supdup hostnames domain nameserver ) vax IN CNAME ucbvax toybox IN A 128.32.131.119 ANY HINFO Pro350 RT11 toybox IN MX 0 monet.Berkeley.Edu miriam ANY MB vineyd.DEC.COM. postmistress ANY MR Miriam Bind ANY MINFO Bind-Request kjd.Berkeley.Edu. ANY MG Ralph.Berkeley.Edu. ANY MG Zhou.Berkeley.Edu. ANY MG Painter.Berkeley.Edu. ANY MG Riggle.Berkeley.Edu. ANY MG Terry.pa.Xerox.Com. 9 9 Name Server Operations Guide for BIND SMM:11-19 _5._5._6. _h_o_s_t._r_e_v ; ; @(#)ucb-hosts.rev 1.1 (Berkeley) 86/02/05 ; @ IN SOA ucbvax.Berkeley.Edu. kjd.monet.Berkeley.Edu. ( 1.1 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS ucbarpa.Berkeley.Edu. IN NS ucbvax.Berkeley.Edu. 4.0 IN PTR ucbarpa.Berkeley.Edu. 6.0 IN PTR ernie.Berkeley.Edu. 7.0 IN PTR monet.Berkeley.Edu. 10.0 IN PTR ucbvax.Berkeley.Edu. 6.130 IN PTR monet.Berkeley.Edu. _6. _D_o_m_a_i_n _M_a_n_a_g_e_m_e_n_t This section contains information for starting, con- trolling and debugging _n_a_m_e_d. _6._1. /_e_t_c/_r_c._l_o_c_a_l The hostname should be set to the full domain style name in /_e_t_c/_r_c._l_o_c_a_l using _h_o_s_t_n_a_m_e(_1). The following entry should be added to /_e_t_c/_r_c._l_o_c_a_l to start up _n_a_m_e_d at system boot time: _i_f [ -_f /_e_t_c/_n_a_m_e_d ]; _t_h_e_n /_e_t_c/_n_a_m_e_d [options] & _e_c_h_o -_n ' _n_a_m_e_d' >/_d_e_v/_c_o_n_s_o_l_e _f_i This usually directly follows the lines that start _s_y_s_l_o_g_d. Do Not attempt to run _n_a_m_e_d from _i_n_e_t_d. This will continuously restart the name server and defeat the purpose of having a cache. _6._2. /_e_t_c/_n_a_m_e_d._p_i_d When _n_a_m_e_d is successfully started up it writes its process id into the file /_e_t_c/_n_a_m_e_d._p_i_d. This is SMM:11-20 Name Server Operations Guide for BIND useful to programs that want to send signals to _n_a_m_e_d. The name of this file may be changed by defining _P_I_D_- _F_I_L_E to the new name when compiling _n_a_m_e_d. _6._3. /_e_t_c/_h_o_s_t_s The _g_e_t_h_o_s_t_b_y_n_a_m_e() library call can detect if _n_a_m_e_d is running. If it is determined that _n_a_m_e_d is not running it will look in /_e_t_c/_h_o_s_t_s to resolve an address. This option was added to allow _i_f_c_o_n_f_g(_8_C) to configure the machines local interfaces and to enable a system manager to access the network while the sys- tem is in single user mode. It is advisable to put the local machines interface addresses and a couple of machine names and address in /_e_t_c/_h_o_s_t_s so the system manager can rcp files from another machine when the system is in single user mode. The format of /_e_t_c/_h_o_s_t has not changed. See _h_o_s_t_s(_5) for more information. Since the process of reading /_e_t_c/_h_o_s_t_s is slow, it is not advised to use this option when the system is in multi user mode. _6._4. _S_i_g_n_a_l_s There are several signals that can be sent to the _n_a_m_e_d process to have it do tasks without restarting the process. _6._4._1. _R_e_l_o_a_d SIGHUP - Causes _n_a_m_e_d to read _n_a_m_e_d._b_o_o_t and reload the database. All previously cached data is lost. This is useful when you have made a change to a data file and you want _n_a_m_e_d's internal data- base to reflect the change. _6._4._2. _D_e_b_u_g_g_i_n_g When _n_a_m_e_d is running incorrectly, look first in /_u_s_r/_a_d_m/_m_e_s_s_a_g_e_s and check for any messages logged by _s_y_s_l_o_g. Next send it a signal to see what is happening. SIGINT - Dumps the current data base and cache to /_u_s_r/_t_m_p/_n_a_m_e_d__d_u_m_p._d_b This should give you an indication to whether the data base was loaded correctly. The name of the dump file may be changed by defining _D_U_M_P_F_I_L_E to the new name when compiling _n_a_m_e_d. _N_o_t_e: the following two signals only work when _n_a_m_e_d is built with _D_E_B_U_G defined. Name Server Operations Guide for BIND SMM:11-21 SIGUSR1 - Turns on debugging. Each following USR1 increments the debug level. The output goes to /_u_s_r/_t_m_p/_n_a_m_e_d._r_u_n The name of this debug file may be changed by defining _D_E_B_U_G_F_I_L_E to the new name before compiling _n_a_m_e_d. SIGUSR2 - Turns off debugging completely. For more detailed debugging, define DEBUG when com- piling the resolver routines into /_l_i_b/_l_i_b_c._a. _A_C_K_N_O_W_L_E_D_G_E_M_E_N_T_S Many thanks to the users at U.C. Berkeley for falling into many of the holes involved with integrating BIND into the system so that others would be spared the trauma. I would also like to extend gratitude to Jim McGinness and Digital Equipment Corporation for permitting me to spend most of my time on this project. Ralph Campbell, Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, Mike Muuss and everyone else on the DARPA Internet who has contributed to the development of BIND. To the members of the original BIND project, Douglas Terry, Mark Painter, David Riggle and Songnian Zhou. Anne Hughes, Jim Bloom and Kirk McKusick and the many others who have reviewed this paper giving considerable advice. This work was sponsored by the Defense Advanced Research Projects Agency (DoD), Arpa Order No. 4871 moni- tored by the Naval Electronics Systems Command under con- tract No. N00039-84-C-0089. The views and conclusions con- tained in this document are those of the authors and should not be interpreted as representing official policies, either expressed or implied, of the Defense Research Projects Agency, of the US Government, or of Digital Equipment Cor- poration. 9 9 SMM:11-22 Name Server Operations Guide for BIND _R_E_F_E_R_E_N_C_E_S [Birrell] Birrell, A. D., Levin, R., Needham, R. M., and Schroeder, M.D., "Grapevine: An Exercise in Dis- tributed Computing." In _C_o_m_m. _A._C._M. _2_5, 4:260-274 April 1982. [RFC819] Su, Z. Postel, J., "The Domain Naming Convention for Internet User Applications." _I_n_t_e_r_n_e_t _R_e_q_u_e_s_t _F_o_r _C_o_m_m_e_n_t _8_1_9 Network Information Center, SRI International, Menlo Park, California. August 1982. [RFC882] Mockapetris, P., "Domain Names - Concept and Facilities." _I_n_t_e_r_n_e_t _R_e_q_u_e_s_t _F_o_r _C_o_m_m_e_n_t _8_8_2 Net- work Information Center, SRI International, Menlo Park, California. November 1983. [RFC883] Mockapetris, P., "Domain Names - Implementation and Specification." _I_n_t_e_r_n_e_t _R_e_q_u_e_s_t _F_o_r _C_o_m_m_e_n_t _8_8_3 Network Information Center, SRI International, Menlo Park, California. November 1983. [RFC973] Mockapetris, P., "Domain System Changes and Obser- vations." _I_n_t_e_r_n_e_t _R_e_q_u_e_s_t _F_o_r _C_o_m_m_e_n_t _9_7_3 Network Information Center, SRI International, Menlo Park, California. February 1986. [RFC974] Partridge, C., "Mail Routing and The Domain Sys- tem." _I_n_t_e_r_n_e_t _R_e_q_u_e_s_t _F_o_r _C_o_m_m_e_n_t _9_7_4 Network Information Center, SRI International, Menlo Park, California. February 1986. [Terry] Terry, D. B., Painter, M., Riggle, D. W., and Zhou, S., _T_h_e _B_e_r_k_e_l_e_y _I_n_t_e_r_n_e_t _N_a_m_e _D_o_m_a_i_n _S_e_r_v_e_r. Proceedings USENIX Summer Conference, Salt Lake City, Utah. June 1984, pages 23-31. [Zhou] Zhou, S., _T_h_e _D_e_s_i_g_n _a_n_d _I_m_p_l_e_m_e_n_t_a_t_i_o_n _o_f _t_h_e _B_e_r_k_e_l_e_y _I_n_t_e_r_n_e_t _N_a_m_e _D_o_m_a_i_n (_B_I_N_D) _S_e_r_v_e_r_s. UCB/CSD 84/177. University of California, Berke- ley, Computer Science Division. May 1984. 9 9