The name server uses several files to load its data base. This section covers the files and their formats needed for named.
This is the file that is first read when named 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 /etc/named.boot. However this can be changed by setting the BOOTFILE variable when you compile named or by specifying the location on the command line when named is started up.
A default domain may be specified for the name server using a line such as
The directory directive specifies the directory in which the name server should run, allowing the other file names in the boot file to use relative path names. There can be only one directory directive and it should be given before any other directives that specify file names.
The line in the boot file that designates the server as a primary master server for a zone looks as follows:
The above assumes that the zone you are specifying is a class IN zone. If you wish to designate a different class you can append /class to the first field, where class 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:
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.
As with primary you may specify a secondary server for a class other than IN by appending /class to the secondary keyword, e.g., secondary/HS.
The line for a stub server is similar to a secondary. (This feature is experimental as of 4.9.3.)
Stub zones are intended to ensure that a primary for a zone always has the correct NS 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 NS records for a zone to be specified in only one place.
All servers, including ``caching only'' servers, should have a line as follows in the boot file to prime the name servers cache:
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 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 primary and secondary, you may specify a secondary server for a class other than IN by appending /class to the cache keyword, e.g., class/HS.
Any server can make use of forwarders. A forwarder is another server capable of processing recursive queries that is willing to try resolving queries on behalf of other systems. The forwarders command specifies forwarders by internet address as follows:
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 NS record lookups for the relevant domain. If the forwarders do not answer, then unless the slave directive was given, the appropriate servers for the domains will be queried directly.
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
So while forwarders prepends addresses to the ``server list'' for each query, options forward-only causes the ``server list'' to contain only those addresses listed in the forwarders declarations. Careless use of the options forward-only 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 options forward-only directive should be considered very carefully. Note that this same behaviour can be achieved using the deprecated directive, slave.
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
A nonrecursive server can be named in an NS RR but it cannot be listed in the resolv.conf file.
If the file system containing your syslog file has quite a bit of space, you can consider using the
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 nslookup tool. You may decide that rather than answering with ``operation not implemented,'' named 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
Some name server operations can be quite resource intensive, and in order to tune your system properly it is sometimes necessary to change BIND's internal quotas. This is accomplished via
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 PTR 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 xfrnets directive.
This directive has the same syntax as forwarders except that you can list network numbers in addition to host addresses. For example, you could add the directive
The xfrnets directive may also be given as tcplist for compatibility with interim releases of BIND 4.9.
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 similarity-of-address; that is, if one address is on the same subnet as some interface of the local host, then that address will be tried first. Failing that, an address which is on the same network will be tried first. Failing that, they will be tried in a more-or-less random order unless the sortlist directive was given in the named.boot file. sortlist has a syntax similar to forwarders, xfrnets, and bogusns -- you give it a list of dotted-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 sortlist, 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 getting answers by listing the Class B network's number in a sortlist 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 sortlist directive is to cause BIND to sort the A records in any response it generates, so as to put those which appear on the sortlist 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 possible 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 perhaps on routing table information. We do not intend to solve the generalized ``multihomed host'' problem, but we should be able to do a little better 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.
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 bogusns directive in your named.boot file. Its syntax is the same as forwarders, xfrnets, and sortlist -- 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 sparingly or not at all.
If you are secondary for a lot of zones, you may find it convenient to split your named.boot file into a static portion which hardly ever changes (directives such as directory, sortlist, xfrnets and cache could go here), and dynamic portions that change frequently (all of your primary directives might go in one file, and all of your secondary directives might go in another file -- and either or both of these might be fetched automatically from some neighbor so that they can change your list of secondary zones without requiring your active intervention). You can accomplish this via the include 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 directory directive, so you can use relative pathnames if your system supports them.
The configuration file's name is /etc/resolv.conf. 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 contents will be cached by each client of the resolver library when the client makes its first call to a resolver routine.
The resolv.conf file contains directives, one per line, of the following forms:
The local-domain will be appended to any query-name that does not contain a ``.''. local-domain can be overridden on a per-process basis by setting the LOCALDOMAIN environment variable. Note that local-domain processing can be disabled by setting an option in the resolver.
The search-list is a list of domains which are tried, in order, as qualifying domains for query-names which do not contain a ``.''. Note that search-list processing can be disabled by setting an option in the resolver. Also note that the environment variable ``LOCALDOMAIN'' can override this search-list on a per-process basis.
The server-address'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 resolver client) and in test programs such as nslookup. 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 versions 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 /etc/rc.local) to do so:
The sort-list is a list of IP address, netmask pairs. Addresses returned by gethostbyname are sorted 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 option-list is a list of options which each override some internal resolver variable. Supported options at this time are:
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.
There are two standard files for specifying the data for a domain. These are hosts and host.rev. 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.
This file contains all the data about the machines in this zone. The location of this file is specified in the boot file.
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 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 natural grouping of hosts in a network.
This file specifies the PTR record for the local loopback interface, better known as localhost, 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 operation of every name server that the 127.0.0.1 address have a PTR record pointing back to the name ``localhost.''. The name of this PTR record is always ``1.0.0.127.IN-ADDR.ARPA''. This is necessary if you want your users to be able to use hostname-authentication (hosts.equiv or ~/.rhosts) on the name ``localhost''. As implied by this PTR record, there should be a ``localhost.my.dom.ain'' A record (with address 127.0.0.1) in every domain that contains hosts. ``localhost.'' will lose its trailing dot when 1.0.0.127.in-addr.arpa is queried for; then, the DEFNAMES and/or DNSRCH resolver options will cause ``localhost'' 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.
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:
{name} {ttl} addr-class Record Type Record Specific data
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 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 Start Of Authority resource record (see below).
The third field is the address class; currently, only one class is supported:
IN for internet addresses and other internet information. Limited
support is included for the HS 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.
The following characters have special meanings:
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 ``.''.
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 particularly useful for separating different types of data into multiple files. An example would be:
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 does not carry into the $INCLUDE file.
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 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 therefore 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.
name {ttl} addr-class SOA Origin Person in charge
@ IN SOA ucbvax.Berkeley.Edu. kjd.ucbvax.Berkeley.Edu. (
1995122103 ; Serial
10800 ; Refresh
1800 ; Retry
3600000 ; Expire
259200 ) ; MinimumThe Start of Authority, SOA, 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 primary master 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 meaning of n.m was ``n000m'' rather than the more intuitive ``n*1000+m'' (such that 1.234 translated to 1000234 rather than to 1234). This feature has been deprecated due to its obscurity, unpredictability, 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 perl programmer you could even use RCS 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 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 SOA record per zone.
{name} {ttl} addr-class NS Name servers name
IN NS ucbarpa.Berkeley.Edu.
The Name Server record, NS, lists a name server responsible
for a given domain, creating a delegation point and a subzone.
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.
{name} {ttl} addr-class A address
ucbarpa IN A 128.32.0.4
IN A 10.0.0.78
The Address 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.
{name} {ttl} addr-class HINFO Hardware OS
IN HINFO VAX-11/780 UNIX
Host Information resource record, HINFO, 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 HINFO
record for each host, though for security reasons most domains don't have
any HINFO records at all. No application depends on them.
{name} {ttl} addr-class WKS address protocol list of services
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 )
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 the existence of a TXT or WKS RR in most
domains.
alias {ttl} addr-class CNAME Canonical name
ucbmonet IN CNAME monet
The Canonical Name resource record, CNAME, specifies 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 canonical name, not with the nickname.
Any resource records that include a domain name as their value
(e.g., NS or MX) must 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 CNAME record so that people still using the old name will get to the right place.
name {ttl} addr-class PTR real name
7.0 IN PTR monet.Berkeley.Edu.
A Domain Name Pointer record, PTR, allows special names to point
to some other location in the domain. The above example of a PTR
record is used in setting up reverse pointers for the special
IN-ADDR.ARPA domain. This line is from the example
hosts.rev file. PTR records are needed by the
gethostbyaddr function. Note the trailing ``.'' which
prevents BIND from appending the current $ORIGIN to that
domain name.
name {ttl} addr-class MX preference value mail exchange
Munnari.OZ.AU. IN MX 0 Seismo.CSS.GOV.
*.IL. IN MX 0 RELAY.CS.NET.
Mail eXchange records, MX, 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 MX since if one is not found at the
time mail is being delivered, an MX will be ``imputed'' with a cost
of 0 and a destination of the host itself. If you want a host to receive
its own mail, you should create an MX 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 example, 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 randomize
same-valued MX 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 MX 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 MX of RELAY.CS.NET. Wildcard MX records are not very useful in practice, though, since once a mail message gets to the gateway for a given domain it still has to be routed within that domain and it is not currently possible to have an apparently-different set of MX 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'' MX records, note that each specific record will have to ``end with'' a complete recitation of the same data that is carried in the top-level record. This is because the specific MX 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 MX records are very subtle and you should be careful with them.
name {ttl} addr-class TXT string
Munnari.OZ.AU. IN TXT "foo"
A TXT record contains free-form textual data. The syntax of the text
depends on the domain where it is found; many systems use TXT records
to encode local data in a stylized format. MIT Hesiod is one such system.
owner {ttl} addr-class RP mbox-domain-name TXT-domain-name
franklin IN RP ben.franklin.berkeley.edu. sysadmins.berkeley.edu.
The Responsible Person record, RP, 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, mbox-domain-name, 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 Person-in-charge mailbox field in the SOA record. In the example above, the mbox-domain-name shows the encoding for ``<ben@franklin.berkeley.edu>''. The root domain name (just ``.'') may be specified to indicate that no mailbox is available.
The second field, TXT-domain-name, is a domain name for which TXT records exist. A subsequent query can be performed to retrieve the associated TXT resource records at TXT-domain-name. This provides 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 TXT-domain-name to indicate that no associated TXT RR exists. In the example above, ``sysadmins.berkeley.edu.'' is the name of a TXT record that might contain some text with names and phone numbers.
The format of the RP record is class-insensitive. Multiple RP records at a single name may be present in the database, though they should have identical TTLs.
The RP record is still experimental; not all name servers implement or recognize it.
name {ttl} addr-class AFSDB subtype server host name
toaster.com. IN AFSDB 1 jack.toaster.com.
toaster.com. IN AFSDB 1 jill.toaster.com.
toaster.com. IN AFSDB 2 tracker.toaster.com.
AFSDB 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 MX record) indicates
which style of distributed service is provided 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 for further information. The
DCE sub-type of record is usually accompanied by a TXT 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 AFSDB record is still experimental; not all name servers implement or recognize it.
name {ttl} addr-class PX prefer 822-dom X.400-dom
*.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 PX records (Pointer to X.400/RFC822 mapping information) are used to specify address mapping 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 PX Resource Records in DNS, although the name value is different: for case 1, the name value is an X.400 domain in DNS syntax, whereas for cases 2 and 3 the name 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 X42D keyword in it. Tools are available to convert from RFC1327 tables format into DNS files syntax. Preference is analogous to the MX RR Preference parameter: it is currently advised to use a fixed value of 50 for it. 822-dom gives the RFC822 part of the mapping rules, and X.400-dom gives the X.400 part of the mapping rule (in DNS syntax). It is currently advised always to use wildcarded name 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 PX information.
Specifications of mapping rules from X.400 to RFC822 syntax requires the creation of an appropriate X.400 domain tree into DNS, including thus specific SOA and NS records for the domain itself. Specification of mapping rules from RFC822 into X.400 can be embedded directly into the normal direct name tree. Again, refer to RFC1664 for details about organization of this structure.
Tools and library routines, based on the standard 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 PX 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 PX record is still experimental; not all servers implement or recognize it.
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). This will drastically reduce the number of requests made to your name servers.
If you need fast propagation of changes and deletions, 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.
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, named must be compiled with SECURE_ZONES defined and you must have at least one secure_zone TXT RR. Unless a secure_zone 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 HS or IN. The syntax 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:
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 external 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.
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 installation. Aside from its use of BIND rather than separate server code another important difference between Hesiod 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 anonymous FTP connection to host ATHENA-DIST.MIT.EDU and retrieve the compressed tar file /pub/ATHENA/hesiod.tar.Z. 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 /pub/ATHENA/usenix/athena-changes.PS 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 provided 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 HS-class queries, the zone transfer logic for non-IN-class zones is still experimental.
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.
; ; 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
; ; 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
; ; 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
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
;
; 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 . <file>"
; 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
@ 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.
;
; @(#)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.
;
; @(#)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