NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD _R_e_l_e_a_s_e _4_._9_._5 _R_e_l_e_a_s_e_s _f_r_o_m _4_._9 Paul Vixie1 Internet Software Consortium La Honda, CA _R_e_l_e_a_s_e_s _t_h_r_o_u_g_h _4_._8_._3 Kevin J. Dunlap2 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) implements an Internet name server for BSD-derived operating sys- tems. The BIND consists of a server (or ``daemon'') called _n_a_m_e_d and a _r_e_s_o_l_v_e_r library. 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. The BIND server runs in the background, servicing queries on a ____________________ 1 This author was employed by Digital Equipment Corpora- tion's Network Systems Laboratory during the development and release of BIND 4.9. Release 4.9.2 was sponsored by Vixie Enterprises. Releases from 4.9.3 were sponsored by the In- ternet Software Consortium. 2 This author was an employee of Digital Equipment Corpo- ration'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. SSMMMM::1100--22 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD well known network port. The standard port for UDP and TCP is specified in _/_e_t_c_/_s_e_r_v_i_c_e_s. The _r_e_s_o_l_v_e_r is a set of routines residing in a system library that provides the interface that programs can use to access the domain name services. BIND is fully integrated into BSD (4.3 and later releases) 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 older host table lookup of information in the network hosts file _/_e_t_c_/_h_o_s_t_s. The default configuration for BSD uses BIND. 22.. TThhee NNaammee SSeerrvviiccee The basic function of the name server is to provide information about network objects by answering queries. The specifications for this name server are defined in RFC1034, RFC1035 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 ffttpp..rrss..iinntteerrnniicc..nneett. It is also recommended 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 dele- gated to the different organizations on the network responsible for it. The host table lookup routines require that the mas- ter file for the entire network be maintained at a cen- tral location by a few people. This works fine for small networks where there are only a few machines and the dif- ferent organizations responsible for them cooperate. But this does not work well for large networks where machines cross organizational boundaries. With the name server, the network can be broken into a hierarchy of domains. The name space is organized as a tree according to organizational or administrative bound- aries. Each node, called a _d_o_m_a_i_n, is given a label, and the name of the domain is the concatenation 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 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--33 of a host address for a host at the University of Cali- fornia, 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.. SSeeccuurriittyy This section examines some of the know security implications of various versions of BIND. Some of these have been used to attack the nameservers in the past. 33..11.. UUnnnneecceessssaarryy GGlluuee Unnecessary glue can lead to incorrect records being loaded into the server. This can result in con- nections going to the wrong machines. To prevent unnecessary glue being loaded, all the servers of zones being servered by a server and the servers of the parent zones need to be upgraded to BIND 4.9.3 or later. 33..22.. IInnsseerrttiioonn ooff ddaattaa iinnttoo aa zzoonnee tthhaatt iiss bbeeiinngg sseerrvveerreedd BIND versions prior to BIND 4.9.2 are subject to the insertion of resource records into zone that they are serving. 33..33.. DDeenniiaall ooff SSeerrvviiccee:: HHaasshh BBuugg EExxppllooiitt September 1996 saw the COM TLD subject to a denial of service attack by injecting into the DNS a record with a final label of COM, eight spaces and COM. This effected BIND 4.9.4 servers. Similar attacks are possible on BIND 4.9.3 and BIND 4.9.3-P1. It is recommend that you run a BIND 4.9.4-P1 or later server to avoid this exploit. 33..44.. DDeenniiaall ooff SSeerrvviiccee:: TTTTLL IInnccoonnssiisstteennccyy AAttttaacckkss If you are still using multiple TTL values within a RRset you can be subject to a denial of service attack. BIND 4.9.5 onwards uses multiple ttl values within a RRset to reject obviously bad RRset. SSMMMM::1100--44 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD It is recommend that you upgrade to BIND 4.9.5 or later as these server prevent you loading multiple TTL values and doesn't merge answers received across the network. 44.. TTyyppeess ooff ZZoonneess A ``zone'' is a point of delegation in the DNS tree. It contains all names from a certain point ``downward'' except those which are delegated to other zones. A ``delegation point'' has one or more _N_S records in the ``parent zone'', which should be matched by equivalent _N_S records at the root of the ``delegated zone'' (i.e., the ``@'' name in the zone file). Understanding the difference between a ``zone'' and a ``domain'' is crucial to the proper operation of a name server. As an example, consider the DEC.COM _d_o_m_a_i_n, which includes names such as POBOX1.PA.DEC.COM and QUAB- BIN.CRL.DEC.COM even though the DEC.COM _z_o_n_e includes only _d_e_l_e_g_a_t_i_o_n_s for the PA.DEC.COM and CRL.DEC.COM zones. A zone can map exactly to a single domain, but could also include only part of a domain (the rest of which could be delegated to other name servers). Techni- cally speaking, every name in the DNS tree is a ``domain'', even if it is ``terminal'', that is, has no ``subdomains''. Technically speaking, every subdomain is a domain and every domain except the root is also a sub- domain. The terminology is not intuitive and you would do well to read RFC's 1033, 1034, and 1035 to gain a com- plete understanding of this difficult and subtle topic. Though BIND is a _D_o_m_a_i_n Name Server, it deals pri- marily in terms of _z_o_n_e_s. The _p_r_i_m_a_r_y and _s_e_c_o_n_d_a_r_y dec- larations in the _n_a_m_e_d_._b_o_o_t file specify _z_o_n_e_s, not _d_o_m_a_i_n_s. When you ask someone if they are willing to be a secondary server for your ``domain'', you are actually asking for secondary service for some collection of _z_o_n_e_s. Each zone will have one ``primary'' server, which loads the zone contents from some local file which is edited by humans or perhaps generated mechanically from some other local file which is edited by humans. Then there will be some number of ``secondary'' servers, which load the zone contents using the IP/DNS protocol (that is, the secondary servers will contact the primary and fetch the zone using IP/TCP). This set of servers (the primary and all of the secondaries) should be listed in the _N_S records in the parent zone, which will constitute a ``delegation''. This set of servers must also be listed in the zone file itself, usually under the ``@'' NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--55 name which is a magic cookie that means the ``top level'' or ``root'' of current zone. You can list servers in the zone's top-level ``@'' _N_S records that are not in the parent's _N_S delegation, but you cannot list servers in the parent's delegation that are not present in the zone's ``@''. Any servers listed in the _N_S records must be configured as authoritative (either primary or sec- ondary) for the zone. If a server listed in a _N_S record is not authoritative, it will respond with a ``lame dele- gation'' when queried. 55.. TTyyppeess ooff SSeerrvveerrss Servers do not really have ``types''. A server can be a primary for some zones and a secondary for others, or it can be only a primary, or only a secondary, or it can serve no zones and just answer queries via its ``cache''. Previous versions of this document referred to servers as ``master'' and ``slave'' but we now feel that those distinctions -- and the assignment of a ``type'' to a name server -- are not useful. 55..11.. 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 zone. 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 _T_T_L (``Time To Live'') field which is maintained for all resource records. 55..22.. RReemmoottee SSeerrvveerr A Remote Server is an option given to people who would like to use a name server from 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 with- out 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. A host which has an _/_e_t_c_/_r_e_s_o_l_v_._c_o_n_f file listing only remote hosts, and which does not run a name server of its own, is sometimes called a Remote Server (because the actual server is remote?) but more often it is called simply a DNS Client. This kind of host is technically not a ``server'', since it has no cache and does not answer queries. SSMMMM::1100--66 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 55..33.. SSllaavvee SSeerrvveerr A Slave Server is a server that always forwards queries it cannot satisfy from its cache, to a fixed list of _f_o_r_w_a_r_d_i_n_g servers instead of interacting with the name servers 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 given site to interact with the rest of the Internet servers. A typical scenario would involve a number of workstations and a departmental timesharing machine with Internet access. The workstations might be administratively prohibited from having Internet access. To give the workstations the appearance of access to the Internet domain system, the workstations could be Slave servers to the timesharing machine which would forward the queries and interact with other name servers to resolve the query before return- ing the answer. An added benefit of using the for- warding feature is that the central machine develops a much more complete cache of information that all the workstations can take advantage of. The use of Slave mode and forwarding is discussed further under the description of the _n_a_m_e_d bootfile commands. There is no prohibition against declaring a server to be a _s_l_a_v_e even though it has _p_r_i_m_a_r_y and/or _s_e_c_o_n_d_a_r_y zones as well; the effect will still be that anything in the local server's cache or zones will be answered, and anything else will be forwarded using the _f_o_r_w_a_r_d_e_r_s list. 66.. 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. 66..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. NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--77 66..11..11.. DDoommaaiinn A default domain may be specified for the name server using a line such as _d_o_m_a_i_n _B_e_r_k_e_l_e_y.._E_d_u Older name servers use this information when they receive a query for a name without a ``..'' that is not known. Newer designs assume that the resolver library will append its own idea of a ``default domain'' to any unqualified names. Though the name server can still be compiled with support for the _d_o_m_a_i_n directive in the boot file, the default is to leave it out and we strenuously recommend against its use. If you use this feature, clients outside your local domain which send you requests about unqualified names will have the implicit qualification of your domain rather than theirs. The proper place for this function is on the client, in their //eettcc//rreessoollvv..ccoonnff (or equivalent) file. Use of the _d_o_m_a_i_n directive in your boot file is strongly discouraged. 66..11..22.. DDiirreeccttoorryy The _d_i_r_e_c_t_o_r_y directive specifies the direc- tory in which the name server should run, allowing the other file names in the boot file to use rela- tive path names. There can be only one _d_i_r_e_c_t_o_r_y directive and it should be given before any other directives that specify file names. _d_i_r_e_c_t_o_r_y _/_v_a_r_/_n_a_m_e_d 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 /var/named 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 named to run in a location that is reasonable to dump core if it feels the urge. 66..11..33.. PPrriimmaarryy SSeerrvviiccee The line in the boot file that designates the server as a primary master server for a zone looks as follows: _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 SSMMMM::1100--88 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 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. The above assumes that the zone you are speci- fying is a class _I_N zone. If you wish to designate a different class you can append _/_c_l_a_s_s to the first field, where _c_l_a_s_s is either the integer value or the standard mnemonic for the class. For example the line for a primary server for a hesiod class zone looks as follows: _p_r_i_m_a_r_y_/_H_S _B_e_r_k_e_l_e_y.._E_d_u _h_e_s_i_o_d_._d_a_t_a Note that this support for specifying other than class _I_N zones is a compile-time option which your vendor may not have enabled when they built your operating system. 66..11..44.. SSeeccoonnddaarryy SSeerrvviiccee 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 sec- ondary server for the zone stated in the second field. The two network addresses specify the name servers which have data for the zone. Note that at least one of these will be a _p_r_i_m_a_r_y, and, unless you are using some protocol other than IP/DNS for your zone transfer mechanism, the others will all be other _s_e_c_o_n_d_a_r_y servers. Having your secondary server pull data from other secondary servers is usually unwise, since you can add delay to the propagation of zone updates if your network's con- nectivity varies in pathological but common ways. The intended use for multiple addresses on a _s_e_c_- _o_n_d_a_r_y declaration is when the _p_r_i_m_a_r_y server has multiple network interfaces and therefore multiple host addresses. The secondary server gets its data across the network from one of the listed servers. The server addresses are tried in the order listed. 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 is loaded from the backup file if possible, and a primary server is then consulted to check that the zone is still up-to-date. Note that NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--99 listing your server as a _s_e_c_o_n_d_a_r_y server does not necessarily make it one -- the parent zone must _d_e_l_e_g_a_t_e authority to your server as well as the primary and the other secondaries, or you will be transferring a zone over for no reason; no other server will have a reason to query you for that zone unless the parent zone lists you as a server for the zone. As with primary you may specify a secondary server for a class other than _I_N by appending _/_c_l_a_s_s to the _s_e_c_o_n_d_a_r_y keyword, e.g., _s_e_c_- _o_n_d_a_r_y_/_H_S. 66..11..55.. SSttuubb SSeerrvviiccee The line for a stub server is similar to a secondary. (This feature is experimental as of 4.9.3.) _s_t_u_b _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 stub server for the zone stated in the second field. Stub zones are intended to ensure that a pri- mary for a zone always has the correct _N_S records for children of that zone. If the primary is not a secondary for a child zone it should be configured with stub zones for all its children. Stub zones provide a mechanism to allow _N_S records for a zone to be specified in only one place. _p_r_i_m_a_r_y _C_S_I_R_O.._A_U _c_s_i_r_o_._d_a_t _s_t_u_b _d_m_s_._C_S_I_R_O.._A_U _1_3_0.._1_5_5.._1_6.._1 _d_m_s_._s_t_u_b _s_t_u_b _d_a_p_._C_S_I_R_O.._A_U _1_3_0.._1_5_5.._9_8.._1 _d_a_p_._s_t_u_b 66..11..66.. CCaacchhee IInniittiiaalliizzaattiioonn All servers, including ``caching only'' 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 Do not put anything into your _c_a_c_h_e files other than root server information. All cache files listed will be read in at named boot time and any values still valid will be reinstated in the cache. The root name server information in the cache files will be used until a SSMMMM::1100--1100 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD root query is actually answered by one of the name servers in the cache file, after which that answer will be used instead of the cache file until the answer times out. As with _p_r_i_m_a_r_y and _s_e_c_o_n_d_a_r_y, you may specify a secondary server for a class other than _I_N by appending _/_c_l_a_s_s to the _c_a_c_h_e keyword, e.g., _c_l_a_s_s_/_H_S. 66..11..77.. 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, some systems may not have full network access and may be prevented from sending any IP packets into the rest of the Internet and therefore must rely on a forwarder which does have access to the full net. The second reason is that the for- warder sees a union of all queries as they pass through its server and therefore it builds up a very rich cache of data compared to the cache in a typical workstation name server. 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. The effect of ``forwarders'' is to prepend some fixed addresses to the list of name servers to be tried for every query. Normally that list is made up only of higher-authority servers discovered via _N_S record lookups for the relevant domain. If the forwarders do not answer, then unless the _s_l_a_v_e directive was given, the appropriate servers for the domains will be queried directly. 66..11..88.. SSllaavvee SSeerrvveerrss 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 name server from using other than the listed forwarders. Slave mode is activated by placing the simple command NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--1111 _o_p_t_i_o_n_s _f_o_r_w_a_r_d_-_o_n_l_y in the bootfile. If this option is used, then you must specify forwarders. When in slave mode, the server will forward each query to each of the for- warders until an answer is found or the list of forwarders is exhausted. The server will not try to contact any remote name server other than those named in the _f_o_r_w_a_r_d_e_r_s list. So while _f_o_r_w_a_r_d_e_r_s prepends addresses to the ``server list'' for each query, _o_p_t_i_o_n_s _f_o_r_w_a_r_d_- _o_n_l_y causes the ``server list'' to contain _o_n_l_y those addresses listed in the _f_o_r_w_a_r_d_e_r_s declara- tions. Careless use of the _o_p_t_i_o_n_s _f_o_r_w_a_r_d_-_o_n_l_y directive can cause really horrible forwarding loops, since you could end up forwarding queries only to some set of hosts which are also slaves, and one or several of them could be forwarding queries back to you. Use of the _o_p_t_i_o_n_s _f_o_r_w_a_r_d_-_o_n_l_y directive should be considered very carefully. Note that this same behaviour can be achieved using the dep- recated directive, _s_l_a_v_e. 66..11..99.. NNoonnrreeccuurrssiivvee SSeerrvveerrss BIND's separation of authoritative (zone) and nonauthoritiative (cache) data has always been somewhat weak, and pollution of the former via the latter has been known to occur. One way to prevent this, as well as to save memory on servers carrying a lot of authoritative data (e.g., root servers) is to make such servers ``nonrecursive.'' This can be achieved via the directive _o_p_t_i_o_n_s _n_o_-_r_e_c_u_r_s_i_o_n in the bootfile. A server with this option enabled will not attempt to fetch data to help answer queries -- if you ask it for data it does not have, it will send you a referral to a more authoritative server or, if it is itself authoritative for the zone of the query, it will send you an negative answer. A nonrecursive server can be named in an NS RR but it cannot be listed in the _r_e_s_o_l_v_._c_o_n_f file. SSMMMM::1100--1122 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 66..11..1100.. QQuueerryy LLooggggiinngg If the file system containing your _s_y_s_l_o_g file has quite a bit of space, you can consider using the _o_p_t_i_o_n_s _q_u_e_r_y_-_l_o_g directive in your bootfile. This will cause your name server to log every query it receives, which when combined with a Perl or AWK script to postpro- cess the logs, can be a useful management tool. 66..11..1111.. IInnvveerrssee QQuueerryy PPsseeuuddoossuuppppoorrtt BIND by default does not support inverse queries, and this has been known to cause problems for certain microcomputer operating systems and for older versions of BIND's _n_s_l_o_o_k_u_p tool. You may decide that rather than answering with ``operation not implemented,'' _n_a_m_e_d should detect the most common inverse queries and answer them with bogus information. It is better to upgrade your clients to stop depending on inverse queries, but if that is not possible, you should use the _o_p_t_i_o_n_s _f_a_k_e_-_i_q_u_e_r_y directive in your bootfile. _N_O_T_E_: the responses are in fact bogus, in that they contain ISO8859 square brackets ([[ and ]]), so your clients will not be able to do anything useful with these responses. It has been observed that no client ever did any- thing useful with real inverse query responses, either. 66..11..1122.. SSeettttiinngg NNaammee SSeerrvveerr LLiimmiittss Some name server operations can be quite resource intensive, and in order to tune your sys- tem properly it is sometimes necessary to change BIND's internal quotas. This is accomplished via _l_i_m_i_t _<_n_a_m_e_> _<_v_a_l_u_e_> directives in the bootfile. Limits, and their default values, are as follows: _l_i_m_i_t _t_r_a_n_s_f_e_r_s_-_i_n _1_0 This is the number of simultaneous _n_a_m_e_d_-_x_f_e_r NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--1133 processes BIND is willing to start. Higher numbers yield faster convergence to primary servers if your secondary server has hundreds or thousands of zones to maintain, but setting this number too high can cause thrashing due to starvation of resources such as network bandwidth or swap space. _N_O_T_E_: this limit can also be expressed via the deprecated directive _m_a_x_-_f_e_t_c_h _N_N. _l_i_m_i_t _t_r_a_n_s_f_e_r_s_-_p_e_r_-_n_s _2 This is the number of simultaneous _n_a_m_e_d_-_x_f_e_r pro- cesses BIND is willing to initiate _t_o _a_n_y _g_i_v_e_n _n_a_m_e _s_e_r_v_e_r. In most cases, you should not need to change it. If your secondary server is pulling hundreds or thousands of zones from a single pri- mary server, increasing _t_r_a_n_s_f_e_r_s_-_p_e_r_-_n_s may speed convergence. It should be kept as small as possi- ble, to avoid causing thrashing and resource star- vation on the primary server. _l_i_m_i_t _d_a_t_a_s_i_z_e _<_s_y_s_t_e_m_-_d_e_p_e_n_d_e_n_t_> Most systems have a quota that limits the size of the so-called ``data segment,'' which is where BIND keeps all of its authority and cache data. BIND will behave suboptimally (perhaps even exiting) if it runs up against this quota. If your system sup- ports a system call to change this quota for a given process, you can ask BIND to use that system call via the _l_i_m_i_t _d_a_t_a_s_i_z_e _N_N directive. The value given here may be scaled by postfixing _k for 1024X, _m for (1024^2)X, and _g for (1024^3)X. In 1995, the root servers all use _l_i_m_i_t _d_a_t_a_s_i_z_e _6_4_m. 66..11..1133.. ZZoonnee TTrraannssffeerr RReessttrriiccttiioonnss It may be the case that your organization does not wish to give complete lists of your hosts to anyone on the Internet who can reach your name servers. While it is still possible for people to ``iterate'' through your address range, looking for _P_T_R records, and build a list of your hosts the ``slow'' way, it is still considered reasonable to restrict your export of zones via the zone transfer protocol. To limit the list of neighbors who can transfer zones from your server, use the _x_f_r_n_e_t_s directive. This directive has the same syntax as _f_o_r_- _w_a_r_d_e_r_s except that you can list network numbers in addition to host addresses. For example, you could SSMMMM::1100--1144 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD add the directive _x_f_r_n_e_t_s _1_6_._0_._0_._0 if you wanted to permit only hosts on Class A net- work number 16 to transfer zones from your server. This is not nearly granular enough, and a future version of BIND will permit such access-control to be specified on a per-host basis rather than the current per-net basis. Note that while addresses without explicit masks are assumed by this direc- tive to be networks, you can specify a mask which is as granular as you wish, perhaps including all bits of the address such that only a single host is given transfer permission. For example, consider _x_f_r_n_e_t_s _1_6_._1_._0_._2_&_2_5_5_._2_5_5_._2_5_5_._2_5_5 which would permit only host _1_6_._1_._0_._2 to transfer zones from you. Note that no spaces are allowed surrounding the ``_&'' character that introduces a netmask. The _x_f_r_n_e_t_s directive may also be given as _t_c_p_l_i_s_t for compatibility with interim releases of BIND 4.9. 66..11..1144.. SSoorrttiinngg AAddddrreesssseess If there are multiple addresses available for a name server which BIND wants to contact, BIND will try the ones it believes are ``closest'' first. ``Closeness'' is defined in terms of simi- larity-of-address; that is, if one address is on the same _s_u_b_n_e_t as some interface of the local host, then that address will be tried first. Fail- ing that, an address which is on the same _n_e_t_w_o_r_k will be tried first. Failing that, they will be tried in a more-or-less random order unless the _s_o_r_t_l_i_s_t directive was given in the _n_a_m_e_d_._b_o_o_t file. _s_o_r_t_l_i_s_t has a syntax similar to _f_o_r_w_a_r_d_e_r_s, _x_f_r_n_e_t_s, and _b_o_g_u_s_n_s -- you give it a list of dot- ted-quad networks and it uses these to ``prefer'' some remote name server addresses over others. If no explicit mask is provided with each element of a _s_o_r_t_l_i_s_t, one will be inferred based on the high order address bits. If you are on a Class C net which has a Class B net between you and the rest of the Internet, you could try to improve the name server's luck in get- ting answers by listing the Class B network's NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--1155 number in a _s_o_r_t_l_i_s_t directive. This should have the effect of trying ``closer'' servers before the more ``distant'' ones. Note that this behaviour is new as of BIND 4.9. The other and older effect of the _s_o_r_t_l_i_s_t directive is to cause BIND to sort the _A records in any response it generates, so as to put those which appear on the _s_o_r_t_l_i_s_t earlier than those which do not. This is not as helpful as you might think, since many clients will reorder the _A records either at random or using LIFO; also, consider the fact that the server won't be able to guess the client's network topology, and so will not be able to accurately order for ``closeness'' to all possi- ble clients. Doing the ordering in the resolver is clearly superior. In actual practice, this directive is used only rarely since it hardwires information which changes rapidly; a network which is ``close'' today may be ``distant'' next month. Since BIND builds up a cache of the remote name servers' response times, it will quickly converge on ``reasonable'' behaviour, which isn't the same as ``optimal'' but it's close enough. Future directions for BIND include choosing addresses based on local interface metrics (on hosts that have more than one) and per- haps on routing table information. We do not intend to solve the generalized ``multihomed host'' problem, but we should be able to do a little bet- ter than we're doing now. Likewise, we hope to see a higher level resolver library that sorts responses using topology information that only exists on the client's host. 66..11..1155.. BBoogguuss NNaammee SSeerrvveerrss It happens occasionally that some remote name server goes ``bad''. You can tell your name server to refuse to listen to or ask questions of certain other name servers by listing them in a _b_o_g_u_s_n_s directive in your _n_a_m_e_d_._b_o_o_t file. Its syntax is the same as _f_o_r_w_a_r_d_e_r_s, _x_f_r_n_e_t_s, and _s_o_r_t_l_i_s_t -- you just give it a list of dotted-quad Internet addresses. Note that zones delegated to such servers will not be reachable from clients of your servers; thus you should use this directive spar- ingly or not at all. SSMMMM::1100--1166 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 66..11..1166.. SSeeggmmeenntteedd BBoooott FFiilleess If you are secondary for a lot of zones, you may find it convenient to split your _n_a_m_e_d_._b_o_o_t file into a static portion which hardly ever changes (directives such as _d_i_r_e_c_t_o_r_y, _s_o_r_t_l_i_s_t, _x_f_r_n_e_t_s and _c_a_c_h_e could go here), and dynamic por- tions that change frequently (all of your _p_r_i_m_a_r_y directives might go in one file, and all of your _s_e_c_o_n_d_a_r_y directives might go in another file -- and either or both of these might be fetched auto- matically from some neighbor so that they can change your list of secondary zones without requir- ing your active intervention). You can accomplish this via the _i_n_c_l_u_d_e directive, which takes just a single file name as its argument. No quotes are needed around the file name. The file name will be evaluated after the name server has changed its working directory to that specified in the _d_i_r_e_c_- _t_o_r_y directive, so you can use relative pathnames if your system supports them. 66..22.. RReessoollvveerr CCoonnffiigguurraattiioonn The configuration file's name is _/_e_t_c_/_r_e_s_o_l_v_._c_o_n_f. This file designates the name servers on the network that should be sent queries. The resolver will try to contact a name server on the localhost if it cannot find its configuration file. You should install the configuration file on every host anyway, since this is the only recommended way to specify a system-level default domain, and you can still list the local host's address if it runs a name server. It is considered reasonable to create this file even if you run a local server, since its con- tents will be cached by each client of the resolver library when the client makes its first call to a resolver routine. The _r_e_s_o_l_v_._c_o_n_f file contains directives, one per line, of the following forms: ; comment # another comment domain _l_o_c_a_l_-_d_o_m_a_i_n search _s_e_a_r_c_h_-_l_i_s_t nameserver _s_e_r_v_e_r_-_a_d_d_r_e_s_s sortlist _s_o_r_t_-_l_i_s_t options _o_p_t_i_o_n_-_l_i_s_t Exactly one of the _d_o_m_a_i_n or _s_e_a_r_c_h directives should be given, exactly once. If the _s_e_a_r_c_h directive is NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--1177 given, the first item in the given _s_e_a_r_c_h_-_l_i_s_t will override any previously-specified _l_o_c_a_l_-_d_o_m_a_i_n. The _n_a_m_e_s_e_r_v_e_r directive may be given up to three times; additional _n_a_m_e_s_e_r_v_e_r directives will be ignored. Comments may be given by starting a line with a ``;;'' or ``##''; note that comments were not permitted in versions of the resolver earlier than the one included with BIND 4.9 -- so if your vendor's resolver supports comments, you know they are really on the ball. The _l_o_c_a_l_-_d_o_m_a_i_n will be appended to any query- name that does not contain a ``..''. _l_o_c_a_l_-_d_o_m_a_i_n can be overridden on a per-process basis by setting the LOCALDOMAIN environment variable. Note that _l_o_c_a_l_- _d_o_m_a_i_n processing can be disabled by setting an option in the resolver. The _s_e_a_r_c_h_-_l_i_s_t is a list of domains which are tried, in order, as qualifying domains for query-names which do not contain a ``..''. Note that _s_e_a_r_c_h_-_l_i_s_t processing can be disabled by setting an option in the resolver. Also note that the environment variable ``LOCALDOMAIN'' can override this _s_e_a_r_c_h_-_l_i_s_t on a per-process basis. The _s_e_r_v_e_r_-_a_d_d_r_e_s_s's are aggregated and then used as the default destination of queries generated through the resolver. In other words, this is the way you tell the resolver which name servers it should use. It is possible for a given client application to override this list, and this is often done inside the name server (which is itself a _r_e_s_o_l_v_e_r client) and in test programs such as _n_s_l_o_o_k_u_p. Note that if you wish to list the local host in your resolver configuration file, you should probably use its primary Internet address rather than a local-host alias such as 127.0.0.1 or 0.0.0.0. This is due to a bug in the handling of connected SOCK_DGRAM sockets in some ver- sions of the BSD networking code. If you must use an address-alias, you should prefer 0.0.0.0 (or simply ``0'') over 127.0.0.1, though be warned that depending on the vintage of your BSD-derived networking code, both of them are capable of failing in their own ways. If your host's IP implementation does not create a short-circuit route between the default interface and the loopback interface, then you might also want to add a static route (eg. in //eettcc//rrcc..llooccaall) to do so: _r_o_u_t_e _a_d_d _m_y_h_o_s_t_._d_o_m_a_i_n_._n_a_m_e _l_o_c_a_l_h_o_s_t _1 The _s_o_r_t_-_l_i_s_t is a list of IP address, netmask pairs. Addresses returned by gethostbyname are sorted SSMMMM::1100--1188 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD to the order specified by this list. Any addresses that do not match the address netmask pair will be returned after those that do. The netmask is optional and the natural netmask will be used if not specified. The _o_p_t_i_o_n_-_l_i_s_t is a list of options which each override some internal resolver variable. Supported options at this time are: ddeebbuugg sets the RES_DEBUG bit in __rreess..ooppttiioonnss. nnddoottss::_n sets the lower threshold (measured in ``number of dots'') on names given to _r_e_s___q_u_e_r_y() such that names with more than this number of dots will be tried as absolute names before any _l_o_c_a_l_-_d_o_m_a_i_n or _s_e_a_r_c_h_-_l_i_s_t processing is done. The default for this internal variable is ``1''. 66..33.. CCaacchhee IInniittiiaalliizzaattiioonn FFiillee 66..33..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. 66..44.. DDoommaaiinn DDaattaa FFiilleess There are two standard files for specifying the data for a domain. These are _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. Note that the file names are arbitrary; many network administrators prefer to name their zone files after the domains they contain, especially in the average case which is where a given server is primary and/or secondary for many different zones. 66..44..11.. hhoossttss This file contains all the data about the machines in this zone. The location of this file is specified in the boot file. NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--1199 66..44..22.. 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 speci- fied even if an octet contains 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 natu- ral grouping of hosts in a network. 66..44..33.. nnaammeedd..llooccaall This file specifies the _P_T_R record for the local loopback interface, better known as _l_o_c_a_l_- _h_o_s_t, whose network address is 127.0.0.1. The location of this file is specified in the boot file. It is vitally important to the proper opera- tion of every name server that the 127.0.0.1 address have a _P_T_R record pointing back to the name ``llooccaallhhoosstt..''. The name of this _P_T_R record is always ``11..00..00..112277..IINN--AADDDDRR..AARRPPAA''. This is neces- sary if you want your users to be able to use host- name-authentication (_h_o_s_t_s_._e_q_u_i_v or _~_/_._r_h_o_s_t_s) on the name ``llooccaallhhoosstt''. As implied by this _P_T_R record, there should be a ``llooccaallhhoosstt.._m_y_._d_o_m_._a_i_n'' _A record (with address 127.0.0.1) in every domain that contains hosts. ``llooccaallhhoosstt..'' will lose its trailing dot when 11..00..00..112277..iinn--aaddddrr..aarrppaa is queried for; then, the DEFNAMES and/or DNSRCH resolver options will cause ``llooccaallhhoosstt'' to be evaluated as a host name in the local domain, and that means the top domains (or ideally, every domain) in your resolver's search path had better have something by that name. 66..55.. 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 SSMMMM::1100--2200 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD record and it must always start in column 1. For all RR's other than the first in a file, 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 internet addresses and other internet information. Limited support is included for the _H_S class, which is for MIT/Athena ``Hesiod'' 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 root domain. ``@'' A free standing @ in the name field denotes the current origin. ``\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 rec- ognized within parentheses. (At present, this notation only works for SOA RR's and is not optional.) ``;'' Semicolon starts a comment; the remainder of the line is ignored. Note that a completely blank line is also considered a comment, and ignored. NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--2211 ``*'' An asterisk signifies wildcarding. Note that this is just another data character whose special meaning comes about only during internal name server search operations. Wildcarding is only meaningful for some RR types (notably _M_X), and then only in the name field -- not in the data fields. Anywhere a name appears -- either in the name field or in some data field defined to contain names -- the current origin will be appended if the name does not end in 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 the domain for which you are creating the data file, end the name with a ``..''. 66..55..11.. $$IINNCCLLUUDDEE An include line begins with $INCLUDE, starting in column 1, and is followed by a file name, and, optionally, by a new temporary $ORIGIN to be used while reading this file. This feature is particu- larly useful for separating different types of data into multiple files. An example would be: $INCLUDE /usr/local/adm/named/data/mail-exchanges The line would be interpreted as a request to load the file _/_u_s_r_/_l_o_c_a_l_/_a_d_m_/_n_a_m_e_d_/_d_a_t_a_/_m_a_i_l_-_e_x_c_h_a_n_g_e_s. The $INCLUDE command does not cause data to be loaded into a different zone or tree. This is sim- ply a way to allow data for a given primary zone to be organized in separate files. Not even the ``temporary $ORIGIN'' feature described above is sufficient to cause your data to branch out into some other zone -- zone boundaries can only be introduced in the boot file. A $INCLUDE file must have a name on its first RR. That is, the first character of the first non- comment line must not be a space. The current default name in the parent file _d_o_e_s _n_o_t carry into the $INCLUDE file. 66..55..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 seems like it could be useful for putting more then one zone into SSMMMM::1100--2222 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD a data file, but that's not how it works. The name server fundamentally requires a given zone to map entirely to some specific file. You should there- fore be very careful to use $ORIGIN only once at the top of a file, or, within a file, to change to a ``lower'' domain in the zone -- never to some other zone altogether. 66..55..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.. ( 1995122103 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 259200 ) ; 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 and is often given as ``@'' since this is always the current $ORIGIN and the SOA RR is usually the first record of the primary zone file. Origin is the name of the host on which this data file resides (in other words, the _p_r_i_m_a_r_y _m_a_s_t_e_r server for this zone.) Person in charge is the e-mail address for the person responsible for the name server, with ``@'' changed to a ``.''. The serial number is the version number of this data file and must be a positive integer. This number must be incremented whenever a change is made to the data. Older servers permitted the use of a phantom ``.'' in this and other numbers in a zone file; the mean- ing of n.m was ``n000m'' rather than the more intu- itive ``n*1000+m'' (such that 1.234 translated to 1000234 rather than to 1234). This feature has been deprecated due to its obscurity, unpre- dictability, and lack of necessity. Note that using a ``YYYYMMDDNN'' notation you can still make 100 changes per day until the year 4294. You should choose a notation that works for you. If you're a clever _p_e_r_l programmer you could even use _R_C_S version numbers to help generate your zone serial numbers. The refresh indicates how often, in seconds, the secondary name servers are to check with the primary name server to see if an update is needed. The retry indicates how long, in seconds, a secondary server should wait before retrying a failed zone transfer. Expire is the upper limit, in seconds, that a secondary name server is to use NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--2233 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 which do not specify one in the zone file. It is also an enforced minimum on Time To Live if it is specified on some resource record (RR) in the zone. There must be exactly one _S_O_A record per zone. 66..55..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, creating a _d_e_l_e_g_a_- _t_i_o_n _p_o_i_n_t and a _s_u_b_z_o_n_e. The first name field specifies the zone that is serviced by the name server specified by the second name. Every zone needs at least two name servers. SSMMMM::1100--2244 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 66..55..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. 66..55..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 operating system that are running at the listed host. If you want to include a space in the machine name you must quote the name (using ``"'' characters.) There could be one _H_I_N_F_O record for each host, though for security reasons most domains don't have any _H_I_N_F_O records at all. No applica- tion depends on them. 66..55..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. Note that RFC1123 says of _W_K_S records: NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--2255 2.2 Using Domain Name Service ... An application SHOULD NOT rely on the ability to locate a WKS record containing an accurate listing of all services at a particular host address, since the WKS RR type is not often used by Internet sites. To confirm that a service is present, simply attempt to use it. ... 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 RFC-974 [SMTP:3] recommended that the domain system be queried for WKS ("Well-Known Service") records, to verify that each proposed mail target does support SMTP. Later experience has shown that WKS is not widely supported, so the WKS step in MX processing SHOULD NOT be used. ... 6.1.3.6 Status of RR Types ... The TXT and WKS RR types have not been widely used by Internet sites; as a result, an application cannot rely on the existence of a TXT or WKS RR in most domains. 66..55..88.. CCNNAAMMEE -- CCaannoonniiccaall NNaammee _a_l_i_a_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 The _C_a_n_o_n_i_c_a_l _N_a_m_e resource record, _C_N_A_M_E, speci- fies an alias or nickname for the official, or canonical, host name. This record must be the only one associated with the alias name. All other resource records must be associated with the canon- ical name, not with the nickname. Any resource records that include a domain name as their value (e.g., NS or MX) _m_u_s_t list the canonical name, not the nickname. Similarly, a CNAME will be followed when searching for A RRs, but not for MX RRs or NS RRs or most other types of RRs. CNAMEs are allowed to point to other CNAMEs, but this is considered sloppy. Nicknames are useful when a well known host changes its name. In that case, it is usually a good idea to have a _C_N_A_M_E record so that people still using the old name will get to the right place. SSMMMM::1100--2266 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 66..55..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 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 records are needed by the _g_e_t_h_o_s_t_b_y_a_d_d_r function. Note the trailing ``..'' which prevents BIND from appending the current $ORIGIN to that domain name. 66..55..1100.. MMXX -- MMaaiill EExxcchhaannggee _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_x_c_h_a_n_g_e Munnari..OZ..AU.. IN MX 0 Seismo..CSS..GOV.. *..IL.. IN MX 0 RELAY..CS..NET.. _M_a_i_l _e_X_c_h_a_n_g_e records, _M_X, are used to specify a list of hosts which are configured to receive mail sent to this domain name. Every name which receives mail should have an _M_X since if one is not found at the time mail is being delivered, an _M_X will be ``imputed'' with a cost of 0 and a destina- tion of the host itself. If you want a host to receive its own mail, you should create an _M_X for your host's name, pointing at your host's name. It is better to have this be explicit than to let it be imputed by remote mailers. In the first exam- ple, above, Seismo..CSS..GOV.. is a mail gateway that knows how to deliver mail to Munnari..OZ..AU... 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 than one way to deliver mail to a single machine. Note that lower numbers indicate higher precedence, and that mailers are supposed to ran- domize same-valued _M_X hosts so as to distribute the load evenly if the costs are equal. 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 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--2277 of RELAY.CS.NET. Wildcard _M_X records are not very useful in practice, though, since once a mail mes- sage gets to the gateway for a given domain it still has to be routed _w_i_t_h_i_n that domain and it is not currently possible to have an apparently-dif- ferent set of _M_X records inside and outside of a domain. If you won't be needing any Mail Exchanges inside your domain, go ahead and use a wildcard. If you want to use both wildcard ``top-level'' and specific ``interior'' _M_X records, note that each specific record will have to ``end with'' a com- plete recitation of the same data that is carried in the top-level record. This is because the spe- cific _M_X records will take precedence over the top- level wildcard records, and must be able to perform the top-level's if a given interior domain is to be able to receive mail from outside the gateway. Wildcard _M_X records are very subtle and you should be careful with them. 66..55..1111.. TTXXTT -- TTeexxtt _n_a_m_e _{_t_t_l_} _a_d_d_r_-_c_l_a_s_s _T_X_T _s_t_r_i_n_g Munnari..OZ..AU.. IN TXT "foo" A _T_X_T record contains free-form textual data. The syntax of the text depends on the domain where it is found; many systems use _T_X_T records to encode local data in a stylized format. MIT Hesiod is one such system. 66..55..1122.. RRPP -- RReessppoonnssiibbllee PPeerrssoonn _o_w_n_e_r _{_t_t_l_} _a_d_d_r_-_c_l_a_s_s _R_P _m_b_o_x_-_d_o_m_a_i_n_-_n_a_m_e _T_X_T_-_d_o_m_a_i_n_-_n_a_m_e franklin IN RP ben.franklin.berkeley.edu. sysadmins.berkeley.edu. The Responsible Person record, _R_P, identifies the name or group name of the responsible person for a host. Often it is desirable to be able to identify the responsible entity for a particular host. When that host is down or malfunctioning, you would want to contact those parties who might be able to repair the host. The first field, _m_b_o_x_-_d_o_m_a_i_n_-_n_a_m_e, is a domain name that specifies the mailbox for the responsible person. Its format in a zone file uses the DNS convention for mailbox encoding, identical to that used for the _P_e_r_s_o_n_-_i_n_-_c_h_a_r_g_e mailbox field in the SOA record. In the example above, the _m_b_o_x_-_d_o_m_a_i_n_- _n_a_m_e shows the encoding for SSMMMM::1100--2288 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD ``<>''. The root domain name (just ``..'') may be specified to indicate that no mailbox is available. The second field, _T_X_T_-_d_o_m_a_i_n_-_n_a_m_e, is a domain name for which _T_X_T records exist. A subsequent query can be performed to retrieve the associated _T_X_T resource records at _T_X_T_-_d_o_m_a_i_n_-_n_a_m_e. This pro- vides a level of indirection so that the entity can be referred to from multiple places in the DNS. The root domain name (just ``..'') may be specified for _T_X_T_-_d_o_m_a_i_n_-_n_a_m_e _t_o _i_n_d_i_c_a_t_e _t_h_a_t _n_o _a_s_s_o_c_i_a_t_e_d _T_X_T _R_R _e_x_i_s_t_s_. _I_n _t_h_e _e_x_a_m_p_l_e _a_b_o_v_e_, _`_`ssyyssaadd-- mmiinnss..bbeerrkkeelleeyy..eedduu.._'_' _i_s _t_h_e _n_a_m_e _o_f _a _T_X_T _r_e_c_o_r_d _t_h_a_t _m_i_g_h_t _c_o_n_t_a_i_n _s_o_m_e _t_e_x_t _w_i_t_h _n_a_m_e_s _a_n_d _p_h_o_n_e _n_u_m_b_e_r_s_. The format of the _R_P record is class-insensi- tive. Multiple _R_P records at a single name may be present in the database, though they should have identical TTLs. The _R_P record is still experimental; not all name servers implement or recognize it. 66..55..1133.. AAFFSSDDBB -- DDCCEE oorr AAFFSS SSeerrvveerr _n_a_m_e _{_t_t_l_} _a_d_d_r_-_c_l_a_s_s _A_F_S_D_B _s_u_b_t_y_p_e _s_e_r_v_e_r _h_o_s_t _n_a_m_e toaster.com. IN AFSDB 1 jack.toaster.com. toaster.com. IN AFSDB 1 jill.toaster.com. toaster.com. IN AFSDB 2 tracker.toaster.com. _A_F_S_D_B records are used to specify the hosts that provide a style of distributed service advertised under this domain name. A subtype value (analogous to the ``preference'' value in the _M_X record) indi- cates which style of distributed service is pro- vided with the given name. Subtype 1 indicates that the named host is an AFS (R) database server for the AFS cell of the given domain name. Subtype 2 indicates that the named host provides intra-cell name service for the DCE (R) cell named by the given domain name. In the example above, jack..toaster..com and jill..toaster..com are declared to be AFS database servers for the toaster..com AFS cell, so that AFS clients wishing service from toaster..com are directed to those two hosts for further information. The third record declares that tracker..toaster..com houses a directory server for the root of the DCE cell toaster..com, so that DCE clients that wish to refer to DCE services should consult with the host tracker..toaster..com NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--2299 for further information. The DCE sub-type of record is usually accompanied by a _T_X_T record for other information specifying other details to be used in accessing the DCE cell. RFC1183 contains more detailed information on the use of this record type. The _A_F_S_D_B record is still experimental; not all name servers implement or recognize it. 66..55..1144.. PPXX -- PPooiinntteerr ttoo XX..440000//RRFFCC882222 mmaappppiinngg iinnffoorrmmaattiioonn _n_a_m_e _{_t_t_l_} _a_d_d_r_-_c_l_a_s_s _P_X _p_r_e_f_e_r _8_2_2_-_d_o_m _X_._4_0_0_-_d_o_m *.ADMD-garr.X42D.it. IN PX 50 it. ADMD-garr.C-it. *.infn.it. IN PX 50 infn.it. O.PRMD-infn.ADMD-garr.C-it. *.it. IN PX 50 it. O-gate.PRMD-garr.ADMD-garr.C-it. The _P_X records (_P_o_i_n_t_e_r _t_o _X_._4_0_0_/_R_F_C_8_2_2 _m_a_p_- _p_i_n_g _i_n_f_o_r_m_a_t_i_o_n) are used to specify address map- ping rules between X.400 O/R addresses and RFC822 style (domain-style) mail addresses. For a detailed description of the mapping process please refer to RFC1327. Mapping rules are of 3 different types: 1) mapping from X.400 to RFC822 (defined as "table 1 rules" in RFC1327) 2) mapping from RFC822 to X.400 (defined as "table 2 rules" in RFC1327) 3) encoding RFC822 into X.400 (defined as "gate table" in RFC1327) All three types of mapping rules are specified using _P_X Resource Records in DNS, although the _n_a_m_e value is different: for case 1, the _n_a_m_e value is an X.400 domain in DNS syntax, whereas for cases 2 and 3 the _n_a_m_e value is an RFC822 domain. Refer to RFC-1664 for details on specifying an X.400 domain in DNS syntax and for the use of the _X_4_2_D keyword in it. Tools are available to convert from RFC1327 tables format into DNS files syntax. _P_r_e_f_e_r_e_n_c_e is analogous to the _M_X RR Preference parameter: it is currently advised to use a fixed value of 50 for it. _8_2_2_-_d_o_m gives the RFC822 part of the mapping rules, and _X_._4_0_0_-_d_o_m gives the X.400 part of the mapping rule (in DNS syntax). It is currently SSMMMM::1100--3300 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD advised always to use wildcarded _n_a_m_e values, as the RFC1327 tables specifications permit wildcard specifications only. This is to keep compatibility with existing services using static RFC1327 tables instead of DNS _P_X information. Specifications of mapping rules from X.400 to RFC822 syntax requires the creation of an appropri- ate X.400 domain tree into DNS, including thus spe- cific _S_O_A and _N_S records for the domain itself. Specification of mapping rules from RFC822 into X.400 can be embedded directly into the normal direct _n_a_m_e tree. Again, refer to RFC1664 for details about organization of this structure. Tools and library routines, based on the stan- dard resolver ones, are available to retrieve from DNS the appropriate mapping rules in RFC1327 or DNS syntax. Once again, refer to RFC1664 to use the _P_X resource record, and be careful in coordinating the mapping information you can specify in DNS with the same information specified into the RFC1327 static tables. The _P_X record is still experimental; not all servers implement or recognize it. 66..66.. DDiissccuussssiioonn aabboouutt tthhee TTTTLL The use of different Time To Live fields with in a RRset have been deprecated and this is enforced by the server when loading a primary zone. See the Secu- rity section for more discussion of differing TTLs. The Time To Live assigned to the records and to the zone via the Minimum field in the SOA record is very important. High values will lead to lower BIND network traffic and faster response time. Lower values will tend to generate lots of requests but will allow faster propagation of changes. Only changes and deletions from the zone are affected by the TTLs. Additions propagate according to the Refresh value in the SOA. Experience has shown that sites use default TTLs for their zones varying from around 0.5 day to around 7 days. You may wish to consider boosting the default TTL shown in former versions of this guide from one day (86400 seconds) to three days (259200 seconds). NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--3311 This will drastically reduce the number of requests made to your name servers. If you need fast propagation of changes and dele- tions, it might be wise to reduce the Minimum field a few days before the change, then do the modification itself and augment the TTL to its former value. If you know that your zone is pretty stable (you mainly add new records without deleting or changing old ones) then you may even wish to consider a TTL higher than three days. Note that in any case, it makes no sense to have records with a TTL below the SOA Refresh delay, as Delay is the time required for secondaries to get a copy of the newly modified zone. 66..77.. AAbboouutt ````sseeccuurree zzoonneess'''' Secure zones implement named security on a zone by zone basis. It is designed to use a permission list of networks or hosts which may obtain particular information from the zone. In order to use zone security, _n_a_m_e_d must be com- piled with SECURE_ZONES defined and you must have at least one secure_zone TXT RR. Unless a _s_e_c_u_r_e___z_o_n_e record exists for a given zone, no restrictions will be applied to the data in that zone. The format of the secure_zone TXT RR is: secure_zone addr-class TXT string The addr-class may be either _H_S or _I_N. The syn- tax for the TXT string is either ``network address:netmask'' or ``host IP address:H''. ``network address:netmask'' allows queries from an entire network. If the netmask is omitted, named will use the default netmask for the network address specified. ``host IP address:H'' allows queries from a host. The ``H'' after the ``:'' is required to differentiate the host address from a network address. Multiple secure_zone TXT RRs are allowed in the same zone file. For example, you can set up a zone to only answer Hesiod requests from the masked class B network 130.215.0.0 and from host 128.23.10.56 by adding the following two TXT RR's: SSMMMM::1100--3322 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD secure_zone HS TXT ``130.215.0.0:255.255.0.0'' secure_zone HS TXT ``128.23.10.56:H'' This feature can be used to restrict access to a Hesiod password map or to separate internal and exter- nal internet address resolution on a firewall machine without needing to run a separate named for internal and external address resolution. Note that you will need to include your loopback interface (127.0.0.1) in your secure_zone record, or your local clients won't be able to resolve names. 66..88.. AAbboouutt HHeessiioodd,, aanndd HHSS--ccllaassss RReessoouurrccee RReeccoorrddss Hesiod, developed by MIT Project Athena, is an information service built upon BIND. Its intent is similar to that of Sun's NIS: to furnish information about users, groups, network-accessible file systems, printcaps, and mail service throughout an installa- tion. Aside from its use of BIND rather than separate server code another important difference between Hes- iod and NIS is that Hesiod is not intended to deal with passwords and authentication, but only with data that are not security sensitive. Hesiod servers can be implemented by adding resource records to BIND servers; or they can be implemented as separate servers separately administered. To learn about and obtain Hesiod make an anony- mous FTP connection to host ATHENA-DIST.MIT.EDU and retrieve the compressed tar file //ppuubb//AATTHHEENNAA//hheess-- iioodd..ttaarr..ZZ. You will not need the named and resolver library portions of the distribution because their functionality has already been integrated into BIND as of 4.9. To learn how Hesiod functions as part of the Athena computing environment obtain the paper //ppuubb//AATTHHEENNAA//uusseenniixx//aatthheennaa--cchhaannggeess..PPSS from the above FTP server host. There is also a tar file of sample Hesiod resource files. Whether one should use Hesiod class is open to question, since the same services can probably be pro- vided with class IN, type TXT and type CNAME records. In either case, the code and documents for Hesiod will suggest how to set up and use the service. Note that while BIND includes support for _H_S- class queries, the zone transfer logic for non-_I_N- class zones is still experimental. NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--3333 66..99.. 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. 66..99..11.. BBoooott FFiilleess 66..99..11..11.. PPrriimmaarryy SSeerrvveerr ; ; Boot file for Primary Name Server ; ; type domain source file or host ; directory /usr/local/adm/named primary Berkeley..Edu ucbhosts primary 32..128..in-addr..arpa ucbhosts..rev primary 0..0..127..in-addr..arpa named..local cache .. root..cache 66..99..11..22.. SSeeccoonnddaarryy SSeerrvveerr ; ; Boot file for Secondary Name Server ; ; type domain source file or host ; directory /usr/local/adm/named 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 SSMMMM::1100--3344 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 66..99..11..33.. CCaacchhiinngg OOnnllyy SSeerrvveerr ; ; Boot file for Caching Only Name Server ; ; type domain source file or host ; directory /usr/local/adm/named cache .. root..cache primary 0..0..127..in-addr..arpa named..local 66..99..22.. RReemmoottee SSeerrvveerr // DDNNSS CClliieenntt 66..99..22..11.. //eettcc//rreessoollvv..ccoonnff domain Berkeley..Edu nameserver 128..32..0..4 nameserver 128..32..0..10 sortlist 130.155.160.0/255.255.240.0 130.155.0.0 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--3355 66..99..33.. rroooott..ccaacchhee ; ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . " ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file /domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher at RS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; file named.root ; ; last update: Oct 5, 1994 ; related version of root zone: 1994100500 ; .. 604800 IN NS NS..INTERNIC..NET.. NS..INTERNIC..NET.. 604800 IN A 198..41..0..4 .. 604800 IN NS NS1..ISI..EDU.. NS1..ISI..EDU.. 604800 IN A 128..9..0..107 .. 604800 IN NS C..PSI..NET.. C..PSI..NET.. 604800 IN A 192..33..4..12 .. 604800 IN NS TERP..UMD..EDU.. TERP..UMD..EDU.. 604800 IN A 128..8..10..90 .. 604800 IN NS NS..NASA..GOV.. NS..NASA..GOV.. 604800 IN A 128..102..16..10 604800 IN A 192..52..195..10 .. 604800 IN NS NS..ISC..ORG.. NS..ISC..ORG.. 604800 IN A 192..5..5..241 .. 604800 IN NS NS..NIC..DDN..MIL.. NS..NIC..DDN..MIL.. 604800 IN A 192..112..36..4 .. 604800 IN NS AOS..ARL..ARMY..MIL.. AOS..ARL..ARMY..MIL.. 604800 IN A 128..63..4..82 604800 IN A 192..5..25..82 .. 604800 IN NS NIC..NORDU..NET.. NIC..NORDU..NET.. 604800 IN A 192..36..148..17 ; End of File SSMMMM::1100--3366 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 66..99..44.. nnaammeedd..llooccaall @ IN SOA ucbvax..Berkeley..Edu. kjd..ucbvax..Berkeley..Edu.. ( 1994072100 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 259200 ) ; Minimum IN NS ucbvax..Berkeley..Edu.. ; pedantic 1 IN PTR localhost.. 66..99..55.. hhoosstt..rreevv ; ; @(#)ucb-hosts.rev 1.1 (Berkeley) 86/02/05 ; @ IN SOA ucbvax..Berkeley..Edu.. kjd..monet..Berkeley..Edu.. ( 1986020501 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 259200 ) ; 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..99..66.. HHoossttss NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--3377 ; ; @(#)ucb-hosts 1.2 (berkeley) 88/02/05 ; @ IN SOA ucbvax..Berkeley..Edu.. kjd..monet..Berkeley..Edu.. ( 1988020501 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 259200 ) ; Minimum IN NS ucbarpa..Berkeley..Edu.. IN NS ucbvax..Berkeley..Edu.. localhost IN A 127..1 ; note that 127.1 is the same as 127.0.0.1; see inet(3n) 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 ; 128.32.10 means 128.32.0.10; see inet(3n) IN A 128..32..10 ; HINFO and WKS are widely unused, ; but we'll show them as examples. IN HINFO VAX-11/750 UNIX IN WKS 128.32.0.10 TCP ( echo telnet discard sunrpc sftp uucp-path systat daytime netstat qotd nntp link chargen ftp auth time whhois 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. csrg IN MX 0 Ralph.CS IN MX 0 Zhou.CS IN MX 0 Painter.CS IN MX 0 Riggle.CS IN MX 0 Terry.CS IN MX 0 Kevin.CS SSMMMM::1100--3388 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 77.. 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 the _I_n_t_e_r_n_e_t and _B_I_T_N_E_T) should register with only one network. 77..11.. IInntteerrnneett Sites on the Internet who need information on setting up a domain should contact the registrar for their network, which is one of the following: MILnet HOSTMASTER@NIC..DDN..MIL other HOSTMASTER@INTERNIC..NET You may also want to be placed on the BIND mailing list, which is a mail group for people on the Internet who run BIND. The group discusses future design deci- sions, 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_u_n_e_t.._u_u.._n_e_t 77..22.. SSuubbddoommaaiinnss ooff EExxiissttiinngg DDoommaaiinnss If you want a subdomain of some existing domain, you should find the contact point for the parent domain rather than asking one of the above top-level registrars. There should be a convention that rreeggiiss-- ttrraarr@_d_o_m_a_i_n or hhoossttmmaasstteerr@_d_o_m_a_i_n for any given domain will always be an alias for that domain's registrar (somewhat analogous to ppoossttmmaasstteerr), but there is no such convention. Try it as a last resort, but first you should examine the _S_O_A record for the domain and send mail to the ``responsible person'' shown therein. You can also try _w_h_o_i_s. 88.. DDoommaaiinn MMaannaaggeemmeenntt This section contains information for starting, con- trolling and debugging _n_a_m_e_d. 88..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 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--3399 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 _/_u_s_r_/_s_b_i_n_/_n_a_m_e_d _]_; _t_h_e_n _/_u_s_r_/_s_b_i_n_/_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 the cache. 88..22.. //vvaarr//rruunn//nnaammeedd..ppiidd When _n_a_m_e_d is successfully started up it writes its process id into the file _/_v_a_r_/_r_u_n_/_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 defin- ing _P_I_D_F_I_L_E to the new name when compiling _n_a_m_e_d. 88..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_i_g_(_8_C_) to configure the machines local interfaces and to enable a system manager to access the network while the system is in single user mode. It is advisable to put the local machines interface addresses and a cou- ple 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_s 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 advisable to use this option when the system is in multi user mode. 88..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. 88..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. This is useful when you have made a change to a ``primary'' data file and you want _n_a_m_e_d's internal database to reflect the change. If you build BIND with the FORCED_RELOAD option, then SIGHUP also has the effect of SSMMMM::1100--4400 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD scheduling all ``secondary'' zones for serial-num- ber checks, which could lead to zone transfers ahead of the usual schedule. Normally serial-num- ber compares are done only at the intervals speci- fied in the zone's SOA record. 88..44..22.. DDeebbuuggggiinngg When _n_a_m_e_d is running incorrectly, look first in _/_v_a_r_/_l_o_g_/_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. Unless you run it with the ``-d'' option, _n_a_m_e_d has very little to say on its standard output or standard error. Everything _n_a_m_e_d has to say, it says to _s_y_s_l_o_g. SIGINT - Dumps the current data base and cache to _/_v_a_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 cor- rectly. 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. SIGUSR1 - Turns on debugging. Each following SIGUSR1 increments the debug level. The output goes to _/_v_a_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. SIGWINCH - Toggles tracing of all incoming queries if _n_a_m_e_d has been compiled with _Q_R_Y_L_O_G defined. The trace is sent to syslog, and is huge, but it is very useful for tracking down problems. To run with tracing of all queries specify the _-_q flag on the command line. If you routinely log queries you will probably want to analyze the results using the dnsstats stats script in the con- trib directory. SIGIOT - Dumps statistics data into _/_v_a_r_/_t_m_p_/_n_a_m_e_d_._s_t_a_t_s if the server is built with _S_T_A_T_S defined. Statistics are appended to the file. NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--4411 99.. BBuuiillddiinngg aa SSyysstteemm wwiitthh aa NNaammee SSeerrvveerr BIND is composed 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 given network port. The standard port for UDP and TCP is specified in _/_e_t_c_/_s_e_r_v_i_c_e_s. 99..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. Newer BSD systems include both name server and host table func- tionality with preference given to the name server if there is one or if there is a _/_e_t_c_/_r_e_s_o_l_v_._c_o_n_f file. 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 contains functions that build query packets and exchange them with name servers. Before building the 4.3BSD 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|=''. If your operating system isn't VAX|= 4.3BSD, it is probably the case that your vendor has included _r_e_s_o_l_v_e_r support in the supplied C Library. You should consult your vendor's documentation to find out what has to be done to enable _r_e_s_o_l_v_e_r support. Note that your vendor's _r_e_s_o_l_v_e_r may be out of date with respect to the one shipped with BIND, and that you might want to build BIND's resolver library and install it, and its include files, into your system's ____________________ |=VAX is a Trademark of Digital Equipment Corporation SSMMMM::1100--4422 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD compile/link path so that your own network applica- tions will be able to use the newer features. NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--4433 AACCKKNNOOWWLLEEDDGGEEMMEENNTTSS ---- 44..99..33 The _<_b_i_n_d_-_w_o_r_k_e_r_s_@_v_i_x_._c_o_m_> mailing list was once again of great help; this release would not be nearly as ready for prime time if not for their efforts. Special commendations are owed to Robert Elz, Don "Truck" Lewis, Bob Halley, Mark Andrews, Berthold Paffrath, Ruediger Volk, and Peter Koch. Digital Equipment Corporation, Hewlett Packard, Silicon Graphics, and SunSoft all made hardware available for inte- gration testing; this made the release far more solid than it would otherwise have been. More hardware loans are wel- come -- if you are a system vendor and you would like BIND to run ``out of the box'' on your platform and are willing to lend some rusty old hardware for the purpose, please con- tact me (_<_p_a_u_l_@_v_i_x_._o_r_g_>) to make the arrangements. Special thanks to the Internet Software Consortium for funding this work. Contact _<_i_s_c_-_i_n_f_o_@_i_s_c_._o_r_g_> if your orga- nization would like to participate in funding future releases of BIND and other freely redistributable software packages that are in wide use on the Internet. AACCKKNNOOWWLLEEDDGGEEMMEENNTTSS ---- tthhrroouugghh 44..99 The alpha-test group was extremely helpful in furnish- ing improvements, finding and repairing bugs, and being patient. I would like to express special thanks to Brian Reid of Digital Equipment corporation for funding this work. Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe Wolfhugel, and a cast of dozens all helped out above and beyond the call of duty. Special thanks to Phil Almquist, who got the project started and contributed a lot of the code and fixed several of the worst bugs. AACCKKNNOOWWLLEEDDGGEEMMEENNTTSS ---- tthhrroouugghh 44..88..33 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. SSMMMM::1100--4444 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD 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 Corpo- ration. NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD SSMMMM::1100--4455 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 Cen- ter, 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 Cen- ter, 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. [RFC1101] 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. [RFC1123] R. Braden, Editor, "Requirements for Internet Hosts -- Application and Support" _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_2_3 Network Information Center, SRI International, Menlo Park, California. October 1989. [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and Mock- apetris, P., "New DNS RR Definitions" _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_8_3 Network Information SSMMMM::1100--4466 NNaammee SSeerrvveerr OOppeerraattiioonnss GGuuiiddee ffoorr BBIINNDD Center, SRI International, Menlo Park, California. October 1990. [RFC1327] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822" _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_3_2_7 Network Information Center, SRI Interna- tional, Menlo Park, California. May 1992. [RFC1664] Allocchio, C., Bonito, A., Cole, B., Giordano, S., Hagens, R., "Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables" _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_6_6_4 Network Information Cen- ter, SRI International, Menlo Park, California. August 1994. [RFC1713] Romao, A., "Tools for DNS debugging" _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_7_1_3_, _a_l_s_o _F_Y_I_2_7 Network Information Center, SRI International, Menlo Park, California. November 1994. [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. [Mockapetris] Mockapetris, P., Dunlap, K, _D_e_v_e_l_o_p_m_e_n_t _o_f _t_h_e _D_o_m_a_i_n _N_a_m_e _S_y_s_t_e_m ACM Computer Communications Review 18, 4:123-133. Proceedings ACM SIGCOMM '88 Symposium, August 1988. [Liu] Liu, C., Albitz, P., _D_N_S _a_n_d _B_I_N_D O'Reilly & Asso- ciates, Sebastopol, CA, 502 pages, ISBN 0-937175-82-X 1992