![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc1033.lpr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc|
Return to rfc1033.lpr CVS log | Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc |
1.1 root 1: Network Working Group M. Lottor
2: Request For Comments: 1033 SRI International
3: November 1987
4:
5:
6: DOMAIN ADMINISTRATORS OPERATIONS GUIDE
7:
8:
9:
10: STATUS OF THIS MEMO
11:
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.
16:
17: ACKNOWLEDGMENTS
18:
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.
22:
23: INTRODUCTION
24:
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.
36:
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.
41:
42: ZONES
43:
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).
48:
49:
50:
51:
52: Lottor [Page 1]
53:
54: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
55:
56:
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").
60:
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
66: the zone.
67:
68: ROOT SERVERS
69:
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.
73:
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.
78:
79: Root servers will not change very often. You can get the names of
80: current root servers from the NIC.
81:
82: FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
83: [email protected].
84:
85: As of this date (June 1987) they are:
86:
87: SRI-NIC.ARPA 10.0.0.51 26.0.0.73
88: C.ISI.EDU 10.0.0.52
89: BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2
90: A.ISI.EDU 26.3.0.103
91:
92: RESOURCE RECORDS
93:
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
96: format as shown:
97:
98: <name> [<ttl>] [<class>] <type> <data>
99:
100: The record is divided into fields which are separated by white space.
101:
102: <name>
103:
104: The name field defines what domain name applies to the given
105:
106:
107:
108: Lottor [Page 2]
109:
110: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
111:
112:
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.
115:
116: <ttl>
117:
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).
123:
124: <class>
125:
126: The class field specifies the protocol group. If left blank it
127: will default to the last class specified.
128:
129: <type>
130:
131: The type field specifies what type of data is in the RR. See
132: the section on types.
133:
134: <data>
135:
136: The data field is defined differently for each type and class
137: of data. Popular RR data formats are described later.
138:
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.
142:
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
145: insensitive.
146:
147: Parenthesis ("(",")") are used to group data that crosses a line
148: boundary.
149:
150: A semicolon (";") starts a comment; the remainder of the line is
151: ignored.
152:
153: The asterisk ("*") is used for wildcarding.
154:
155: The at-sign ("@") denotes the current default domain name.
156:
157:
158:
159:
160:
161:
162:
163:
164: Lottor [Page 3]
165:
166: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
167:
168:
169: NAMES
170:
171: A domain name is a sequence of labels separated by dots.
172:
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.
179:
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):
185:
186: "A-Z", "a-z", "0-9", dash and underscore
187:
188: TTL's (Time To Live)
189:
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
197: record for the zone.
198:
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
206: previous value.
207:
208: Also, all RRs with the same name, class, and type should have the
209: same TTL value.
210:
211: CLASSES
212:
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.
215:
216: The class of interest to people using TCP/IP software is the class
217:
218:
219:
220: Lottor [Page 4]
221:
222: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
223:
224:
225: "Internet". Its standard designation is "IN".
226:
227: A zone file should only contain RRs of the same class.
228:
229: TYPES
230:
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.
234:
235: Designation Description
236: ==========================================
237: SOA Start Of Authority
238: NS Name Server
239:
240: A Internet Address
241: CNAME Canonical Name (nickname pointer)
242: HINFO Host Information
243: WKS Well Known Services
244:
245: MX Mail Exchanger
246:
247: PTR Pointer
248:
249: SOA (Start Of Authority)
250:
251: <name> [<ttl>] [<class>] SOA <origin> <person> (
252: <serial>
253: <refresh>
254: <retry>
255: <expire>
256: <minimum> )
257:
258: The Start Of Authority record designates the start of a zone. The
259: zone ends at the next SOA record.
260:
261: <name> is the name of the zone.
262:
263: <origin> is the name of the host on which the master zone file
264: resides.
265:
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.
269:
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.
272:
273:
274:
275:
276: Lottor [Page 5]
277:
278: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
279:
280:
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).
284:
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
287: 10 minutes (600).
288:
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
292: 42 days.
293:
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).
296:
297: There should only be one SOA record per zone. A sample SOA record
298: would look something like:
299:
300: @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
301: 45 ;serial
302: 3600 ;refresh
303: 600 ;retry
304: 3600000 ;expire
305: 86400 ) ;minimum
306:
307:
308: NS (Name Server)
309:
310: <domain> [<ttl>] [<class>] NS <server>
311:
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
317: would be used:
318:
319: COM. NS SRI-NIC.ARPA.
320: NS C.ISI.EDU.
321:
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
325: record.
326:
327: NS records for a domain exist in both the zone that delegates the
328: domain, and in the domain itself.
329:
330:
331:
332: Lottor [Page 6]
333:
334: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
335:
336:
337: GLUE RECORDS
338:
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.
346:
347: SRI.COM. NS
348: KL.SRI.COM. KL.SRI.COM. A 10.1.0.2.
349:
350:
351: A (Address)
352:
353: <host> [<ttl>] [<class>] A <address>
354:
355: The data for an A record is an internet address in dotted decimal
356: form. A sample A record might look like:
357:
358: SRI-NIC.ARPA. A 10.0.0.51
359:
360: There should be one A record for each address of a host.
361:
362: CNAME ( Canonical Name)
363:
364: <nickname> [<ttl>] [<class>] CNAME <host>
365:
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:
370:
371: NIC.ARPA. CNAME SRI-NIC.ARPA.
372:
373: There must not be any other RRs associated with a nickname of the
374: same class.
375:
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.
379:
380:
381:
382:
383:
384:
385:
386:
387:
388: Lottor [Page 7]
389:
390: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
391:
392:
393: HINFO (Host Info)
394:
395: <host> [<ttl>] [<class>] HINFO <hardware> <software>
396:
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.
402:
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.
406:
407: Some sample HINFO records:
408:
409: SRI-NIC.ARPA. HINFO DEC-2060 TOPS20
410: UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX
411:
412:
413: WKS (Well Known Services)
414:
415: <host> [<ttl>] [<class>] WKS <address> <protocol> <services>
416:
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
422: look like:
423:
424: Official protocol names can be found in the latest Assigned Numbers
425: RFC, the latest of which is RFC-1010.
426:
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
431:
432: MX (Mail Exchanger) (See RFC-974 for more details.)
433:
434: <name> [<ttl>] [<class>] MX <preference> <host>
435:
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.
441:
442:
443:
444: Lottor [Page 8]
445:
446: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
447:
448:
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:
451:
452: BAR.FOO.COM. MX 10 PO.FOO.COM.
453:
454: A host BAZ.FOO.COM may want its mail to be delivered to one of three
455: different machines, in the following order:
456:
457: BAZ.FOO.COM. MX 10 PO1.FOO.COM.
458: MX 20 PO2.FOO.COM.
459: MX 30 PO3.FOO.COM.
460:
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:
465:
466: FOO.COM. MX 10 RELAY.CS.NET.
467: *.FOO.COM. MX 20 RELAY.CS.NET.
468:
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.
471:
472: IN-ADDR.ARPA
473:
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.
479:
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.
487:
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
495: for the NIC.
496:
497:
498:
499:
500: Lottor [Page 9]
501:
502: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
503:
504:
505: PTR
506:
507: <special-name> [<ttl>] [<class>] PTR <name>
508:
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.
513:
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
516: 10 and net 26:
517:
518: 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
519: 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
520:
521: GATEWAY PTR's
522:
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,
528: respectively.
529:
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:
533:
534: GW.CSL.SRI.COM. A 10.2.0.2
535: A 128.18.1.1
536: A 192.12.33.2
537:
538: Also, in 3 different zones (one for each network), it will have one
539: of the following number to name translation pointers:
540:
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.
544:
545: In addition, in each of the same 3 zones will be one of the following
546: gateway location pointers:
547:
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.
551:
552:
553:
554:
555:
556: Lottor [Page 10]
557:
558: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
559:
560:
561: INSTRUCTIONS
562:
563: Adding a subdomain.
564:
565: To add a new subdomain to your domain:
566:
567: Setup the other domain server and/or the new zone file.
568:
569: Add an NS record for each server of the new domain to the zone
570: file of the parent domain.
571:
572: Add any necessary glue RRs.
573:
574: Adding a host.
575:
576: To add a new host to your zone files:
577:
578: Edit the appropriate zone file for the domain the host is in.
579:
580: Add an entry for each address of the host.
581:
582: Optionally add CNAME, HINFO, WKS, and MX records.
583:
584: Add the reverse IN-ADDR entry for each host address in the
585: appropriate zone files for each network the host in on.
586:
587: Deleting a host.
588:
589: To delete a host from the zone files:
590:
591: Remove all the hosts' resource records from the zone file of
592: the domain the host is in.
593:
594: Remove all the hosts' PTR records from the IN-ADDR zone files
595: for each network the host was on.
596:
597: Adding gateways.
598:
599: Follow instructions for adding a host.
600:
601: Add the gateway location PTR records for each network the
602: gateway is on.
603:
604: Deleting gateways.
605:
606: Follow instructions for deleting a host.
607:
608: Also delete the gateway location PTR records for each network
609:
610:
611:
612: Lottor [Page 11]
613:
614: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
615:
616:
617: the gateway was on.
618:
619: COMPLAINTS
620:
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:
623:
624:
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.
627:
628: 2. Complain publicly to the responsible person for the domain.
629:
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
633:
634: 4. Complain to the parent domain authorities.
635:
636: 5. Ask the parent authorities to excommunicate the domain.
637:
638:
639:
640:
641:
642:
643:
644:
645:
646:
647:
648:
649:
650:
651:
652:
653:
654:
655:
656:
657:
658:
659:
660:
661:
662:
663:
664:
665:
666:
667:
668: Lottor [Page 12]
669:
670: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
671:
672:
673: EXAMPLE DOMAIN SERVER DATABASE FILES
674:
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.
679:
680: Note the following interesting items:
681:
682: There are both hosts and domains under SRI.COM.
683:
684: CSL.SRI.COM is both a domain name and a host name.
685:
686: All the domains are serviced by the same pair of domain servers.
687:
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.
691:
692: The examples do not necessarily correspond to actual data in use
693: by the SRI domain.
694:
695: SRI Domain Organization
696:
697: +-------+
698: | COM |
699: +-------+
700: |
701: +-------+
702: | SRI |
703: +-------+
704: |
705: +----------++-----------+
706: | | |
707: +-------+ +------+ +-------+
708: | CSL | | ISTC | | Hosts |
709: +-------+ +------+ +-------+
710: | |
711: +-------+ +-------+
712: | Hosts | | Hosts |
713: +-------+ +-------+
714:
715:
716:
717:
718:
719:
720:
721:
722:
723:
724: Lottor [Page 13]
725:
726: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
727:
728:
729: [File "CONFIG.CMD". Since bootstrap files are not standardized, this
730: file is presented using a pseudo configuration file syntax.]
731:
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
738:
739:
740:
741:
742:
743:
744:
745:
746:
747:
748:
749:
750:
751:
752:
753:
754:
755:
756:
757:
758:
759:
760:
761:
762:
763:
764:
765:
766:
767:
768:
769:
770:
771:
772:
773:
774:
775:
776:
777:
778:
779:
780: Lottor [Page 14]
781:
782: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
783:
784:
785: [File "ROOT.SERVERS". Again, the format of this file is not
786: standardized.]
787:
788: ;list of possible root servers
789: SRI-NIC.ARPA 10.0.0.51 26.0.0.73
790: C.ISI.EDU 10.0.0.52
791: BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2
792: A.ISI.EDU 26.3.0.103
793:
794:
795:
796:
797:
798:
799:
800:
801:
802:
803:
804:
805:
806:
807:
808:
809:
810:
811:
812:
813:
814:
815:
816:
817:
818:
819:
820:
821:
822:
823:
824:
825:
826:
827:
828:
829:
830:
831:
832:
833:
834:
835:
836: Lottor [Page 15]
837:
838: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
839:
840:
841: [File "SRI.ZONE"]
842:
843: SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
844: 870407 ;serial
845: 1800 ;refresh every 30 minutes
846: 600 ;retry every 10 minutes
847: 604800 ;expire after a week
848: 86400 ;default of an hour
849: )
850:
851: SRI.COM. NS KL.SRI.COM.
852: NS STRIPE.SRI.COM.
853: MX 10 KL.SRI.COM.
854:
855: ;SRI.COM hosts
856:
857: KL A 10.1.0.2
858: A 128.18.10.6
859: MX 10 KL.SRI.COM.
860:
861: STRIPE A 10.4.0.2
862: STRIPE A 128.18.10.4
863: MX 10 STRIPE.SRI.COM.
864:
865: NIC CNAME SRI-NIC.ARPA.
866:
867: Blackjack A 128.18.2.1
868: HINFO VAX-11/780 UNIX
869: WKS 128.18.2.1 TCP TELNET FTP
870:
871: CSL A 192.12.33.2
872: HINFO FOONLY-F4 TOPS20
873: WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER
874: MX 10 CSL.SRI.COM.
875:
876:
877:
878:
879:
880:
881:
882:
883:
884:
885:
886:
887:
888:
889:
890:
891:
892: Lottor [Page 16]
893:
894: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
895:
896:
897: [File "CSL.ZONE"]
898:
899: CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (
900: 870330 ;serial
901: 1800 ;refresh every 30 minutes
902: 600 ;retry every 10 minutes
903: 604800 ;expire after a week
904: 86400 ;default of a day
905: )
906:
907: CSL.SRI.COM. NS KL.SRI.COM.
908: NS STRIPE.SRI.COM.
909: A 192.12.33.2
910:
911: ;CSL.SRI.COM hosts
912:
913: A CNAME CSL.SRI.COM.
914: B A 192.12.33.3
915: HINFO FOONLY-F4 TOPS20
916: WKS 192.12.33.3 TCP TELNET FTP SMTP
917: GW A 10.2.0.2
918: A 192.12.33.1
919: A 128.18.1.1
920: HINFO PDP-11/23 MOS
921: SMELLY A 192.12.33.4
922: HINFO IMAGEN IMAGEN
923: SQUIRREL A 192.12.33.5
924: HINFO XEROX-1100 INTERLISP
925: VENUS A 192.12.33.7
926: HINFO SYMBOLICS-3600 LISPM
927: HELIUM A 192.12.33.30
928: HINFO SUN-3/160 UNIX
929: ARGON A 192.12.33.31
930: HINFO SUN-3/75 UNIX
931: RADON A 192.12.33.32
932: HINFO SUN-3/75 UNIX
933:
934:
935:
936:
937:
938:
939:
940:
941:
942:
943:
944:
945:
946:
947:
948: Lottor [Page 17]
949:
950: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
951:
952:
953: [File "ISTC.ZONE"]
954:
955: ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
956: 870406 ;serial
957: 1800 ;refresh every 30 minutes
958: 600 ;retry every 10 minutes
959: 604800 ;expire after a week
960: 86400 ;default of a day
961: )
962:
963: ISTC.SRI.COM. NS KL.SRI.COM.
964: NS STRIPE.SRI.COM.
965: MX 10 SPAM.ISTC.SRI.COM.
966:
967: ; ISTC hosts
968:
969: joyce A 128.18.4.2
970: HINFO VAX-11/750 UNIX
971: bozo A 128.18.0.6
972: HINFO SUN UNIX
973: sundae A 128.18.0.11
974: HINFO SUN UNIX
975: tsca A 128.18.0.201
976: A 10.3.0.2
977: HINFO VAX-11/750 UNIX
978: MX 10 TSCA.ISTC.SRI.COM.
979: tsc CNAME tsca
980: prmh A 128.18.0.203
981: A 10.2.0.51
982: HINFO PDP-11/44 UNIX
983: spam A 128.18.4.3
984: A 10.2.0.107
985: HINFO VAX-11/780 UNIX
986: MX 10 SPAM.ISTC.SRI.COM.
987:
988:
989:
990:
991:
992:
993:
994:
995:
996:
997:
998:
999:
1000:
1001:
1002:
1003:
1004: Lottor [Page 18]
1005:
1006: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
1007:
1008:
1009: [File "SRINET.ZONE"]
1010:
1011: 18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
1012: 870406 ;serial
1013: 1800 ;refresh every 30 minutes
1014: 600 ;retry every 10 minutes
1015: 604800 ;expire after a week
1016: 86400 ;default of a day
1017: )
1018:
1019: 18.128.IN-ADDR.ARPA. NS KL.SRI.COM.
1020: NS STRIPE.SRI.COM.
1021: PTR GW.CSL.SRI.COM.
1022:
1023: ; SRINET [128.18.0.0] Address Translations
1024:
1025: ; SRI.COM Hosts
1026: 1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM.
1027:
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.
1035:
1036: ; CSL.SRI.COM Hosts
1037: 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.
1038:
1039:
1040:
1041:
1042:
1043:
1044:
1045:
1046:
1047:
1048:
1049:
1050:
1051:
1052:
1053:
1054:
1055:
1056:
1057:
1058:
1059:
1060: Lottor [Page 19]
1061:
1062: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
1063:
1064:
1065: [File "SRI-CSL-NET.ZONE"]
1066:
1067: 33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (
1068: 870404 ;serial
1069: 1800 ;refresh every 30 minutes
1070: 600 ;retry every 10 minutes
1071: 604800 ;expire after a week
1072: 86400 ;default of a day
1073: )
1074:
1075: 33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM.
1076: NS STRIPE.SRI.COM.
1077: PTR GW.CSL.SRI.COM.
1078:
1079: ; SRI-CSL-NET [192.12.33.0] Address Translations
1080:
1081: ; SRI.COM Hosts
1082: 2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM.
1083:
1084: ; CSL.SRI.COM Hosts
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.
1093:
1094:
1095:
1096:
1097:
1098:
1099:
1100:
1101:
1102:
1103:
1104:
1105:
1106:
1107:
1108:
1109:
1110:
1111:
1112:
1113:
1114:
1115:
1116: Lottor [Page 20]
1117:
1118: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
1119:
1120:
1121: APPENDIX
1122:
1123: BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD
1124: UNIX
1125:
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.
1130:
1131: The boot file for BIND is usually called "named.boot". This
1132: corresponds to file "CONFIG.CMD" in the example section.
1133:
1134: --------------------------------------------------------
1135: cache . named.ca
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: --------------------------------------------------------
1142:
1143: The cache file for BIND is usually called "named.ca". This
1144: corresponds to file "ROOT.SERVERS" in the example section.
1145:
1146: -------------------------------------------------
1147: ;list of possible root servers
1148: . 1 IN NS SRI-NIC.ARPA.
1149: NS C.ISI.EDU.
1150: NS BRL-AOS.ARPA.
1151: NS C.ISI.EDU.
1152: ;and their addresses
1153: SRI-NIC.ARPA. A 10.0.0.51
1154: A 26.0.0.73
1155: C.ISI.EDU. A 10.0.0.52
1156: BRL-AOS.ARPA. A 192.5.25.82
1157: A 192.5.22.82
1158: A 128.20.1.2
1159: A.ISI.EDU. A 26.3.0.103
1160: -------------------------------------------------
1161:
1162:
1163:
1164:
1165:
1166:
1167:
1168:
1169:
1170:
1171:
1172: Lottor [Page 21]
1173:
1174: RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
1175:
1176:
1177: REFERENCES
1178:
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.
1182:
1183: [2] Partridge, C., "Mail Routing and the Domain System", RFC-974,
1184: CSNET CIC BBN Laboratories, January 1986.
1185:
1186: [3] Mockapetris, P., "Domains Names - Concepts and Facilities",
1187: RFC-1034, USC/Information Sciences Institute, November 1987.
1188:
1189: [4] Mockapetris, P., "Domain Names - Implementations Specification",
1190: RFC-1035, USC/Information Sciences Institute, November 1987.
1191:
1192:
1193:
1194:
1195:
1196:
1197:
1198:
1199:
1200:
1201:
1202:
1203:
1204:
1205:
1206:
1207:
1208:
1209:
1210:
1211:
1212:
1213:
1214:
1215:
1216:
1217:
1218:
1219:
1220:
1221:
1222:
1223:
1224:
1225:
1226:
1227:
1228: Lottor [Page 22]
1229:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.