rtsi.com

home *** CD-ROM | disk | FTP | other *** search

/ rtsi.com / 2014.01.www.rtsi.com.tar / www.rtsi.com / OS9 / OSK / NETWORK / ISP / bind.4.8.3.lzh / BIND483 / DOC / BOG / file < prev next >

Wrap

Text File | 1993-08-24 | 60KB | 1,651 lines

NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD _R_e_l_e_a_s_e _4._8 Kevin J. Dunlap* Michael J. Karels Computer Systems Research Group Computer Science Division Department of Electrical Engineering and Computer Sciences University of California Berkeley CA 94720 11.. IInnttrroodduuccttiioonn 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. 22.. BBuuiillddiinngg AA SSyysstteemm wwiitthh aa NNaammee SSeerrvveerr 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 ____________________ * The author was an employee of Digital Equipment Corporation's Ultrix Engineering Advanced Development Group and was on loan to CSRG when this work was done. Ultrix is a trademark of Digital Equipment Corporation. |-UNIX is a Trademark of AT&T Bell Laboratories SSMMMM::1111--22 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD given network port. The standard port for UDP and TCP is specified in /_e_t_c/_s_e_r_v_i_c_e_s. 22..11.. RReessoollvveerr RRoouuttiinneess iinn lliibbcc 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|=''. 22..22.. TThhee NNaammee SSeerrvviiccee 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 RFC1034, RFC1035 and RFC974. These docu- ments 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 nic.ddn.mil. It is also recommeded 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 net- work responsible for it. ____________________ |=VAX is a Trademark of Digital Equipment Corporation NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--33 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. 33.. TTyyppeess ooff SSeerrvveerrss There are several types of servers: Master, Caching, Remote, and Slave. 33..11.. MMaasstteerr SSeerrvveerrss 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. 33..11..11.. PPrriimmaarryy A Primary Master Server is a server that loads its data from a file on disk. This server may also delegate authority to other servers in its domain. SSMMMM::1111--44 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 33..11..22.. SSeeccoonnddaarryy 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. 33..22.. CCaacchhiinngg OOnnllyy SSeerrvveerr 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. 33..33.. RReemmoottee SSeerrvveerr 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. 33..44.. SSllaavvee SSeerrvveerr A Slave Server is a server that always forwards queries it cannot satisfy locally to a fixed list of _f_o_r_w_a_r_d_i_n_g servers instead of interacting with the master nameservers for the root and other domains. The queries to the _f_o_r_w_a_r_d_i_n_g _s_e_r_v_e_r_s are recursive queries. There may be one or more forwarding servers, and they are tried in turn until the list is exhausted. A Slave and forwarder configuration is typically used when you do not wish all the servers at a give site to be interacting with the rest of the Internet servers. A typically scenario would involve a number of workstations and a departmental timeshar- ing machine with Internet access. The workstations might be administratively prohibited from having Internet access. To give the workstations the appear- ance of access to the Internet domain system, the workstations could be Slave servers to the timesharing machine which would forward the queries and interact NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--55 with other nameservers to resolv the query before returning the answer. An added benefit of using the forwarding feature is that the central machine develops a much more complete cache of information that all the workstations can take advantage of. The use Slave mode and forwarding is discussed further under the description of the named bootfile commands. 44.. SSeettttiinngg uupp YYoouurr OOwwnn DDoommaaiinn 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: 44..11.. DDAARRPPAA IInntteerrnneett Sites that are already on the DARPA Internet and need information on setting up a domain should contact HOSTMASTER@NIC..DDN..MIL.. You may also want to be 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.. 44..22.. CCSSNNEETT 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) 873-2777. SSMMMM::1111--66 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 44..33.. BBIITTNNEETT If you are on the BITNET and need to set up a domain, contact INFO@BITNIC. 55.. FFiilleess 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. 55..11.. BBoooott FFiillee 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. 55..11..11.. DDoommaaiinn A default domain may be specified for the nameserver using a line such as _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 ``..'' that is not known. When it receives one of these queries, it appends the name in the second field to the query name. This is an obsolete facility which will be removed from future releases. 55..11..22.. DDiirreeccttoorryy The directory line specifies the directory in which the nameserver should run, allowing the other file names in the boot file to use relative path names. _d_i_r_e_c_t_o_r_y /_u_s_r/_l_o_c_a_l/_d_o_m_a_i_n If you have more than a couple of named files to be maintained, you may wish to place the named files in a directory such as /usr/local/domain and adjust the directory command properly. The main purposes of this command are to make sure named is in the proper directory when trying to include files by relative path names with $Include and to allow NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--77 named to run in a location that is reasonable to dump core if it feels the urge. 55..11..33.. PPrriimmaarryy MMaasstteerr 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 _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. 55..11..44.. SSeeccoonnddaarryy MMaasstteerr The line for a secondary server is similar to the primary except that it lists addresses of other servers (usually primary servers) from which the zone data will be obtained. _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 _u_c_b_h_o_s_t_s._b_a_k The first field specifies that the server is a secondary master server for the zone stated in the second field. The two network addresses specify the name servers that are primary for the zone. The secondary server gets its data across the net- work from the listed servers. Each server is tried in the order listed until it successfully receives the data from a listed server. If a filename is present after the list of primary servers, data for the zone will be dumped into that file as a backup. When the server is first started, the data are loaded from the backup file if possible, and a pri- mary server is then consulted to check that the zone is still up-to-date. 55..11..55.. CCaacchhiinngg OOnnllyy SSeerrvveerr 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 .. _r_o_o_t.._c_a_c_h_e SSMMMM::1111--88 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD All cache files listed will be read in at named boot time and any values still valid will be rein- stated in the cache and the root nameserver infor- mation in the cache files will always be used. 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. 55..11..66.. FFoorrwwaarrddeerrss Any server can make use of _f_o_r_- _w_a_r_d_e_r_s. A _f_o_r_w_a_r_d_e_r is another server capable of processing recursive queries that is willing to try resolving queries on behalf of other systems. The _f_o_r_w_a_r_d_e_r_s command specifies forwarders by internet address as follows: _f_o_r_w_a_r_d_e_r_s _1_2_8.._3_2.._0.._1_0_1_2_8.._3_2.._0.._4 There are two main reasons for wanting to do so. First, the other systems may not have full network access and may be prevent from sending any IP pack- ets into the rest of the network and therefore must rely on a forwarder which does have access to the full net. The second reason is that the forwarder sees a union of all queries as they pass through his server and therefore he builds up a very rich cache of data compared to the cache in a typical workstation nameserver. In effect, the _f_o_r_w_a_r_d_e_r becomes a meta-cache that all hosts can benefit from, thereby reducing the total number of queries from that site to the rest of the net. 55..11..77.. SSllaavvee MMooddee Slave mode is used if the use of forwarders is the only possible way to resolve queries due to lack of full net access or if you wish to prevent the nameserver from using other than the listed forwarders. Slave mode is activated by placing the simple command _s_l_a_v_e in the bootfile. If _s_l_a_v_e is used, then you must specify forwarders. When in slave mode, the server will forward each query to each of the the forward- ers until an answer is found or the list of for- warders is exhausted. 55..11..88.. RReemmoottee SSeerrvveerr 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 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--99 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. 55..22.. CCaacchhee IInniittiiaalliizzaattiioonn 55..22..11.. rroooott..ccaacchhee The name server needs to know the servers that are the authoritative name servers for the root domain of the network. To do this we have to prime the name server's cache with the addresses of these higher authorities. The location of this file is specified in the boot file. This file uses the Standard Resource Record Format (aka. Masterfile Format) covered further on in this paper. 55..33.. DDoommaaiinn DDaattaa FFiilleess 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. 55..33..11.. nnaammeedd..llooccaall 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. 55..33..22.. hhoossttss This file contains all the data about the machines in this zone. The location of this file is specified in the boot file. 55..33..33.. hhoossttss..rreevv 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 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. SSMMMM::1111--1100 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 55..44.. SSttaannddaarrdd RReessoouurrccee RReeccoorrdd FFoorrmmaatt The records in the name server data files are called resource records. The Standard Resource Record Format (RR) is specified in RFC1035. 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 and it must always start in column 1. 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; currently, only one class is supported: _I_N for inter- net addresses and other information. The fourth field states the type of the resource record. The fields after that are dependent 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. TThhee ffoolllloowwiinngg cchhaarraacctteerrss hhaavvee ssppeecciiaall mmeeaanniinnggss:: .. 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 checked for special meaning. ( ) Parentheses are used to group data that crosses a line. In effect, line terminations are not recog- nized within parentheses. NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--1111 ; 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 ``..''. 55..44..11.. $$IINNCCLLUUDDEE 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. 55..44..22.. $$OORRIIGGIINN 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. 55..44..33.. SSOOAA -- SSttaarrtt OOff AAuutthhoorriittyy _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 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 86400 ) ; Minimum SSMMMM::1111--1122 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 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. 55..44..44.. NNSS -- NNaammee SSeerrvveerr {_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. 55..44..55.. AA -- AAddddrreessss {_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 should be one _A record for each address of the machine. 55..44..66.. HHIINNFFOO -- HHoosstt IInnffoorrmmaattiioonn {_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 IN 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 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--1133 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. There should be one _H_I_N_F_O record for each host. 55..44..77.. WWKKSS -- WWeellll KKnnoowwnn SSeerrvviicceess {_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. 55..44..88.. CCNNAAMMEE -- CCaannoonniiccaall NNaammee _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 the only record associated with the alias name; all other resource records should be associated with the canonical name and not with the alias. Any resource records that include a domain name as their value (e.g. NS or MX) should list the canoni- cal name, not the alias. 55..44..99.. PPTTRR -- DDoommaaiinn NNaammee PPooiinntteerr _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 SSMMMM::1111--1144 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 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. 55..44..1100.. MMBB -- MMaaiillbbooxx _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. (These records are currently for experimental use only.) 55..44..1111.. MMRR -- MMaaiill RReennaammee NNaammee _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. (These records are currently for experimental use only.) 55..44..1122.. MMIINNFFOO -- MMaaiillbbooxx IInnffoorrmmaattiioonn _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 person other than the sender. (These records are currently for experimental use only.) 55..44..1133.. MMGG -- MMaaiill GGrroouupp MMeemmbbeerr {_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 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--1155 _M_a_i_l _G_r_o_u_p, _M_G lists members of a mail group. (These records are currently for experimental use only.) 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.. 55..44..1144.. MMXX -- MMaaiill EExxcchhaannggeerr _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. 55..55.. SSaammppllee FFiilleess 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. SSMMMM::1111--1166 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 55..55..11.. BBoooott FFiillee 55..55..11..11.. PPrriimmaarryy MMaasstteerr SSeerrvveerr ; ; Boot file for Primary Master Name Server ; ; type domain source file or host ; directory /usr/local/domain primary Berkeley..Edu ucbhosts primary 32..128..in-addr..arpa ucbhosts..rev primary 0..0..127..in-addr..arpa named..local cache .. root..cache 55..55..11..22.. SSeeccoonnddaarryy MMaasstteerr SSeerrvveerr ; ; Boot file for Primary Master Name Server ; ; type domain source file or host ; directory /usr/local/domain secondary Berkeley..Edu 128..32..0..4 128..32..0..10 ucbhosts.bak secondary 32..128..in-addr..arpa 128..32..0..4 128..32..0..10 ucbhosts.rev.bak primary 0..0..127..in-addr..arpa named..local cache .. root..cache 55..55..11..33.. CCaacchhiinngg OOnnllyy SSeerrvveerr ; ; Boot file for Caching Only Name Server ; ; type domain source file or host ; directory /usr/local/domain cache .. root..cache primary 0..0..127..in-addr..arpa /etc/named..local NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--1177 55..55..22.. RReemmoottee SSeerrvveerr 55..55..22..11.. //eettcc//rreessoollvv..ccoonnff domain Berkeley..Edu nameserver 128..32..0..4 nameserver 128..32..0..10 55..55..33.. rroooott..ccaacchhee ; ; ; Initial cache data for root domain servers. ; .. 99999999 IN NS NIC..DDN..MIL.. 99999999 IN NS NS..NASA..GOV.. 99999999 IN NS TERP..UMD..EDU.. 99999999 IN NS A..ISI..EDU.. 99999999 IN NS AOS..BRL..MIL.. 99999999 IN NS GUNTER-ADAM..AF..MIL.. 99999999 IN NS C..NYSER..NET.. ; Prep the cache (hotwire the addresses).. NIC..DDN..MIL.. 99999999 IN A 10..0..0..51 NIC..DDN..MIL.. 99999999 IN A 26..0..0..73 NS..NASA..GOV.. 99999999 IN A 128..102..16..10 A..ISI..EDU.. 99999999 IN A 26..3..0..103 AOS..BRL..MIL.. 99999999 IN A 128..20..1..2 AOS..BRL..MIL.. 99999999 IN A 192..5..25..82 GUNTER-ADAM..AF..MIL.. 99999999 IN A 26..1..0..13 C..NYSER..NET.. 99999999 IN A 192..33..4..12 TERP..UMD..EDU.. 99999999 IN A 128..8..10..90 55..55..44.. nnaammeedd..llooccaall SSMMMM::1111--1188 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD @ IN SOA ucbvax..Berkeley..Edu. kjd..ucbvax..Berkeley..Edu.. ( 1 ; Serial 10800 1800 3600000 86400 ) IN NS ucbvax..Berkeley..Edu.. 1 IN PTR localhost.. NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--1199 55..55..55.. HHoossttss SSMMMM::1111--2200 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD ; ; @(#)ucb-hosts 1.2 (berkeley) 88/02/05 ; @ IN SOA ucbvax..Berkeley..Edu.. kjd..monet..Berkeley..Edu.. ( 1..2 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 86400 ) ; 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 IN HINFO VAX-11/780 UNIX arpa IN CNAME ucbarpa ernie IN A 128..32..6 IN HINFO VAX-11/780 UNIX ucbernie IN CNAME ernie monet IN A 128..32..7 IN A 128..32..130..6 IN HINFO VAX-11/750 UNIX ucbmonet IN CNAME monet ucbvax IN A 10..2..0..78 IN A 128..32..10 IN 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 IN HINFO Pro350 RT11 toybox IN MX 0 monet.Berkeley.Edu miriam IN MB vineyd.DEC.COM. postmistress IN MR Miriam 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.. NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--2211 55..55..66.. hhoosstt..rreevv ; ; @(#)ucb-hosts.rev 1.1 (Berkeley) 86/02/05 ; @ IN SOA ucbvax..Berkeley..Edu.. kjd..monet..Berkeley..Edu.. ( 1..1 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS ucbarpa..Berkeley..Edu.. IN NS ucbvax..Berkeley..Edu.. 0..0 IN PTR Berkeley-net..Berkeley..EDU.. IN A 255..255..255..0 0..130 IN PTR csdiv-net..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.. 66.. DDoommaaiinn MMaannaaggeemmeenntt This section contains information for starting, con- trolling and debugging _n_a_m_e_d. 66..11.. //eettcc//rrcc..llooccaall 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. DDoo NNoott 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. SSMMMM::1111--2222 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 66..22.. //eettcc//nnaammeedd..ppiidd 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 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. 66..33.. //eettcc//hhoossttss 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. 66..44.. SSiiggnnaallss 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. 66..44..11.. RReellooaadd 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. 66..44..22.. DDeebbuuggggiinngg 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 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--2233 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. 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. AACCKKNNOOWWLLEEDDGGEEMMEENNTTSS 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. SSMMMM::1111--2244 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD RREEFFEERREENNCCEESS [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. [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. [RFC1032] Stahl, M., "Domain Administrators Guide" _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 _1_0_3_2 Network Information Center, SRI International, Menlo Park, California. November 1987. [RFC1033] Lottor, M., "Domain Administrators Guide" _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 _1_0_3_3 Network Information Center, SRI International, Menlo Park, California. November 1987. [RFC1034] 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 _1_0_3_4 Network Information Center, SRI International, Menlo Park, California. November 1987. [RFC1035] 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 _1_0_3_5 Network Information Center, SRI Interna- tional, Menlo Park, California. November 1987. [RFC10101] Mockapetris, P., "DNS Encoding of Network Names and Other Types." _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 _1_1_0_1 Network Information Center, SRI Interna- tional, Menlo Park, California. April 1989. [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, NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1111--2255 Berkeley, Computer Science Division. May 1984.