1 Network Working Group M. Lottor
2 Request For Comments: 1033 SRI International
6 DOMAIN ADMINISTRATORS OPERATIONS GUIDE
12 This RFC provides guidelines for domain administrators in operating a
13 domain server and maintaining their portion of the hierarchical
14 database. Familiarity with the domain system is assumed.
15 Distribution of this memo is unlimited.
19 This memo is a formatted collection of notes and excerpts from the
20 references listed at the end of this document. Of particular mention
21 are Paul Mockapetris and Kevin Dunlap.
25 A domain server requires a few files to get started. It will
26 normally have some number of boot/startup files (also known as the
27 "safety belt" files). One section will contain a list of possible
28 root servers that the server will use to find the up-to-date list of
29 root servers. Another section will list the zone files to be loaded
30 into the server for your local domain information. A zone file
31 typically contains all the data for a particular domain. This guide
32 describes the data formats that can be used in zone files and
33 suggested parameters to use for certain fields. If you are
34 attempting to do anything advanced or tricky, consult the appropriate
35 domain RFC's for more details.
37 Note: Each implementation of domain software may require different
38 files. Zone files are standardized but some servers may require
39 other startup files. See the appropriate documentation that comes
40 with your software. See the appendix for some specific examples.
44 A zone defines the contents of a contiguous section of the domain
45 space, usually bounded by administrative boundaries. There will
46 typically be a separate data file for each zone. The data contained
47 in a zone file is composed of entries called Resource Records (RRs).
54 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
57 You may only put data in your domain server that you are
58 authoritative for. You must not add entries for domains other than
59 your own (except for the special case of "glue records").
61 A domain server will probably read a file on start-up that lists the
62 zones it should load into its database. The format of this file is
63 not standardized and is different for most domain server
64 implementations. For each zone it will normally contain the domain
65 name of the zone and the file name that contains the data to load for
70 A resolver will need to find the root servers when it first starts.
71 When the resolver boots, it will typically read a list of possible
72 root servers from a file.
74 The resolver will cycle through the list trying to contact each one.
75 When it finds a root server, it will ask it for the current list of
76 root servers. It will then discard the list of root servers it read
77 from the data file and replace it with the current list it received.
79 Root servers will not change very often. You can get the names of
80 current root servers from the NIC.
82 FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
85 As of this date (June 1987) they are:
87 SRI-NIC.ARPA 10.0.0.51 26.0.0.73
89 BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2
94 Records in the zone data files are called resource records (RRs).
95 They are specified in RFC-883 and RFC-973. An RR has a standard
98 <name> [<ttl>] [<class>] <type> <data>
100 The record is divided into fields which are separated by white space.
104 The name field defines what domain name applies to the given
110 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
113 RR. In some cases the name field can be left blank and it will
114 default to the name field of the previous RR.
118 TTL stands for Time To Live. It specifies how long a domain
119 resolver should cache the RR before it throws it out and asks a
120 domain server again. See the section on TTL's. If you leave
121 the TTL field blank it will default to the minimum time
122 specified in the SOA record (described later).
126 The class field specifies the protocol group. If left blank it
127 will default to the last class specified.
131 The type field specifies what type of data is in the RR. See
132 the section on types.
136 The data field is defined differently for each type and class
137 of data. Popular RR data formats are described later.
139 The domain system does not guarantee to preserve the order of
140 resource records. Listing RRs (such as multiple address records) in
141 a certain order does not guarantee they will be used in that order.
143 Case is preserved in names and data fields when loaded into the name
144 server. All comparisons and lookups in the name server are case
147 Parenthesis ("(",")") are used to group data that crosses a line
150 A semicolon (";") starts a comment; the remainder of the line is
153 The asterisk ("*") is used for wildcarding.
155 The at-sign ("@") denotes the current default domain name.
166 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
171 A domain name is a sequence of labels separated by dots.
173 Domain names in the zone files can be one of two types, either
174 absolute or relative. An absolute name is the fully qualified domain
175 name and is terminated with a period. A relative name does not
176 terminate with a period, and the current default domain is appended
177 to it. The default domain is usually the name of the domain that was
178 specified in the boot file that loads each zone.
180 The domain system allows a label to contain any 8-bit character.
181 Although the domain system has no restrictions, other protocols such
182 as SMTP do have name restrictions. Because of other protocol
183 restrictions, only the following characters are recommended for use
184 in a host name (besides the dot separator):
186 "A-Z", "a-z", "0-9", dash and underscore
190 It is important that TTLs are set to appropriate values. The TTL is
191 the time (in seconds) that a resolver will use the data it got from
192 your server before it asks your server again. If you set the value
193 too low, your server will get loaded down with lots of repeat
194 requests. If you set it too high, then information you change will
195 not get distributed in a reasonable amount of time. If you leave the
196 TTL field blank, it will default to what is specified in the SOA
199 Most host information does not change much over long time periods. A
200 good way to set up your TTLs would be to set them at a high value,
201 and then lower the value if you know a change will be coming soon.
202 You might set most TTLs to anywhere between a day (86400) and a week
203 (604800). Then, if you know some data will be changing in the near
204 future, set the TTL for that RR down to a lower value (an hour to a
205 day) until the change takes place, and then put it back up to its
208 Also, all RRs with the same name, class, and type should have the
213 The domain system was designed to be protocol independent. The class
214 field is used to identify the protocol group that each RR is in.
216 The class of interest to people using TCP/IP software is the class
222 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
225 "Internet". Its standard designation is "IN".
227 A zone file should only contain RRs of the same class.
231 There are many defined RR types. For a complete list, see the domain
232 specification RFCs. Here is a list of current commonly used types.
233 The data for each type is described in the data section.
235 Designation Description
236 ==========================================
237 SOA Start Of Authority
241 CNAME Canonical Name (nickname pointer)
242 HINFO Host Information
243 WKS Well Known Services
249 SOA (Start Of Authority)
251 <name> [<ttl>] [<class>] SOA <origin> <person> (
258 The Start Of Authority record designates the start of a zone. The
259 zone ends at the next SOA record.
261 <name> is the name of the zone.
263 <origin> is the name of the host on which the master zone file
266 <person> is a mailbox for the person responsible for the zone. It is
267 formatted like a mailing address but the at-sign that normally
268 separates the user from the host name is replaced with a dot.
270 <serial> is the version number of the zone file. It should be
271 incremented anytime a change is made to data in the zone.
278 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
281 <refresh> is how long, in seconds, a secondary name server is to
282 check with the primary name server to see if an update is needed. A
283 good value here would be one hour (3600).
285 <retry> is how long, in seconds, a secondary name server is to retry
286 after a failure to check for a refresh. A good value here would be
289 <expire> is the upper limit, in seconds, that a secondary name server
290 is to use the data before it expires for lack of getting a refresh.
291 You want this to be rather large, and a nice value is 3600000, about
294 <minimum> is the minimum number of seconds to be used for TTL values
295 in RRs. A minimum of at least a day is a good value here (86400).
297 There should only be one SOA record per zone. A sample SOA record
298 would look something like:
300 @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
310 <domain> [<ttl>] [<class>] NS <server>
312 The NS record lists the name of a machine that provides domain
313 service for a particular domain. The name associated with the RR is
314 the domain name and the data portion is the name of a host that
315 provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide
316 name lookup service for the domain COM then the following entries
319 COM. NS SRI-NIC.ARPA.
322 Note that the machines providing name service do not have to live in
323 the named domain. There should be one NS record for each server for
324 a domain. Also note that the name "COM" defaults for the second NS
327 NS records for a domain exist in both the zone that delegates the
328 domain, and in the domain itself.
334 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
339 If the name server host for a particular domain is itself inside the
340 domain, then a 'glue' record will be needed. A glue record is an A
341 (address) RR that specifies the address of the server. Glue records
342 are only needed in the server delegating the domain, not in the
343 domain itself. If for example the name server for domain SRI.COM was
344 KL.SRI.COM, then the NS record would look like this, but you will
345 also need to have the following A record.
347 SRI.COM. NS KL.SRI.COM.
348 KL.SRI.COM. A 10.1.0.2
353 <host> [<ttl>] [<class>] A <address>
355 The data for an A record is an internet address in dotted decimal
356 form. A sample A record might look like:
358 SRI-NIC.ARPA. A 10.0.0.51
360 There should be one A record for each address of a host.
362 CNAME ( Canonical Name)
364 <nickname> [<ttl>] [<class>] CNAME <host>
366 The CNAME record is used for nicknames. The name associated with the
367 RR is the nickname. The data portion is the official name. For
368 example, a machine named SRI-NIC.ARPA may want to have the nickname
369 NIC.ARPA. In that case, the following RR would be used:
371 NIC.ARPA. CNAME SRI-NIC.ARPA.
373 There must not be any other RRs associated with a nickname of the
376 Nicknames are also useful when a host changes it's name. In that
377 case, it is usually a good idea to have a CNAME pointer so that
378 people still using the old name will get to the right place.
390 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
395 <host> [<ttl>] [<class>] HINFO <hardware> <software>
397 The HINFO record gives information about a particular host. The data
398 is two strings separated by whitespace. The first string is a
399 hardware description and the second is software. The hardware is
400 usually a manufacturer name followed by a dash and model designation.
401 The software string is usually the name of the operating system.
403 Official HINFO types can be found in the latest Assigned Numbers RFC,
404 the latest of which is RFC-1010. The Hardware type is called the
405 Machine name and the Software type is called the System name.
407 Some sample HINFO records:
409 SRI-NIC.ARPA. HINFO DEC-2060 TOPS20
410 UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX
413 WKS (Well Known Services)
415 <host> [<ttl>] [<class>] WKS <address> <protocol> <services>
417 The WKS record is used to list Well Known Services a host provides.
418 WKS's are defined to be services on port numbers below 256. The WKS
419 record lists what services are available at a certain address using a
420 certain protocol. The common protocols are TCP or UDP. A sample WKS
421 record for a host offering the same services on all address would
424 Official protocol names can be found in the latest Assigned Numbers
425 RFC, the latest of which is RFC-1010.
427 SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP
428 WKS 10.0.0.51 UDP TIME
429 WKS 26.0.0.73 TCP TELNET FTP SMTP
430 WKS 26.0.0.73 UDP TIME
432 MX (Mail Exchanger) (See RFC-974 for more details.)
434 <name> [<ttl>] [<class>] MX <preference> <host>
436 MX records specify where mail for a domain name should be delivered.
437 There may be multiple MX records for a particular name. The
438 preference value specifies the order a mailer should try multiple MX
439 records when delivering mail. Zero is the highest preference.
440 Multiple records for the same name may have the same preference.
446 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
449 A host BAR.FOO.COM may want its mail to be delivered to the host
450 PO.FOO.COM and would then use the MX record:
452 BAR.FOO.COM. MX 10 PO.FOO.COM.
454 A host BAZ.FOO.COM may want its mail to be delivered to one of three
455 different machines, in the following order:
457 BAZ.FOO.COM. MX 10 PO1.FOO.COM.
461 An entire domain of hosts not connected to the Internet may want
462 their mail to go through a mail gateway that knows how to deliver
463 mail to them. If they would like mail addressed to any host in the
464 domain FOO.COM to go through the mail gateway they might use:
466 FOO.COM. MX 10 RELAY.CS.NET.
467 *.FOO.COM. MX 20 RELAY.CS.NET.
469 Note that you can specify a wildcard in the MX record to match on
470 anything in FOO.COM, but that it won't match a plain FOO.COM.
474 The structure of names in the domain system is set up in a
475 hierarchical way such that the address of a name can be found by
476 tracing down the domain tree contacting a server for each label of
477 the name. Because of this 'indexing' based on name, there is no easy
478 way to translate a host address back into its host name.
480 In order to do the reverse translation easily, a domain was created
481 that uses hosts' addresses as part of a name that then points to the
482 data for that host. In this way, there is now an 'index' to hosts'
483 RRs based on their address. This address mapping domain is called
484 IN-ADDR.ARPA. Within that domain are subdomains for each network,
485 based on network number. Also, for consistency and natural
486 groupings, the 4 octets of a host number are reversed.
488 For example, the ARPANET is net 10. That means there is a domain
489 called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at
490 51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
491 (who's address is 10.0.0.51). Since the NIC is also on the MILNET
492 (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN-
493 ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format
494 of these special pointers is defined below along with the examples
502 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
507 <special-name> [<ttl>] [<class>] PTR <name>
509 The PTR record is used to let special names point to some other
510 location in the domain tree. They are mainly used in the IN-
511 ADDR.ARPA records for translation of addresses to names. PTR's
512 should use official names and not aliases.
514 For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
515 would have the following records in the respective zone files for net
518 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
519 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
523 The IN-ADDR tree is also used to locate gateways on a particular
524 network. Gateways have the same kind of PTR RRs as hosts (as above)
525 but in addition they have other PTRs used to locate them by network
526 number alone. These records have only 1, 2, or 3 octets as part of
527 the name depending on whether they are class A, B, or C networks,
530 Lets take the SRI-CSL gateway for example. It connects 3 different
531 networks, one class A, one class B and one class C. It will have the
532 standard RR's for a host in the CSL.SRI.COM zone:
534 GW.CSL.SRI.COM. A 10.2.0.2
538 Also, in 3 different zones (one for each network), it will have one
539 of the following number to name translation pointers:
541 2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
542 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
543 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
545 In addition, in each of the same 3 zones will be one of the following
546 gateway location pointers:
548 10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
549 18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
550 33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
558 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
565 To add a new subdomain to your domain:
567 Setup the other domain server and/or the new zone file.
569 Add an NS record for each server of the new domain to the zone
570 file of the parent domain.
572 Add any necessary glue RRs.
576 To add a new host to your zone files:
578 Edit the appropriate zone file for the domain the host is in.
580 Add an entry for each address of the host.
582 Optionally add CNAME, HINFO, WKS, and MX records.
584 Add the reverse IN-ADDR entry for each host address in the
585 appropriate zone files for each network the host in on.
589 To delete a host from the zone files:
591 Remove all the hosts' resource records from the zone file of
592 the domain the host is in.
594 Remove all the hosts' PTR records from the IN-ADDR zone files
595 for each network the host was on.
599 Follow instructions for adding a host.
601 Add the gateway location PTR records for each network the
606 Follow instructions for deleting a host.
608 Also delete the gateway location PTR records for each network
614 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
621 These are the suggested steps you should take if you are having
622 problems that you believe are caused by someone else's name server:
625 1. Complain privately to the responsible person for the domain. You
626 can find their mailing address in the SOA record for the domain.
628 2. Complain publicly to the responsible person for the domain.
630 3. Ask the NIC for the administrative person responsible for the
631 domain. Complain. You can also find domain contacts on the NIC in
632 the file NETINFO:DOMAIN-CONTACTS.TXT
634 4. Complain to the parent domain authorities.
636 5. Ask the parent authorities to excommunicate the domain.
670 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
673 EXAMPLE DOMAIN SERVER DATABASE FILES
675 The following examples show how zone files are set up for a typical
676 organization. SRI will be used as the example organization. SRI has
677 decided to divided their domain SRI.COM into a few subdomains, one
678 for each group that wants one. The subdomains are CSL and ISTC.
680 Note the following interesting items:
682 There are both hosts and domains under SRI.COM.
684 CSL.SRI.COM is both a domain name and a host name.
686 All the domains are serviced by the same pair of domain servers.
688 All hosts at SRI are on net 128.18 except hosts in the CSL domain
689 which are on net 192.12.33. Note that a domain does not have to
690 correspond to a physical network.
692 The examples do not necessarily correspond to actual data in use
695 SRI Domain Organization
705 +----------++-----------+
707 +-------+ +------+ +-------+
708 | CSL | | ISTC | | Hosts |
709 +-------+ +------+ +-------+
726 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
729 [File "CONFIG.CMD". Since bootstrap files are not standardized, this
730 file is presented using a pseudo configuration file syntax.]
732 load root server list from file ROOT.SERVERS
733 load zone SRI.COM. from file SRI.ZONE
734 load zone CSL.SRI.COM. from file CSL.ZONE
735 load zone ISTC.SRI.COM. from file ISTC.ZONE
736 load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE
737 load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
782 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
785 [File "ROOT.SERVERS". Again, the format of this file is not
788 ;list of possible root servers
789 SRI-NIC.ARPA 10.0.0.51 26.0.0.73
791 BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2
838 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
843 SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
845 1800 ;refresh every 30 minutes
846 600 ;retry every 10 minutes
847 604800 ;expire after a week
848 86400 ;default of an hour
851 SRI.COM. NS KL.SRI.COM.
863 MX 10 STRIPE.SRI.COM.
865 NIC CNAME SRI-NIC.ARPA.
867 Blackjack A 128.18.2.1
868 HINFO VAX-11/780 UNIX
869 WKS 128.18.2.1 TCP TELNET FTP
872 HINFO FOONLY-F4 TOPS20
873 WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER
894 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
899 CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
901 1800 ;refresh every 30 minutes
902 600 ;retry every 10 minutes
903 604800 ;expire after a week
904 86400 ;default of a day
907 CSL.SRI.COM. NS KL.SRI.COM.
915 HINFO FOONLY-F4 TOPS20
916 WKS 192.12.33.3 TCP TELNET FTP SMTP
923 SQUIRREL A 192.12.33.5
924 HINFO XEROX-1100 INTERLISP
926 HINFO SYMBOLICS-3600 LISPM
927 HELIUM A 192.12.33.30
950 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
955 ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
957 1800 ;refresh every 30 minutes
958 600 ;retry every 10 minutes
959 604800 ;expire after a week
960 86400 ;default of a day
963 ISTC.SRI.COM. NS KL.SRI.COM.
965 MX 10 SPAM.ISTC.SRI.COM.
970 HINFO VAX-11/750 UNIX
977 HINFO VAX-11/750 UNIX
978 MX 10 TSCA.ISTC.SRI.COM.
985 HINFO VAX-11/780 UNIX
986 MX 10 SPAM.ISTC.SRI.COM.
1006 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
1009 [File "SRINET.ZONE"]
1011 18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
1013 1800 ;refresh every 30 minutes
1014 600 ;retry every 10 minutes
1015 604800 ;expire after a week
1016 86400 ;default of a day
1019 18.128.IN-ADDR.ARPA. NS KL.SRI.COM.
1023 ; SRINET [128.18.0.0] Address Translations
1026 1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM.
1028 ; ISTC.SRI.COM Hosts
1029 2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM.
1030 6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM.
1031 11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM.
1032 201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM.
1033 203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM.
1034 3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM.
1037 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
1062 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
1065 [File "SRI-CSL-NET.ZONE"]
1067 33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
1069 1800 ;refresh every 30 minutes
1070 600 ;retry every 10 minutes
1071 604800 ;expire after a week
1072 86400 ;default of a day
1075 33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM.
1079 ; SRI-CSL-NET [192.12.33.0] Address Translations
1082 2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM.
1085 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
1086 3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM.
1087 4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM.
1088 5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM.
1089 7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM.
1090 30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM.
1091 31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM.
1092 32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM.
1118 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
1123 BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD
1126 This section describes two BIND implementation specific files; the
1127 boot file and the cache file. BIND has other options, files, and
1128 specifications that are not described here. See the Name Server
1129 Operations Guide for BIND for details.
1131 The boot file for BIND is usually called "named.boot". This
1132 corresponds to file "CONFIG.CMD" in the example section.
1134 --------------------------------------------------------
1136 primary SRI.COM SRI.ZONE
1137 primary CSL.SRI.COM CSL.ZONE
1138 primary ISTC.SRI.COM ISTC.ZONE
1139 primary 18.128.IN-ADDR.ARPA SRINET.ZONE
1140 primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE
1141 --------------------------------------------------------
1143 The cache file for BIND is usually called "named.ca". This
1144 corresponds to file "ROOT.SERVERS" in the example section.
1146 -------------------------------------------------
1147 ;list of possible root servers
1148 . 1 IN NS SRI-NIC.ARPA.
1152 ;and their addresses
1153 SRI-NIC.ARPA. A 10.0.0.51
1155 C.ISI.EDU. A 10.0.0.52
1156 BRL-AOS.ARPA. A 192.5.25.82
1159 A.ISI.EDU. A 26.3.0.103
1160 -------------------------------------------------
1174 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
1179 [1] Dunlap, K., "Name Server Operations Guide for BIND", CSRG,
1180 Department of Electrical Engineering and Computer Sciences,
1181 University of California, Berkeley, California.
1183 [2] Partridge, C., "Mail Routing and the Domain System", RFC-974,
1184 CSNET CIC BBN Laboratories, January 1986.
1186 [3] Mockapetris, P., "Domains Names - Concepts and Facilities",
1187 RFC-1034, USC/Information Sciences Institute, November 1987.
1189 [4] Mockapetris, P., "Domain Names - Implementations Specification",
1190 RFC-1035, USC/Information Sciences Institute, November 1987.