1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 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 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 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 781 782 783 784 785 786 787 788 789 790 791 792 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 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 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 1229
|
Network Working Group M. Lottor
Request For Comments: 1033 SRI International
November 1987
DOMAIN ADMINISTRATORS OPERATIONS GUIDE
STATUS OF THIS MEMO
This RFC provides guidelines for domain administrators in operating a
domain server and maintaining their portion of the hierarchical
database. Familiarity with the domain system is assumed.
Distribution of this memo is unlimited.
ACKNOWLEDGMENTS
This memo is a formatted collection of notes and excerpts from the
references listed at the end of this document. Of particular mention
are Paul Mockapetris and Kevin Dunlap.
INTRODUCTION
A domain server requires a few files to get started. It will
normally have some number of boot/startup files (also known as the
"safety belt" files). One section will contain a list of possible
root servers that the server will use to find the up-to-date list of
root servers. Another section will list the zone files to be loaded
into the server for your local domain information. A zone file
typically contains all the data for a particular domain. This guide
describes the data formats that can be used in zone files and
suggested parameters to use for certain fields. If you are
attempting to do anything advanced or tricky, consult the appropriate
domain RFC's for more details.
Note: Each implementation of domain software may require different
files. Zone files are standardized but some servers may require
other startup files. See the appropriate documentation that comes
with your software. See the appendix for some specific examples.
ZONES
A zone defines the contents of a contiguous section of the domain
space, usually bounded by administrative boundaries. There will
typically be a separate data file for each zone. The data contained
in a zone file is composed of entries called Resource Records (RRs).
Lottor [Page 1]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
You may only put data in your domain server that you are
authoritative for. You must not add entries for domains other than
your own (except for the special case of "glue records").
A domain server will probably read a file on start-up that lists the
zones it should load into its database. The format of this file is
not standardized and is different for most domain server
implementations. For each zone it will normally contain the domain
name of the zone and the file name that contains the data to load for
the zone.
ROOT SERVERS
A resolver will need to find the root servers when it first starts.
When the resolver boots, it will typically read a list of possible
root servers from a file.
The resolver will cycle through the list trying to contact each one.
When it finds a root server, it will ask it for the current list of
root servers. It will then discard the list of root servers it read
from the data file and replace it with the current list it received.
Root servers will not change very often. You can get the names of
current root servers from the NIC.
FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
NIC@SRI-NIC.ARPA.
As of this date (June 1987) they are:
SRI-NIC.ARPA 10.0.0.51 26.0.0.73
C.ISI.EDU 10.0.0.52
BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2
A.ISI.EDU 26.3.0.103
RESOURCE RECORDS
Records in the zone data files are called resource records (RRs).
They are specified in RFC-883 and RFC-973. An RR has a standard
format as shown:
<name> [<ttl>] [<class>] <type> <data>
The record is divided into fields which are separated by white space.
<name>
The name field defines what domain name applies to the given
Lottor [Page 2]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
RR. In some cases the name field can be left blank and it will
default to the name field of the previous RR.
<ttl>
TTL stands for Time To Live. It specifies how long a domain
resolver should cache the RR before it throws it out and asks a
domain server again. See the section on TTL's. If you leave
the TTL field blank it will default to the minimum time
specified in the SOA record (described later).
<class>
The class field specifies the protocol group. If left blank it
will default to the last class specified.
<type>
The type field specifies what type of data is in the RR. See
the section on types.
<data>
The data field is defined differently for each type and class
of data. Popular RR data formats are described later.
The domain system does not guarantee to preserve the order of
resource records. Listing RRs (such as multiple address records) in
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 name
server. All comparisons and lookups in the name server are case
insensitive.
Parenthesis ("(",")") are used to group data that crosses a line
boundary.
A semicolon (";") starts a comment; the remainder of the line is
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
NAMES
A domain name is a sequence of labels separated by dots.
Domain names in the zone files can be one of two types, either
absolute or relative. An absolute name is the fully qualified domain
name and is terminated with a period. A relative name does not
terminate with a period, and the current default domain is appended
to it. The default domain is usually the name of the domain that was
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 such
as SMTP do have name restrictions. Because of other protocol
restrictions, only the following characters are recommended for use
in a host name (besides the dot separator):
"A-Z", "a-z", "0-9", dash and underscore
TTL's (Time To Live)
It is important that TTLs are set to appropriate values. The TTL is
the time (in seconds) that a resolver will use the data it got from
your server before it asks your server again. If you set the value
too low, your server will get loaded down with lots of repeat
requests. If you set it too high, then information you change will
not get distributed in a reasonable amount of time. If you leave the
TTL field blank, it will default to what is specified in the SOA
record for the zone.
Most host information does not change much over long time periods. A
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 week
(604800). Then, if you know some data will be changing in the near
future, set the TTL for that RR down to a lower value (an hour to a
day) until the change takes place, and then put it back up to its
previous value.
Also, all RRs with the same name, class, and type should have the
same TTL value.
CLASSES
The domain system was designed to be protocol independent. The class
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 class
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.
TYPES
There are many defined RR types. For a complete list, see the domain
specification RFCs. Here is a list of current commonly used types.
The data for each type is described in the data section.
Designation Description
==========================================
SOA Start Of Authority
NS Name Server
A Internet Address
CNAME Canonical Name (nickname pointer)
HINFO Host Information
WKS Well Known Services
MX Mail Exchanger
PTR Pointer
SOA (Start Of Authority)
<name> [<ttl>] [<class>] SOA <origin> <person> (
<serial>
<refresh>
<retry>
<expire>
<minimum> )
The Start Of Authority record designates the start of a zone. The
zone ends at the next SOA record.
<name> is the name of the zone.
<origin> is the name of the host on which the master zone file
resides.
<person> is a mailbox for the person responsible for the zone. It is
formatted like a mailing address but the at-sign that normally
separates the user from the host name is replaced with a dot.
<serial> is the version number of the zone file. It should be
incremented anytime a change is made to data in the zone.
Lottor [Page 5]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
<refresh> is how long, in seconds, a secondary name server is to
check with the primary name server to see if an update is needed. A
good value here would be one hour (3600).
<retry> is how long, in seconds, a secondary name server is to retry
after a failure to check for a refresh. A good value here would be
10 minutes (600).
<expire> is the upper limit, in seconds, that a secondary name server
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, about
42 days.
<minimum> is the minimum number of seconds to be used for TTL values
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 record
would look something like:
@ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
45 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400 ) ;minimum
NS (Name Server)
<domain> [<ttl>] [<class>] NS <server>
The NS record lists the name of a machine that provides domain
service for a particular domain. The name associated with the RR is
the domain name and the data portion is the name of a host that
provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide
name lookup service for the domain COM then the following entries
would be used:
COM. NS SRI-NIC.ARPA.
NS C.ISI.EDU.
Note that the machines providing name service do not have to live in
the named domain. There should be one NS record for each server for
a domain. Also note that the name "COM" defaults for the second NS
record.
NS records for a domain exist in both the zone that delegates the
domain, and in the domain itself.
Lottor [Page 6]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
GLUE RECORDS
If the name server host for a particular domain is itself inside the
domain, then a 'glue' record will be needed. A glue record is an A
(address) RR that specifies the address of the server. Glue records
are only needed in the server delegating the domain, not in the
domain itself. If for example the name server for domain SRI.COM was
KL.SRI.COM, then the NS record would look like this, but you will
also need to have the following A record.
SRI.COM. NS
KL.SRI.COM. KL.SRI.COM. A 10.1.0.2.
A (Address)
<host> [<ttl>] [<class>] A <address>
The data for an A record is an internet address in dotted decimal
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> [<ttl>] [<class>] CNAME <host>
The CNAME record is used for nicknames. The name associated with the
RR is the nickname. The data portion is the official name. For
example, a machine named SRI-NIC.ARPA may want to have the nickname
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 the
same class.
Nicknames are also useful when a host changes it's name. In that
case, it is usually a good idea to have a CNAME pointer so that
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)
<host> [<ttl>] [<class>] HINFO <hardware> <software>
The HINFO record gives information about a particular host. The data
is two strings separated by whitespace. The first string is a
hardware description and the second is software. The hardware is
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 the
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 UNIX
WKS (Well Known Services)
<host> [<ttl>] [<class>] WKS <address> <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 WKS
record lists what services are available at a certain address using a
certain protocol. The common protocols are TCP or UDP. A sample WKS
record for a host offering the same services on all address would
look like:
Official protocol names can be found in the latest Assigned Numbers
RFC, the latest of which is RFC-1010.
SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP
WKS 10.0.0.51 UDP TIME
WKS 26.0.0.73 TCP TELNET FTP SMTP
WKS 26.0.0.73 UDP TIME
MX (Mail Exchanger) (See RFC-974 for more details.)
<name> [<ttl>] [<class>] MX <preference> <host>
MX records specify where mail for a domain name should be delivered.
There may be multiple MX records for a particular name. The
preference value specifies the order a mailer should try multiple MX
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 host
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 three
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 want
their mail to go through a mail gateway that knows how to deliver
mail to them. If they would like mail addressed to any host in the
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 on
anything in FOO.COM, but that it won't match a plain FOO.COM.
IN-ADDR.ARPA
The structure of names in the domain system is set up in a
hierarchical way such that the address of a name can be found by
tracing down the domain tree contacting a server for each label of
the name. Because of this 'indexing' based on name, there is no easy
way to translate a host address back into its host name.
In order to do the reverse translation easily, a domain was created
that uses hosts' addresses as part of a name that then points to the
data for that host. In this way, there is now an 'index' to hosts'
RRs based on their address. This address mapping domain is called
IN-ADDR.ARPA. Within that domain are subdomains for each network,
based on network number. Also, for consistency and natural
groupings, the 4 octets of a host number are reversed.
For example, the ARPANET is net 10. That means there is a domain
called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at
51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
(who's address is 10.0.0.51). Since the NIC is also on the MILNET
(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 format
of these special pointers is defined below along with the examples
for the NIC.
Lottor [Page 9]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
PTR
<special-name> [<ttl>] [<class>] PTR <name>
The PTR record is used to let special names point to some other
location in the domain tree. They are mainly used in the IN-
ADDR.ARPA records for translation of addresses to names. PTR's
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 net
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's
The IN-ADDR tree is also used to locate gateways on a particular
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 network
number alone. These records have only 1, 2, or 3 octets as part of
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 different
networks, one class A, one class B and one class C. It will have the
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 one
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 following
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
INSTRUCTIONS
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 zone
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 the
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 of
the domain the host is in.
Remove all the hosts' PTR records from the IN-ADDR zone files
for each network the host was on.
Adding gateways.
Follow instructions for adding a host.
Add the gateway location PTR records for each network the
gateway is on.
Deleting gateways.
Follow instructions for deleting a host.
Also delete the gateway location PTR records for each network
Lottor [Page 11]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
the gateway was on.
COMPLAINTS
These are the suggested steps you should take if you are having
problems that you believe are caused by someone else's name server:
1. Complain privately to the responsible person for the domain. You
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 the
domain. Complain. You can also find domain contacts on the NIC in
the file NETINFO:DOMAIN-CONTACTS.TXT
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 FILES
The following examples show how zone files are set up for a typical
organization. SRI will be used as the example organization. SRI has
decided to divided their domain SRI.COM into a few subdomains, one
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 domain
which are on net 192.12.33. Note that a domain does not have to
correspond to a physical network.
The examples do not necessarily correspond to actual data in use
by the SRI domain.
SRI Domain Organization
+-------+
| 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, this
file is presented using a pseudo configuration file syntax.]
load root server list from file ROOT.SERVERS
load zone SRI.COM. from file SRI.ZONE
load zone CSL.SRI.COM. from file CSL.ZONE
load zone ISTC.SRI.COM. from file ISTC.ZONE
load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE
load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
Lottor [Page 14]
RFC 1033 DOMAIN OPERATIONS GUIDE November 1987
[File "ROOT.SERVERS". Again, the format of this file is not
standardized.]
;list of possible root servers
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 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of an hour
)
SRI.COM. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
MX 10 KL.SRI.COM.
;SRI.COM hosts
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 UNIX
WKS 128.18.2.1 TCP TELNET FTP
CSL A 192.12.33.2
HINFO FOONLY-F4 TOPS20
WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER
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 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
CSL.SRI.COM. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
A 192.12.33.2
;CSL.SRI.COM hosts
A CNAME CSL.SRI.COM.
B A 192.12.33.3
HINFO FOONLY-F4 TOPS20
WKS 192.12.33.3 TCP TELNET FTP SMTP
GW A 10.2.0.2
A 192.12.33.1
A 128.18.1.1
HINFO PDP-11/23 MOS
SMELLY A 192.12.33.4
HINFO IMAGEN IMAGEN
SQUIRREL A 192.12.33.5
HINFO XEROX-1100 INTERLISP
VENUS A 192.12.33.7
HINFO SYMBOLICS-3600 LISPM
HELIUM A 192.12.33.30
HINFO SUN-3/160 UNIX
ARGON A 192.12.33.31
HINFO SUN-3/75 UNIX
RADON A 192.12.33.32
HINFO SUN-3/75 UNIX
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 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
ISTC.SRI.COM. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
MX 10 SPAM.ISTC.SRI.COM.
; ISTC hosts
joyce A 128.18.4.2
HINFO VAX-11/750 UNIX
bozo A 128.18.0.6
HINFO SUN UNIX
sundae A 128.18.0.11
HINFO SUN UNIX
tsca A 128.18.0.201
A 10.3.0.2
HINFO VAX-11/750 UNIX
MX 10 TSCA.ISTC.SRI.COM.
tsc CNAME tsca
prmh A 128.18.0.203
A 10.2.0.51
HINFO PDP-11/44 UNIX
spam A 128.18.4.3
A 10.2.0.107
HINFO VAX-11/780 UNIX
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 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
18.128.IN-ADDR.ARPA. NS KL.SRI.COM.
NS STRIPE.SRI.COM.
PTR GW.CSL.SRI.COM.
; SRINET [128.18.0.0] Address Translations
; SRI.COM Hosts
1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM.
; ISTC.SRI.COM Hosts
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 Hosts
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 ;serial
1800 ;refresh every 30 minutes
600 ;retry every 10 minutes
604800 ;expire after a week
86400 ;default of a day
)
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 Translations
; SRI.COM Hosts
2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM.
; CSL.SRI.COM Hosts
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
APPENDIX
BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD
UNIX
This section describes two BIND implementation specific files; the
boot file and the cache file. BIND has other options, files, and
specifications that are not described here. See the Name Server
Operations Guide for BIND for details.
The boot file for BIND is usually called "named.boot". This
corresponds to file "CONFIG.CMD" in the example section.
--------------------------------------------------------
cache . named.ca
primary SRI.COM SRI.ZONE
primary CSL.SRI.COM CSL.ZONE
primary ISTC.SRI.COM ISTC.ZONE
primary 18.128.IN-ADDR.ARPA SRINET.ZONE
primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE
--------------------------------------------------------
The cache file for BIND is usually called "named.ca". This
corresponds to file "ROOT.SERVERS" in the example section.
-------------------------------------------------
;list of possible root servers
. 1 IN NS SRI-NIC.ARPA.
NS C.ISI.EDU.
NS BRL-AOS.ARPA.
NS C.ISI.EDU.
;and their addresses
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
REFERENCES
[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]
|