Network Working Group
This RFC provides guidelines for domain administrators in operating a domain server and maintaining their portion of the hierarchical database. Familiarity with the domain system is assumed. Distribution of this memo is unlimited.
This memo is a formatted collection of notes and excerpts from the references listed at the end of this document. Of particular mention are Paul Mockapetris and Kevin Dunlap.
A domain server requires a few files to get started. It will normally have some number of boot/startup files (also known as the "safety belt" files). One section will contain a list of possible root servers that the server will use to find the up-to-date list of root servers. Another section will list the zone files to be loaded into the server for your local domain information. A zone file typically contains all the data for a particular domain. This guide describes the data formats that can be used in zone files and suggested parameters to use for certain fields. If you are attempting to do anything advanced or tricky, consult the appropriate domain RFC's for more details.
Note: Each implementation of domain software may require different files. Zone files are standardized but some servers may require other startup files. See the appropriate documentation that comes with your software. See the appendix for some specific examples.
A zone defines the contents of a contiguous section of the domain space, usually bounded by administrative boundaries. There will typically be a separate data file for each zone. The data contained in a zone file is composed of entries called Resource Records (RRs).
You may only put data in your domain server that you are authoritative for. You must not add entries for domains other than your own (except for the special case of "glue records").
A domain server will probably read a file on start-up that lists the zones it should load into its database. The format of this file is not standardized and is different for most domain server implementations. For each zone it will normally contain the domain name of the zone and the file name that contains the data to load for the zone.
A resolver will need to find the root servers when it first starts. When the resolver boots, it will typically read a list of possible root servers from a file.
The resolver will cycle through the list trying to contact each one. When it finds a root server, it will ask it for the current list of root servers. It will then discard the list of root servers it read from the data file and replace it with the current list it received.
Root servers will not change very often. You can get the names of current root servers from the NIC.
FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to NIC@SRI-NIC.ARPA.
As of this date (June 1987) they are:
SRI-NIC.ARPA 10.0.0.51 126.96.36.199 C.ISI.EDU 10.0.0.52 BRL-AOS.ARPA 188.8.131.52 184.108.40.206 220.127.116.11 A.ISI.EDU 18.104.22.168
Records in the zone data files are called resource records (RRs). They are specified in RFC-883 and RFC-973. An RR has a standard format as shown:
<name> [<ttl>] [<class>] <type> <data>
The record is divided into fields which are separated by white space.
The name field defines what domain name applies to the given RR. In some cases the name field can be left blank and it will default to the name field of the previous RR.
TTL stands for Time To Live. It specifies how long a domain resolver should cache the RR before it throws it out and asks a domain server again. See the section on TTL's. If you leave the TTL field blank it will default to the minimum time specified in the SOA record (described later).
The class field specifies the protocol group. If left blank it will default to the last class specified.
The type field specifies what type of data is in the RR. See the section on types.
The data field is defined differently for each type and class of data. Popular RR data formats are described later.
The domain system does not guarantee to preserve the order of resource records. Listing RRs (such as multiple address records) in a certain order does not guarantee they will be used in that order.
Case is preserved in names and data fields when loaded into the name server. All comparisons and lookups in the name server are case insensitive.
Parenthesis ("(",")") are used to group data that crosses a line boundary.
A semicolon (";") starts a comment; the remainder of the line is ignored.
The asterisk ("*") is used for wildcarding.
The at-sign ("@") denotes the current default domain name.
A domain name is a sequence of labels separated by dots.
Domain names in the zone files can be one of two types, either absolute or relative. An absolute name is the fully qualified domain name and is terminated with a period. A relative name does not terminate with a period, and the current default domain is appended to it. The default domain is usually the name of the domain that was specified in the boot file that loads each zone.
The domain system allows a label to contain any 8-bit character. Although the domain system has no restrictions, other protocols such as SMTP do have name restrictions. Because of other protocol restrictions, only the following characters are recommended for use in a host name (besides the dot separator):
"A-Z", "a-z", "0-9", dash and underscore
It is important that TTLs are set to appropriate values. The TTL is the time (in seconds) that a resolver will use the data it got from your server before it asks your server again. If you set the value too low, your server will get loaded down with lots of repeat requests. If you set it too high, then information you change will not get distributed in a reasonable amount of time. If you leave the TTL field blank, it will default to what is specified in the SOA record for the zone.
Most host information does not change much over long time periods. A good way to set up your TTLs would be to set them at a high value, and then lower the value if you know a change will be coming soon. You might set most TTLs to anywhere between a day (86400) and a week (604800). Then, if you know some data will be changing in the near future, set the TTL for that RR down to a lower value (an hour to a day) until the change takes place, and then put it back up to its previous value.
Also, all RRs with the same name, class, and type should have the same TTL value.
The domain system was designed to be protocol independent. The class field is used to identify the protocol group that each RR is in.
The class of interest to people using TCP/IP software is the class "Internet". Its standard designation is "IN".
A zone file should only contain RRs of the same class.
There are many defined RR types. For a complete list, see the domain specification RFCs. Here is a list of current commonly used types. The data for each type is described in the data section.
Designation Description ========================================== SOA Start Of Authority NS Name Server A Internet Address CNAME Canonical Name (nickname pointer) HINFO Host Information WKS Well Known Services MX Mail Exchanger PTR Pointer
<name> [<ttl>] [<class>] SOA <origin> <person> ( <serial> <refresh> <retry> <expire> <minimum> )
The Start Of Authority record designates the start of a zone. The zone ends at the next SOA record.
There should only be one SOA record per zone. A sample SOA record would look something like:
@ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( 45 ;serial 3600 ;refresh 600 ;retry 3600000 ;expire 86400 ) ;minimum
<domain> [<ttl>] [<class>] NS <server>
The NS record lists the name of a machine that provides domain service for a particular domain. The name associated with the RR is the domain name and the data portion is the name of a host that provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide name lookup service for the domain COM then the following entries would be used:
COM. NS SRI-NIC.ARPA. NS C.ISI.EDU.
Note that the machines providing name service do not have to live in the named domain. There should be one NS record for each server for a domain. Also note that the name "COM" defaults for the second NS record.
NS records for a domain exist in both the zone that delegates the domain, and in the domain itself.
If the name server host for a particular domain is itself inside the domain, then a 'glue' record will be needed. A glue record is an A (address) RR that specifies the address of the server. Glue records are only needed in the server delegating the domain, not in the domain itself. If for example the name server for domain SRI.COM was KL.SRI.COM, then the NS record would look like this, but you will also need to have the following A record.
SRI.COM. NS KL.SRI.COM. KL.SRI.COM. A 10.1.0.2
<host> [<ttl>] [<class>] A <address>
The data for an A record is an internet address in dotted decimal form. A sample A record might look like:
SRI-NIC.ARPA. A 10.0.0.51
There should be one A record for each address of a host.
<nickname> [<ttl>] [<class>] CNAME <host>
The CNAME record is used for nicknames. The name associated with the RR is the nickname. The data portion is the official name. For example, a machine named SRI-NIC.ARPA may want to have the nickname NIC.ARPA. In that case, the following RR would be used:
NIC.ARPA. CNAME SRI-NIC.ARPA.
There must not be any other RRs associated with a nickname of the same class.
Nicknames are also useful when a host changes it's name. In that case, it is usually a good idea to have a CNAME pointer so that people still using the old name will get to the right place.
<host> [<ttl>] [<class>] HINFO <hardware> <software>
The HINFO record gives information about a particular host. The data is two strings separated by whitespace. The first string is a hardware description and the second is software. The hardware is usually a manufacturer name followed by a dash and model designation. The software string is usually the name of the operating system.
Official HINFO types can be found in the latest Assigned Numbers RFC, the latest of which is RFC-1010. The Hardware type is called the Machine name and the Software type is called the System name.
Some sample HINFO records:
SRI-NIC.ARPA. HINFO DEC-2060 TOPS20 UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX
<host> [<ttl>] [<class>] WKS <address> <protocol> <services>
The WKS record is used to list Well Known Services a host provides. WKS's are defined to be services on port numbers below 256. The WKS record lists what services are available at a certain address using a certain protocol. The common protocols are TCP or UDP. A sample WKS record for a host offering the same services on all address would look like:
Official protocol names can be found in the latest Assigned Numbers RFC, the latest of which is RFC-1010.
SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP WKS 10.0.0.51 UDP TIME WKS 22.214.171.124 TCP TELNET FTP SMTP WKS 126.96.36.199 UDP TIME
<name> [<ttl>] [<class>] MX <preference> <host>
MX records specify where mail for a domain name should be delivered. There may be multiple MX records for a particular name. The preference value specifies the order a mailer should try multiple MX records when delivering mail. Zero is the highest preference. Multiple records for the same name may have the same preference.
A host BAR.FOO.COM may want its mail to be delivered to the host PO.FOO.COM and would then use the MX record:
BAR.FOO.COM. MX 10 PO.FOO.COM.
A host BAZ.FOO.COM may want its mail to be delivered to one of three different machines, in the following order:
BAZ.FOO.COM. MX 10 PO1.FOO.COM. MX 20 PO2.FOO.COM. MX 30 PO3.FOO.COM.
An entire domain of hosts not connected to the Internet may want their mail to go through a mail gateway that knows how to deliver mail to them. If they would like mail addressed to any host in the domain FOO.COM to go through the mail gateway they might use:
FOO.COM. MX 10 RELAY.CS.NET. *.FOO.COM. MX 20 RELAY.CS.NET.
Note that you can specify a wildcard in the MX record to match on anything in FOO.COM, but that it won't match a plain FOO.COM.
The structure of names in the domain system is set up in a hierarchical way such that the address of a name can be found by tracing down the domain tree contacting a server for each label of the name. Because of this 'indexing' based on name, there is no easy way to translate a host address back into its host name.
In order to do the reverse translation easily, a domain was created that uses hosts' addresses as part of a name that then points to the data for that host. In this way, there is now an 'index' to hosts' RRs based on their address. This address mapping domain is called IN-ADDR.ARPA. Within that domain are subdomains for each network, based on network number. Also, for consistency and natural groupings, the 4 octets of a host number are reversed.
For example, the ARPANET is net 10. That means there is a domain called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at 188.8.131.52.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA (who's address is 10.0.0.51). Since the NIC is also on the MILNET (Net 26, address 184.108.40.206), there is also a PTR RR at 220.127.116.11.IN- ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format of these special pointers is defined below along with the examples for the NIC.
<special-name> [<ttl>] [<class>] PTR <name>
The PTR record is used to let special names point to some other location in the domain tree. They are mainly used in the IN- ADDR.ARPA records for translation of addresses to names. PTR's should use official names and not aliases.
For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 18.104.22.168 would have the following records in the respective zone files for net 10 and net 26:
22.214.171.124.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. 126.96.36.199.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
The IN-ADDR tree is also used to locate gateways on a particular network. Gateways have the same kind of PTR RRs as hosts (as above) but in addition they have other PTRs used to locate them by network number alone. These records have only 1, 2, or 3 octets as part of the name depending on whether they are class A, B, or C networks, respectively.
Lets take the SRI-CSL gateway for example. It connects 3 different networks, one class A, one class B and one class C. It will have the standard RR's for a host in the CSL.SRI.COM zone:
GW.CSL.SRI.COM. A 10.2.0.2 A 188.8.131.52 A 184.108.40.206
Also, in 3 different zones (one for each network), it will have one of the following number to name translation pointers:
220.127.116.11.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 18.104.22.168.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 22.214.171.124.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
In addition, in each of the same 3 zones will be one of the following gateway location pointers:
10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
To add a new subdomain to your domain:
To add a new host to your zone files:
To delete a host from the zone files:
These are the suggested steps you should take if you are having problems that you believe are caused by someone else's name server:
The following examples show how zone files are set up for a typical organization. SRI will be used as the example organization. SRI has decided to divided their domain SRI.COM into a few subdomains, one for each group that wants one. The subdomains are CSL and ISTC.
Note the following interesting items:
SRI Domain Organization +-------+ | COM | +-------+ | +-------+ | SRI | +-------+ | +----------++-----------+ | | | +-------+ +------+ +-------+ | CSL | | ISTC | | Hosts | +-------+ +------+ +-------+ | | +-------+ +-------+ | Hosts | | Hosts | +-------+ +-------+
load root server list from file ROOT.SERVERS load zone SRI.COM. from file SRI.ZONE load zone CSL.SRI.COM. from file CSL.ZONE load zone ISTC.SRI.COM. from file ISTC.ZONE load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
;list of possible root servers SRI-NIC.ARPA 10.0.0.51 126.96.36.199 C.ISI.EDU 10.0.0.52 BRL-AOS.ARPA 188.8.131.52 184.108.40.206 220.127.116.11 A.ISI.EDU 18.104.22.168
SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( 870407 ;serial 1800 ;refresh every 30 minutes 600 ;retry every 10 minutes 604800 ;expire after a week 86400 ;default of an hour ) SRI.COM. NS KL.SRI.COM. NS STRIPE.SRI.COM. MX 10 KL.SRI.COM. ;SRI.COM hosts KL A 10.1.0.2 A 22.214.171.124 MX 10 KL.SRI.COM. STRIPE A 10.4.0.2 STRIPE A 126.96.36.199 MX 10 STRIPE.SRI.COM. NIC CNAME SRI-NIC.ARPA. Blackjack A 188.8.131.52 HINFO VAX-11/780 UNIX WKS 184.108.40.206 TCP TELNET FTP CSL A 220.127.116.11 HINFO FOONLY-F4 TOPS20 WKS 18.104.22.168 TCP TELNET FTP SMTP FINGER MX 10 CSL.SRI.COM.
CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( 870330 ;serial 1800 ;refresh every 30 minutes 600 ;retry every 10 minutes 604800 ;expire after a week 86400 ;default of a day ) CSL.SRI.COM. NS KL.SRI.COM. NS STRIPE.SRI.COM. A 22.214.171.124 ;CSL.SRI.COM hosts A CNAME CSL.SRI.COM. B A 126.96.36.199 HINFO FOONLY-F4 TOPS20 WKS 188.8.131.52 TCP TELNET FTP SMTP GW A 10.2.0.2 A 184.108.40.206 A 220.127.116.11 HINFO PDP-11/23 MOS SMELLY A 18.104.22.168 HINFO IMAGEN IMAGEN SQUIRREL A 22.214.171.124 HINFO XEROX-1100 INTERLISP VENUS A 126.96.36.199 HINFO SYMBOLICS-3600 LISPM HELIUM A 188.8.131.52 HINFO SUN-3/160 UNIX ARGON A 184.108.40.206 HINFO SUN-3/75 UNIX RADON A 220.127.116.11 HINFO SUN-3/75 UNIX
ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. ( 870406 ;serial 1800 ;refresh every 30 minutes 600 ;retry every 10 minutes 604800 ;expire after a week 86400 ;default of a day ) ISTC.SRI.COM. NS KL.SRI.COM. NS STRIPE.SRI.COM. MX 10 SPAM.ISTC.SRI.COM. ; ISTC hosts joyce A 18.104.22.168 HINFO VAX-11/750 UNIX bozo A 22.214.171.124 HINFO SUN UNIX sundae A 126.96.36.199 HINFO SUN UNIX tsca A 188.8.131.52 A 10.3.0.2 HINFO VAX-11/750 UNIX MX 10 TSCA.ISTC.SRI.COM. tsc CNAME tsca prmh A 184.108.40.206 A 10.2.0.51 HINFO PDP-11/44 UNIX spam A 220.127.116.11 A 10.2.0.107 HINFO VAX-11/780 UNIX MX 10 SPAM.ISTC.SRI.COM.
18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( 870406 ;serial 1800 ;refresh every 30 minutes 600 ;retry every 10 minutes 604800 ;expire after a week 86400 ;default of a day ) 18.128.IN-ADDR.ARPA. NS KL.SRI.COM. NS STRIPE.SRI.COM. PTR GW.CSL.SRI.COM. ; SRINET [18.104.22.168] Address Translations ; SRI.COM Hosts 22.214.171.124.IN-ADDR.ARPA. PTR Blackjack.SRI.COM. ; ISTC.SRI.COM Hosts 126.96.36.199.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM. 188.8.131.52.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM. 184.108.40.206.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM. 220.127.116.11.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM. 18.104.22.168.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM. 22.214.171.124.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM. ; CSL.SRI.COM Hosts 126.96.36.199.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( 870404 ;serial 1800 ;refresh every 30 minutes 600 ;retry every 10 minutes 604800 ;expire after a week 86400 ;default of a day ) 33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM. NS STRIPE.SRI.COM. PTR GW.CSL.SRI.COM. ; SRI-CSL-NET [188.8.131.52] Address Translations ; SRI.COM Hosts 184.108.40.206.IN-ADDR.ARPA. PTR CSL.SRI.COM. ; CSL.SRI.COM Hosts 220.127.116.11.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. 18.104.22.168.IN-ADDR.ARPA. PTR B.CSL.SRI.COM. 22.214.171.124.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM. 126.96.36.199.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM. 188.8.131.52.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM. 184.108.40.206.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM. 220.127.116.11.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM. 18.104.22.168.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM.
BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD UNIX
This section describes two BIND implementation specific files; the boot file and the cache file. BIND has other options, files, and specifications that are not described here. See the Name Server Operations Guide for BIND for details.
The boot file for BIND is usually called "named.boot". This corresponds to file "CONFIG.CMD" in the example section.
-------------------------------------------------------- cache . named.ca primary SRI.COM SRI.ZONE primary CSL.SRI.COM CSL.ZONE primary ISTC.SRI.COM ISTC.ZONE primary 18.128.IN-ADDR.ARPA SRINET.ZONE primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE --------------------------------------------------------
The cache file for BIND is usually called "named.ca". This corresponds to file "ROOT.SERVERS" in the example section.
------------------------------------------------- ;list of possible root servers . 1 IN NS SRI-NIC.ARPA. NS C.ISI.EDU. NS BRL-AOS.ARPA. NS C.ISI.EDU. ;and their addresses SRI-NIC.ARPA. A 10.0.0.51 A 22.214.171.124 C.ISI.EDU. A 10.0.0.52 BRL-AOS.ARPA. A 126.96.36.199 A 188.8.131.52 A 184.108.40.206 A.ISI.EDU. A 220.127.116.11 -------------------------------------------------