As per Relevance of the word operations, we have this rfc below:
Network Working Group M.
Request For Comments: 1033 SRI
November 1987
DOMAIN ADMINISTRATORS OPERATIONS
STATUS OF THIS
This RFC provides guidelines for domain administrators in operating
domain server and maintaining their portion of the
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
references listed at the end of this document. Of particular
are Paul Mockapetris and Kevin Dunlap
A domain server requires a few files to get started. It
normally have some number of boot/startup files (also known as
"safety belt" files). One section will contain a list of
root servers that the server will use to find the up-to-date list
root servers. Another section will list the zone files to be
into the server for your local domain information. A zone
typically contains all the data for a particular domain. This
describes the data formats that can be used in zone files
suggested parameters to use for certain fields. If you
attempting to do anything advanced or tricky, consult the
domain RFC's for more details
Note: Each implementation of domain software may require
files. Zone files are standardized but some servers may
other startup files. See the appropriate documentation that
with your software. See the appendix for some specific examples
A zone defines the contents of a contiguous section of the
space, usually bounded by administrative boundaries. There
typically be a separate data file for each zone. The data
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
authoritative for. You must not add entries for domains other
your own (except for the special case of "glue records").
A domain server will probably read a file on start-up that lists
zones it should load into its database. The format of this file
not standardized and is different for most domain
implementations. For each zone it will normally contain the
name of the zone and the file name that contains the data to load
the zone
ROOT
A resolver will need to find the root servers when it first starts
When the resolver boots, it will typically read a list of
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
root servers. It will then discard the list of root servers it
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
current root servers from the NIC
FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request
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 in the zone data files are called resource records (RRs).
They are specified in RFC-883 and RFC-973. An RR has a
format as shown
[] []
The record is divided into fields which are separated by white space
The name field defines what domain name applies to the
Lottor [Page 2]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
RR. In some cases the name field can be left blank and it
default to the name field of the previous RR
TTL stands for Time To Live. It specifies how long a
resolver should cache the RR before it throws it out and asks
domain server again. See the section on TTL's. If you
the TTL field blank it will default to the minimum
specified in the SOA record (described later).
The class field specifies the protocol group. If left blank
will default to the last class specified
The type field specifies what type of data is in the RR.
the section on types
The data field is defined differently for each type and
of data. Popular RR data formats are described later
The domain system does not guarantee to preserve the order
resource records. Listing RRs (such as multiple address records)
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
server. All comparisons and lookups in the name server are
insensitive
Parenthesis ("(",")") are used to group data that crosses a
boundary
A semicolon (";") starts a comment; the remainder of the line
ignored
The asterisk ("*") is used for wildcarding
The at-sign ("@") denotes the current default domain name
Lottor [Page 3]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
A domain name is a sequence of labels separated by dots
Domain names in the zone files can be one of two types,
absolute or relative. An absolute name is the fully qualified
name and is terminated with a period. A relative name does
terminate with a period, and the current default domain is
to it. The default domain is usually the name of the domain that
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
as SMTP do have name restrictions. Because of other
restrictions, only the following characters are recommended for
in a host name (besides the dot separator):
"A-Z", "a-z", "0-9", dash and
TTL's (Time To Live
It is important that TTLs are set to appropriate values. The TTL
the time (in seconds) that a resolver will use the data it got
your server before it asks your server again. If you set the
too low, your server will get loaded down with lots of
requests. If you set it too high, then information you change
not get distributed in a reasonable amount of time. If you leave
TTL field blank, it will default to what is specified in the
record for the zone
Most host information does not change much over long time periods.
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
(604800). Then, if you know some data will be changing in the
future, set the TTL for that RR down to a lower value (an hour to
day) until the change takes place, and then put it back up to
previous value
Also, all RRs with the same name, class, and type should have
same TTL value
The domain system was designed to be protocol independent. The
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
Lottor [Page 4]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
"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
specification RFCs. Here is a list of current commonly used types
The data for each type is described in the data section
Designation
==========================================
SOA Start Of
NS Name
A Internet
CNAME Canonical Name (nickname pointer
HINFO Host
WKS Well Known
MX Mail
PTR
SOA (Start Of Authority
[] [] SOA (
)
The Start Of Authority record designates the start of a zone.
zone ends at the next SOA record
is the name of the zone
is the name of the host on which the master zone
resides
is a mailbox for the person responsible for the zone. It
formatted like a mailing address but the at-sign that
separates the user from the host name is replaced with a dot
is the version number of the zone file. It should
incremented anytime a change is made to data in the zone
Lottor [Page 5]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
is how long, in seconds, a secondary name server is
check with the primary name server to see if an update is needed.
good value here would be one hour (3600).
is how long, in seconds, a secondary name server is to
after a failure to check for a refresh. A good value here would
10 minutes (600).
is the upper limit, in seconds, that a secondary name
is to use the data before it expires for lack of getting a refresh
You want this to be rather large, and a nice value is 3600000,
42 days
is the minimum number of seconds to be used for TTL
in RRs. A minimum of at least a day is a good value here (86400).
There should only be one SOA record per zone. A sample SOA
would look something like
@ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
45 ;
3600 ;
600 ;
3600000 ;
86400 ) ;
NS (Name Server
[] [] NS
The NS record lists the name of a machine that provides
service for a particular domain. The name associated with the RR
the domain name and the data portion is the name of a host
provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU
name lookup service for the domain COM then the following
would be used
COM. NS SRI-NIC.ARPA
NS C.ISI.EDU
Note that the machines providing name service do not have to live
the named domain. There should be one NS record for each server
a domain. Also note that the name "COM" defaults for the second
record
NS records for a domain exist in both the zone that delegates
domain, and in the domain itself
Lottor [Page 6]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
GLUE
If the name server host for a particular domain is itself inside
domain, then a 'glue' record will be needed. A glue record is an
(address) RR that specifies the address of the server. Glue
are only needed in the server delegating the domain, not in
domain itself. If for example the name server for domain SRI.COM
KL.SRI.COM, then the NS record would look like this, but you
also need to have the following A record
SRI.COM.
KL.SRI.COM. KL.SRI.COM. A 10.1.0.2.
A (Address
[] [] A
The data for an A record is an internet address in dotted
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
CNAME ( Canonical Name
<nickname> [] [] CNAME
The CNAME record is used for nicknames. The name associated with
RR is the nickname. The data portion is the official name.
example, a machine named SRI-NIC.ARPA may want to have the
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
same class
Nicknames are also useful when a host changes it's name. In
case, it is usually a good idea to have a CNAME pointer so
people still using the old name will get to the right place
Lottor [Page 7]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
HINFO (Host Info
[] [] HINFO <hardware> <software
The HINFO record gives information about a particular host. The
is two strings separated by whitespace. The first string is
hardware description and the second is software. The hardware
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
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
WKS (Well Known Services
[] [] WKS <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
record lists what services are available at a certain address using
certain protocol. The common protocols are TCP or UDP. A sample
record for a host offering the same services on all address
look like
Official protocol names can be found in the latest Assigned
RFC, the latest of which is RFC-1010.
SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP
WKS 10.0.0.51 UDP
WKS 26.0.0.73 TCP TELNET FTP
WKS 26.0.0.73 UDP
MX (Mail Exchanger) (See RFC-974 for more details.)
[] [] MX <preference>
MX records specify where mail for a domain name should be delivered
There may be multiple MX records for a particular name.
preference value specifies the order a mailer should try multiple
records when delivering mail. Zero is the highest preference
Multiple records for the same name may have the same preference
Lottor [Page 8]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
A host BAR.FOO.COM may want its mail to be delivered to the
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
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
their mail to go through a mail gateway that knows how to
mail to them. If they would like mail addressed to any host in
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
anything in FOO.COM, but that it won't match a plain FOO.COM
IN-ADDR.
The structure of names in the domain system is set up in
hierarchical way such that the address of a name can be found
tracing down the domain tree contacting a server for each label
the name. Because of this 'indexing' based on name, there is no
way to translate a host address back into its host name
In order to do the reverse translation easily, a domain was
that uses hosts' addresses as part of a name that then points to
data for that host. In this way, there is now an 'index' to hosts
RRs based on their address. This address mapping domain is
IN-ADDR.ARPA. Within that domain are subdomains for each network
based on network number. Also, for consistency and
groupings, the 4 octets of a host number are reversed
For example, the ARPANET is net 10. That means there is a
called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR
51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.
(who's address is 10.0.0.51). Since the NIC is also on the
(Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN
ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The
of these special pointers is defined below along with the
for the NIC
Lottor [Page 9]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
[] [] PTR
The PTR record is used to let special names point to some
location in the domain tree. They are mainly used in the IN
ADDR.ARPA records for translation of addresses to names. PTR'
should use official names and not aliases
For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
would have the following records in the respective zone files for
10 and net 26:
51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA
73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA
GATEWAY PTR'
The IN-ADDR tree is also used to locate gateways on a
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
number alone. These records have only 1, 2, or 3 octets as part
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
networks, one class A, one class B and one class C. It will have
standard RR's for a host in the CSL.SRI.COM zone
GW.CSL.SRI.COM. A 10.2.0.2
A 128.18.1.1
A 192.12.33.2
Also, in 3 different zones (one for each network), it will have
of the following number to name translation pointers
2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM
1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM
1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM
In addition, in each of the same 3 zones will be one of the
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
Lottor [Page 10]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
Adding a subdomain
To add a new subdomain to your domain
Setup the other domain server and/or the new zone file
Add an NS record for each server of the new domain to the
file of the parent domain
Add any necessary glue RRs
Adding a host
To add a new host to your zone files
Edit the appropriate zone file for the domain the host is in
Add an entry for each address of the host
Optionally add CNAME, HINFO, WKS, and MX records
Add the reverse IN-ADDR entry for each host address in
appropriate zone files for each network the host in on
Deleting a host
To delete a host from the zone files
Remove all the hosts' resource records from the zone file
the domain the host is in
Remove all the hosts' PTR records from the IN-ADDR zone
for each network the host was on
Adding gateways
Follow instructions for adding a host
Add the gateway location PTR records for each network
gateway is on
Deleting gateways
Follow instructions for deleting a host
Also delete the gateway location PTR records for each
Lottor [Page 11]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
the gateway was on
These are the suggested steps you should take if you are
problems that you believe are caused by someone else's name server
1. Complain privately to the responsible person for the domain.
can find their mailing address in the SOA record for the domain
2. Complain publicly to the responsible person for the domain
3. Ask the NIC for the administrative person responsible for
domain. Complain. You can also find domain contacts on the NIC
the file NETINFO:DOMAIN-CONTACTS.
4. Complain to the parent domain authorities
5. Ask the parent authorities to excommunicate the domain
Lottor [Page 12]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
EXAMPLE DOMAIN SERVER DATABASE
The following examples show how zone files are set up for a
organization. SRI will be used as the example organization. SRI
decided to divided their domain SRI.COM into a few subdomains,
for each group that wants one. The subdomains are CSL and ISTC
Note the following interesting items
There are both hosts and domains under SRI.COM
CSL.SRI.COM is both a domain name and a host name
All the domains are serviced by the same pair of domain servers
All hosts at SRI are on net 128.18 except hosts in the CSL
which are on net 192.12.33. Note that a domain does not have
correspond to a physical network
The examples do not necessarily correspond to actual data in
by the SRI domain
SRI Domain
+-------+
| COM |
+-------+
|
+-------+
| SRI |
+-------+
|
+----------++-----------+
| | |
+-------+ +------+ +-------+
| CSL | | ISTC | | Hosts |
+-------+ +------+ +-------+
| |
+-------+ +-------+
| Hosts | | Hosts |
+-------+ +-------+
Lottor [Page 13]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
[File "CONFIG.CMD". Since bootstrap files are not standardized,
file is presented using a pseudo configuration file syntax.]
load root server list from file ROOT.
load zone SRI.COM. from file SRI.
load zone CSL.SRI.COM. from file CSL.
load zone ISTC.SRI.COM. from file ISTC.
load zone 18.128.IN-ADDR.ARPA. from file SRINET.
load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.
Lottor [Page 14]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
[File "ROOT.SERVERS". Again, the format of this file is
standardized.]
;list of possible root
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
Lottor [Page 15]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
[File "SRI.ZONE"]
SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
870407 ;
1800 ;refresh every 30
600 ;retry every 10
604800 ;expire after a
86400 ;default of an
)
SRI.COM. NS KL.SRI.COM
NS STRIPE.SRI.COM
MX 10 KL.SRI.COM
;SRI.COM
KL A 10.1.0.2
A 128.18.10.6
MX 10 KL.SRI.COM
STRIPE A 10.4.0.2
STRIPE A 128.18.10.4
MX 10 STRIPE.SRI.COM
NIC CNAME SRI-NIC.ARPA
Blackjack A 128.18.2.1
HINFO VAX-11/780
WKS 128.18.2.1 TCP TELNET
CSL A 192.12.33.2
HINFO FOONLY-F4 TOPS20
WKS 192.12.33.2 TCP TELNET FTP SMTP
MX 10 CSL.SRI.COM
Lottor [Page 16]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
[File "CSL.ZONE"]
CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
870330 ;
1800 ;refresh every 30
600 ;retry every 10
604800 ;expire after a
86400 ;default of a
)
CSL.SRI.COM. NS KL.SRI.COM
NS STRIPE.SRI.COM
A 192.12.33.2
;CSL.SRI.COM
A CNAME CSL.SRI.COM
B A 192.12.33.3
HINFO FOONLY-F4 TOPS20
WKS 192.12.33.3 TCP TELNET FTP
GW A 10.2.0.2
A 192.12.33.1
A 128.18.1.1
HINFO PDP-11/23
SMELLY A 192.12.33.4
HINFO IMAGEN
SQUIRREL A 192.12.33.5
HINFO XEROX-1100
VENUS A 192.12.33.7
HINFO SYMBOLICS-3600
HELIUM A 192.12.33.30
HINFO SUN-3/160
ARGON A 192.12.33.31
HINFO SUN-3/75
RADON A 192.12.33.32
HINFO SUN-3/75
Lottor [Page 17]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
[File "ISTC.ZONE"]
ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
870406 ;
1800 ;refresh every 30
600 ;retry every 10
604800 ;expire after a
86400 ;default of a
)
ISTC.SRI.COM. NS KL.SRI.COM
NS STRIPE.SRI.COM
MX 10 SPAM.ISTC.SRI.COM
; ISTC
joyce A 128.18.4.2
HINFO VAX-11/750
bozo A 128.18.0.6
HINFO SUN
sundae A 128.18.0.11
HINFO SUN
tsca A 128.18.0.201
A 10.3.0.2
HINFO VAX-11/750
MX 10 TSCA.ISTC.SRI.COM
tsc CNAME
prmh A 128.18.0.203
A 10.2.0.51
HINFO PDP-11/44
spam A 128.18.4.3
A 10.2.0.107
HINFO VAX-11/780
MX 10 SPAM.ISTC.SRI.COM
Lottor [Page 18]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
[File "SRINET.ZONE"]
18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
870406 ;
1800 ;refresh every 30
600 ;retry every 10
604800 ;expire after a
86400 ;default of a
)
18.128.IN-ADDR.ARPA. NS KL.SRI.COM
NS STRIPE.SRI.COM
PTR GW.CSL.SRI.COM
; SRINET [128.18.0.0] Address
; SRI.COM
1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM
; ISTC.SRI.COM
2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM
6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM
11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM
201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM
203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM
3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM
; CSL.SRI.COM
1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM
Lottor [Page 19]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
[File "SRI-CSL-NET.ZONE"]
33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
870404 ;
1800 ;refresh every 30
600 ;retry every 10
604800 ;expire after a
86400 ;default of a
)
33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM
NS STRIPE.SRI.COM
PTR GW.CSL.SRI.COM
; SRI-CSL-NET [192.12.33.0] Address
; SRI.COM
2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM
; CSL.SRI.COM
1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM
3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM
4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM
5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM
7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM
30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM
31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM
32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM
Lottor [Page 20]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
BIND (Berkeley Internet Name Domain server) distributed with 4.3
This section describes two BIND implementation specific files;
boot file and the cache file. BIND has other options, files,
specifications that are not described here. See the Name
Operations Guide for BIND for details
The boot file for BIND is usually called "named.boot".
corresponds to file "CONFIG.CMD" in the example section
--------------------------------------------------------
cache . named.
primary SRI.COM SRI.
primary CSL.SRI.COM CSL.
primary ISTC.SRI.COM ISTC.
primary 18.128.IN-ADDR.ARPA SRINET.
primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.
--------------------------------------------------------
The cache file for BIND is usually called "named.ca".
corresponds to file "ROOT.SERVERS" in the example section
-------------------------------------------------
;list of possible root
. 1 IN NS SRI-NIC.ARPA
NS C.ISI.EDU
NS BRL-AOS.ARPA
NS C.ISI.EDU
;and their
SRI-NIC.ARPA. A 10.0.0.51
A 26.0.0.73
C.ISI.EDU. A 10.0.0.52
BRL-AOS.ARPA. A 192.5.25.82
A 192.5.22.82
A 128.20.1.2
A.ISI.EDU. A 26.3.0.103
-------------------------------------------------
Lottor [Page 21]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
[1] Dunlap, K., "Name Server Operations Guide for BIND", CSRG
Department of Electrical Engineering and Computer Sciences
University of California, Berkeley, California
[2] Partridge, C., "Mail Routing and the Domain System", RFC-974,
CSNET CIC BBN Laboratories, January 1986.
[3] Mockapetris, P., "Domains Names - Concepts and Facilities",
RFC-1034, USC/Information Sciences Institute, November 1987.
[4] Mockapetris, P., "Domain Names - Implementations Specification",
RFC-1035, USC/Information Sciences Institute, November 1987.
Lottor [Page 22]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
