Domain Administrators Operations Guide
RFC 1033
|
Document |
Type |
|
RFC - Unknown
(November 1987; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2020-07-29
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1033 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group M. Lottor
Request For Comments: 1033 SRI International
November 1987
DOMAIN ADMINISTRATORS OPERATIONS GUIDE
STATUS OF THIS MEMO
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.
ACKNOWLEDGMENTS
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.
INTRODUCTION
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.
ZONES
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).
Lottor [Page 1]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
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.
ROOT SERVERS
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 26.0.0.73
C.ISI.EDU 10.0.0.52
BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2
A.ISI.EDU 26.3.0.103
RESOURCE RECORDS
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.
<name>
The name field defines what domain name applies to the given
Lottor [Page 2]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
RR. In some cases the name field can be left blank and it will
default to the name field of the previous RR.
<ttl>
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).
<class>
The class field specifies the protocol group. If left blank it
will default to the last class specified.
<type>
The type field specifies what type of data is in the RR. See
the section on types.
<data>
The data field is defined differently for each type and class
Show full document text