386BSD 0.0 development
[unix-history] / usr / src / usr.sbin / named / doc / rfc1033.lpr
CommitLineData
32d7a0bb
WJ
1Network Working Group M. Lottor
2Request For Comments: 1033 SRI International
3 November 1987
4
5
6 DOMAIN ADMINISTRATORS OPERATIONS GUIDE
7
8
9
10STATUS 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
17ACKNOWLEDGMENTS
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
23INTRODUCTION
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
42ZONES
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
52Lottor [Page 1]
53\f
54RFC 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
68ROOT 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 NIC@SRI-NIC.ARPA.
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
92RESOURCE 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
108Lottor [Page 2]
109\f
110RFC 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
164Lottor [Page 3]
165\f
166RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
167
168
169NAMES
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
188TTL'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
211CLASSES
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
220Lottor [Page 4]
221\f
222RFC 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
229TYPES
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
249SOA (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
276Lottor [Page 5]
277\f
278RFC 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
308NS (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
332Lottor [Page 6]
333\f
334RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
335
336
337GLUE 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
351A (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
362CNAME ( 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
388Lottor [Page 7]
389\f
390RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
391
392
393HINFO (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
413WKS (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
432MX (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
444Lottor [Page 8]
445\f
446RFC 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
472IN-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
500Lottor [Page 9]
501\f
502RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
503
504
505PTR
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
521GATEWAY 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
556Lottor [Page 10]
557\f
558RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
559
560
561INSTRUCTIONS
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
612Lottor [Page 11]
613\f
614RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
615
616
617 the gateway was on.
618
619COMPLAINTS
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
668Lottor [Page 12]
669\f
670RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
671
672
673EXAMPLE 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
724Lottor [Page 13]
725\f
726RFC 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
780Lottor [Page 14]
781\f
782RFC 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
836Lottor [Page 15]
837\f
838RFC 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
892Lottor [Page 16]
893\f
894RFC 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
948Lottor [Page 17]
949\f
950RFC 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
1004Lottor [Page 18]
1005\f
1006RFC 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
1060Lottor [Page 19]
1061\f
1062RFC 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
1116Lottor [Page 20]
1117\f
1118RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
1119
1120
1121APPENDIX
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
1172Lottor [Page 21]
1173\f
1174RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
1175
1176
1177REFERENCES
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
1228Lottor [Page 22]
1229\f