N  RELEASEB.SAVȘ RELEASEB.SAV;BACKUP/LOG/INTERCHANGE RELBDIR RELEASEB.SAV/SAVE/BLOCK=8192 ORCHARD @vV5.3 _ETHEL::  _$1$DUA1: V5.3   J*[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]128_104_138.ZONE_MASTER;12+,./@ 4NR-B0123KPWO 56@꒛Y7yћY8@>9G@HJ;0; Zone master file for 138.104.128.in-addr.arpa; ; Modified:%; 910307 - CAK. Added 142 for Wismrc3M; 910307 - CAK. Added 197-198 for MACS in room 607 and 611. Changed ns record"; for cs.wisc.edu to joker.cs.edu;@@ in soa don.waisman.wisc.edu. ( ; sourceN orchard.waisman.wisc.edu. ; responsible person1 91031400 ; serialA 43200 ; refresh period (12 hours): 3600 ; retry time (1 hour)? 5184000 ; expire time (60 days); 172800 ) ; minimum (2 days)5 in ns don.waisman.wisc.edu.2 in ns joker.cs.wisc.edu.5 in ns mailrus.cc.umich.edu.9140 in ptr wismrc1.waisman.wisc.edu.9141 in ptr wismrc2.waisman.wisc.edu.9142 in ptr wismrc3.waisman.wisc.edu.6151 in ptr shop.waisman.wisc.edu.=152 in ptr yellowbrick.waisman.wisc.edu.8153 in ptr brudwn.waisman.wisc.edu.8154 in ptr brujon.waisman.wisc.edu.8155 in ptr bruvic.waisman.wisc.edu.9156 in ptr room247.waisman.wisc.edu.8157 in ptr visexp.waisman.wisc.edu.8159 in ptr bmusec.waisman.wisc.edu.8160 in ptr gustav.waisman.wisc.edu.7161 in ptr spike.waisman.wisc.edu.8162 in ptr smitty.waisman.wisc.edu.8167 in ptr bigmac.waisman.wisc.edu.9168 in ptr ddaging.waisman.wisc.edu.6169 in ptr toto.waisman.wisc.edu.7170 in ptr harry.waisman.wisc.edu.7171 in ptr ethel.waisman.wisc.edu.5172 in ptr don.waisman.wisc.edu.7173 in ptr words.waisman.wisc.edu.8175 in ptr vision.waisman.wisc.edu.8176 in ptr wccomp.waisman.wisc.edu.8177 in ptr retina.waisman.wisc.edu.8178 in ptr morfus.waisman.wisc.edu.7179 in ptr admin.waisman.wisc.edu.7180 in ptr nchem.waisman.wisc.edu.8181 in ptr infant.waisman.wisc.edu.8182 in ptr caruso.waisman.wisc.edu.8183 in ptr sounds.waisman.wisc.edu.6184 in ptr poet.waisman.wisc.edu.7185 in ptr lloyd.waisman.wisc.edu.7186 in ptr georg.waisman.wisc.edu.7187 in ptr aging.waisman.wisc.edu.8188 in ptr syntax.waisman.wisc.edu.8189 in ptr darwin.waisman.wisc.edu.8190 in ptr pepper.waisman.wisc.edu.8191 in ptr medgen.waisman.wisc.edu.7192 in ptr toron.waisman.wisc.edu.8194 in ptr winkie.waisman.wisc.edu.8195 in ptr mac446.waisman.wisc.edu.8196 in ptr mac447.waisman.wisc.edu.8197 in ptr mac607.waisman.wisc.edu.8198 in ptr mac611.waisman.wisc.edu. I*[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]192_012_223.ZONE_MASTER;6+,./@ 4N-B0123KPWO5 6@{^f7I{889G@HJ;/; Zone master file for 223.12.192.in-addr.arpa;@@ in soa don.waisman.wisc.edu. ( ; sourceN orchard.waisman.wisc.edu. ; responsible person1 90060500 ; serialA 43200 ; refresh period (12 hours): 3600 ; retry time (1 hour)? 5184000 ; expire time (60 days); 172800 ) ; minimum (2 days)5 in ns don.waisman.wisc.edu., in ns cs.wisc.edu.5 in ns mailrus.cc.umich.edu.61 in ptr antm.waisman.wisc.edu.82 in ptr wizard.waisman.wisc.edu.63 in ptr lion.waisman.wisc.edu.94 in ptr dorothy.waisman.wisc.edu.78 in ptr ubvax.waisman.wisc.edu. I*[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]192_012_224.ZONE_MASTER;4+,./@ 4N-B0123KPWO56_f7 {8]9G@HJ;/; Zone master file for 224.12.192.in-addr.arpa;@@ in soa don.waisman.wisc.edu. ( ; sourceN orchard.waisman.wisc.edu. ; responsible person1 90060500 ; serialA 43200 ; refresh period (12 hours): 3600 ; retry time (1 hour)? 5184000 ; expire time (60 days); 172800 ) ; minimum (2 days)5 in ns don.waisman.wisc.edu., in ns cs.wisc.edu.5 in ns mailrus.cc.umich.edu.61 in ptr antm.waisman.wisc.edu.82 in ptr wizard.waisman.wisc.edu.63 in ptr lion.waisman.wisc.edu.64 in ptr toto.waisman.wisc.edu.5101 in ptr oz1.waisman.wisc.edu.5102 in ptr oz2.waisman.wisc.edu.5103 in ptr oz3.waisman.wisc.edu.5104 in ptr oz4.waisman.wisc.edu.5105 in ptr oz5.waisman.wisc.edu.5106 in ptr oz6.waisman.wisc.edu.5107 in ptr oz7.waisman.wisc.edu.5108 in ptr oz8.waisman.wisc.edu.5109 in ptr oz9.waisman.wisc.edu.6110 in ptr oz10.waisman.wisc.edu.6111 in ptr oz11.waisman.wisc.edu.6112 in ptr oz12.waisman.wisc.edu.6113 in ptr oz13.waisman.wisc.edu.6114 in ptr oz14.waisman.wisc.edu.6115 in ptr oz15.waisman.wisc.edu.6116 in ptr oz16.waisman.wisc.edu.6117 in ptr oz17.waisman.wisc.edu.6118 in ptr oz18.waisman.wisc.edu.6119 in ptr oz19.waisman.wisc.edu.6120 in ptr oz20.waisman.wisc.edu.6121 in ptr `]+J RELEASEB.SAVBI[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]192_012_224.ZONE_MASTER;4N oz21.waisman.wisc.edu.6122 in ptr oz22.waisman.wisc.edu.6123 in ptr oz23.waisman.wisc.edu.6124 in ptr oz24.waisman.wisc.edu.6125 in ptr oz25.waisman.wisc.edu.6126 in ptr oz26.waisman.wisc.edu.5201 in ptr pc1.waisman.wisc.edu.5202 in ptr pc2.waisman.wisc.edu.5203 in ptr pc3.waisman.wisc.edu.9*[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]DOC.TXT;7+,U.@/@ 4D@@r-B0123 KPWOA56u{-\7 2 ~-\8 2!.r9G@HJAPROGRAMS. . . . . . . . . . . . . . . . . . . . . . . . . . . 2A CHECK. . . . . . . . . . . . . . . . . . . . . . . . . . 2A EXAMINE. . . . . . . . . . . . . . . . . . . . . . . . . 2A LOOKUP . . . . . . . . . . . . . . . . . . . . . . . . . 3A PERIODIC_UPDATE. . . . . . . . . . . . . . . . . . . . . 5A PRINT. . . . . . . . . . . . . . . . . . . . . . . . . . 5A SERVE_TCP. . . . . . . . . . . . . . . . . . . . . . . . 6A SERVE_UDP. . . . . . . . . . . . . . . . . . . . . . . . 6A SERVE_UDP_FORKED . . . . . . . . . . . . . . . . . . . . 7A START. . . . . . . . . . . . . . . . . . . . . . . . . . 7A STOP . . . . . . . . . . . . . . . . . . . . . . . . . . 8A UPDATE_PRIMARY . . . . . . . . . . . . . . . . . . . . . 8AINITIALIZATION FILES. . . . . . . . . . . . . . . . . . . . . 9A Parameter file . . . . . . . . . . . . . . . . . . . . . 9A Protocols file . . . . . . . . . . . . . . . . . . . . . 12A Services file. . . . . . . . . . . . . . . . . . . . . . 12A Resource records files . . . . . . . . . . . . . . . . . 12ASET UP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13ATROUBLESHOOTING . . . . . . . . . . . . . . . . . . . . . . . 15 C The domain name server programs implement the server described8in RFC's 1034, and 1035. This document does not includeBintroductory material about the domain name system. That materialBcan be found in RFC 1033. The following resource record types areCimplemented: A, CNAME, HINFO, MB, MG, MINFO, MR, MX, NS, PTR, SOA,=TXT, and WKS. Only internet class is implemented. Automatic>refresh of zones in secondary servers is implemented. Inverse@queries and completion queries are not implemented. It uses the5CMU/Tektronix TCP/IP package for communication calls.> The cache is implemented as a global section. The globalBsection is created when the server is started and deleted when the>server is stopped. The backing file for the global section isCcreated when the server is started if necessary. It is not deleted<when the server is stopped so the cache will usually surviveAstopping and starting the server. Since several processes can beAaccessing the cache at once, VMS locks are used to control access?to individual records in the cache. If more than one node in aAcluster is running the domain server, each node must have its own(copy of the global section backing file.PROGRAMSCHECKB The check program verifies the integrity of the cache. If no?errors are found, the message "Passes all checks" is displayed.. Otherwise the first error found is displayed.0 CHECK should be invoked with a DCL command.DCL invocation: DOMAIN/CHECK optionsOptions:A /DEBUG_LEVEL=n Sets the level of debugging output. TheC higher the number, the greater the output.> The source code must be consulted to8 interpret the debugging output.EXAMINEC The examine program displays parts of the cache in hexadecimal+and ASCII. It is used as a debugging tool.2 EXAMINE should be invoked with a DCL command.DCL invocation: DOMAIN/EXAMINE= The invocation line should be followed with addresses toBexamine, one address per line, relative to the start of the cache,9in hexadecimal. The 32 bytes starting at the address are displayed.LOOKUP? The lookup program is in interactive program to do queries>requested by the user and print the result. It can be used to8examine data stored in the servers and to debug servers.DCL invocation: DOMAIN/LOOKUP@ The invocation line should be followed with commands giving/parameters to be set and names to be looked up. Commands: SET options ...? The SET command sets options for the following LOOKUPA commands. Options set with the SET command remain in effectC until changed with another SET command. The following options are available: /CLASS=class= The/CLASS option sets the class to be used for= LOOKUP commands. The class can be either INTERNET,: CHAOS, HESIOD, or ALL. The default is INTERNET. /FULL /NOFULL@ The /FULL option turns on full output from LOOKUP> commands. The /NOFULL option turns off full output.< Partial output just includes the resource recordsB returned by the server. Full output includes the query,C the resource records returned by the server, and the time> the server took to answer the query. The default is /NOFULL. /PORT=portB The /PORT option sets the TCP or UDP port number to@ be used by LOOKUP commands. /PORT defaults to 53, the+ standard port for domain service. /PROTOCOL=protocol@ The /PROTOCOL option sets the protocol to be used@ by LOOKUP commands. The protocol can be either TCP orC UDP. The default is UDP except for zone transfers, whereC the default is TCP. To request a zone transfer with UDP,B which is not allowed by the specification, the /PROTOCOL9 option must be specified on the LOOKUP command. /RECURSION /NORECURSIONA The /RECURSION option sets the recursion requested9 bit in queries sent by the LOOKUP command. The8 /NORECURSION option clears it. The default is /RECURSION. /RETRY=count? The /RETRY option sets the number of times a UDP@ request will be retried. The default is 3 retries for a total of 4 tries. /SERVER=server@ The /SERVER option sets the server to be used forA LOOKUP commands. The server can be specified as either@ a domain name or an internet address in dotted decimal5 notation. There is no default for /SERVER. /SUFFIX=suffix@ The /SUFFIX option sets a suffix to be applied to@ unqualified domain names (ones with no periods) by the LOOKUP command. /TIMEOUT=timeout= The /TIMEOUT option sets the length of time in= seconds the LOOKUP command will wait for a response@ before doing a retry when using the UDP protocol. The default is 5 seconds. j*L RELEASEB.SAVUB9[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]DOC.TXT;7D@8 /TYPE=type> The /TYPE option sets the query type for LOOKUP: commands. The following types are available: AA (Internet address), ANY (any records the server happens7 to have), CNAME (canonical name), HINFO (host; information), MAILA (mail agent, obsolete), MAILBC (mailbox), MB (mailbox), MD (mail destination, obsolete),? MF (mail forwarder, obsolete), MG (mail group), MINFO; (mail information), MR (mailbox rename), MX (mail= exchanger), NS (name server), NULL (undefined), PTR9 (pointer), TXT (text), WKS (well known server),: ZONE_TRANSFER (zone transfer). The default is A (Internet address). EXIT@ The EXIT command exits from LOOKUP and returns to DCL. HELP topic? The HELP command displays help about the topic given. LOOKUP target options...? The LOOKUP command does a query to the current server> about the target given and displays the results. Options? specified on the LOOKUP command apply only to that commandB and override options specified on previous SET commands. TheA same options as on the SET command can be used on the LOOKUP command. Examples: DOMAIN/LOOKUP! SET /SUFFIX=WAISMAN.WISC.EDU SET /SERVER=DON SET /TYPE=A LOOKUP HARRYB This sequence of commands will query DON.WAISMAN.WISC.EDU for/the Internet address of HARRY.WAISMAN.WISC.EDU.PERIODIC_UPDATE B The periodic update program keeps zones for which this serverAis a secondary server current, keeps resource records on the keep Ccurrent list current, and removes expired responses from the cache. C It normally runs continuously, checking the cache for expired data every 5 minutes.C PERIODIC_UPDATE can be run either by calling the CREPRC system Bservice or with a DCL command. It does not require that DCL be in=its address space. It is started by START when the server is 4started. PERIODIC_UPDATE requires SYSLCK privilege.DCL invocation:  DOMAIN/PERIODIC optionsOptions:A /DEBUG_LEVEL=n Sets the level of debugging output. The C higher the number, the greater the output. > The source code must be consulted to8 interpret the debugging output.PRINT ' The print program lists the cache. , PRINT should be run with a DCL command.DCL invocation:1 DOMAIN/PRINT options Options:; /LOCK Lock each record while it is being B printed. If this option is selected, the? process running print must have SYSLCK # privilege. @ /NOLOCK (Default) Do not lock each record whileA it is being printed. This may result inc@ inconsistent data being printed or evenA the program getting lost in the cache ifp? a record in the cache is updated while : PRINT is looking at it. The lockB information about each record is printed.A /OUTPUT=file Specifies the output file to receive the @ listing. The default extension for the@ file is .LIS. If the /OUTPUT qualifierA is not specified, the listing is written' to SYS$OUTPUT.t SERVE_TCPo@ SERVE_TCP accepts messages from the TCP domain server port,Aport 53, and answers them. A separate invocation of SERVE_TCP iserun for each TCP connection.= SERVE_TCP can be run either by calling the CREPRC systemcBservice or with a DCL command. It does not require that DCL be in<its address space. It is started by IPACP when a connection?request is received for port 53. SERVE_TCP requires PHY_IO andsSYSLCK privilege..DCL invocation:C DOMAIN/TCP optionsrOptions:A /DEBUG_LEVEL=n Sets the level of debugging output. ThePC higher the number, the greater the output. > The source code must be consulted to8 interpret the debugging output. SERVE_UDPE@ SERVE_UDP accepts messages from the UDP domain server port,;port 53, and answers the messages than can be answered from ?resource records in the cache. For the messages that cannot be 5answered from the cache, it creates a process runningM SERVE_UDP_FORKED to answer them.= SERVE_UDP can be run either by calling the CREPRC systemdBservice or with a DCL command. It does not require that DCL be in=its address space. It is started by START when the server isi9started. SERVE_UDP requires PHY_IO and SYSLCK privilege.nDCL invocation:l DOMAIN/UDP optionstOptions:A /DEBUG_LEVEL=n Sets the level of debugging output. ThepC higher the number, the greater the output. > The source code must be consulted to8 interpret the debugging output.A /FORK_REQUEST (Default) Makes SERVE_UDP queue requestsi? that cannot be answered from the caches< for processing by SERVE_UDP_FORKED.C /NOFORK_REQUEST Makes SERVE_UDP answer all requests. Thisi= option is used for debugging since amA request requiring queries to other hostsoC can required several minutes and SERVE_UDP > only processes one request at a time.C /RUN_PROGRAMS (Default) Makes SERVE_UDP create a process @ to run SERVE_UDP_FORKED if a message is2 queued to be processed by* SERVE_UDP_FORKED.C /NORUN_PROGRAMS Prevents SERVE_UDP from creating a processPA to run SERVE_UDP_FORKED. This option isd, used for debugging.SERVE_UDP_FORKED@ SERVE_UDP_FORKED answers queries queued to it by SERVE_UDP.= SERVE_UDP_FORKED can be run either by calling the CREPRCL?system service or with a DCL command. It does not require thatt?DCL be in its address space. It is started by SERVE_UDP when as9query is received that cannot be answered from the cache.o, SERVE_UDP_FORKED requires SYSLCK privilege.DCL invocation:e DOMAIN/FORK_SERVER optionsoOptions:A /DEBUG_LEVEL=n Sets the level of debugging output. TheC higher the number, the greater the output.> The source code must be consulted to8 interpret the debugging output.STARTTB START initializes the domain server programs. It creates the@global section for the cache if it does not exist, validates the@contents of the cache, initializes the cache if it is invalid orCthe /INITIALIZE option is used, reads the initialization files, and ;starts the UDP server, the periodic update program, and, if 5necessary, the primary update program. Note that thehAinitialization file is only read if the cache is initialized. Ite>can be run as part of the system bootstrap procedure after the@TCP/IP package has been initialized. The process in which it is>run should have SYSGBL, SYSLCK, PHY_IO, and PRMGBL privileges.DCL invocation:e DOMAIN/START options Options:A /DEBUG_LEVEL=n Si RELEASEB.SAVUB9[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]DOC.TXT;7D@ets the level of debugging output. TheuC higher the number, the greater the output.F> The source code must be consulted to8 interpret the debugging output.> /INITIALIZE Unconditionally initialize the cache.B This qualifier must be used if the cache@ is intact and an initialization file isB changed. The primary update program will= be started if START starts programs.sB /NOINITIALIZE (Default) Initialize the cache only if it@ does not exist or is corrupted. If the< cache is intact, the primary update< program will not be started and the? initialization files will not be read.t@ /RUN_PROGRAMS (Default) Create processes with the UDP< server program, the periodic update@ program, and, if necessary, the primary( update program.= /NORUN_PROGRAMS Do not create processes with the UDPn< server program, the periodic updateA program, and the primary update program.tA This option is used mainly to debug they= programs START would normally start.STOP> STOP stops the UDP server process and the periodic update-process and removes the cache global section. @ STOP can be run either by calling the CREPRC system service>or with a DCL command. It does not require that DCL be in itsAaddress space. It is started by START when the server is startedtCand the cache is not intact and manually when the primary zone dataT@is changed. STOP requires PRMGBL, SYSGBL, and SYSLCK privilege.DCL invocation: DOMAIN/STOP optionsOptions:A /DEBUG_LEVEL=n Sets the level of debugging output. TheSC higher the number, the greater the output.r> The source code must be consulted to8 interpret the debugging output.UPDATE_PRIMARYB UPDATE_PRIMARY reads the zone master files for the server andAstores them in the cache. If an error is found in any file read,Ithe cache is not changed.bB UPDATE_PRIMARY can be run either by calling the CREPRC systemBservice or with a DCL command. It does not require that DCL be in=its address space. It is started by START when the server isCAstarted and the cache is not intact and manually when the primaryp@zone data is changed. UPDATE_PRIMARY requires SYSLCK privilege.DCL invocation:  DOMAIN/PRIMARY optionsbOptions:A /DEBUG_LEVEL=n Sets the level of debugging output. The C higher the number, the greater the output..> The source code must be consulted to8 interpret the debugging output.INITIALIZATION FILES? START reads several text files if it has to initialize thetBcache. These files must be prepared manually before START is run.A In all the files, everything between a semicolon (;) and the ende=of the line is treated as a comment and ignored. In general, =letter case does not matter, although it will be preserved in Cresource records. In the command and resource record descriptions, >items shown in upper case are keywords which should be used as;shown, although case does not matter. Items shown in angle ?brackets (< >) should be replaced with a value. Ellipsis (...) ?indicate that the last item on the line may be repeated as many times as needed.Parameter file; The parameter file describes the zones the server will 8maintain, initialization data, nearby servers, and other3information. It is read by START using the logical DOMAIN$SERVER_STARTUP. Cache command Format: CACHE C Gives the size for the cache in bytes. A cache sizeVA of 512,000 bytes (1000 pages) will be used if the cacherA command is not used. All the data for zones the serverT@ holds as both a primary and secondary server is storedB in the cache as well as responses that have not expired.B If the server holds many or large zones, the cache size# may have to be increased.sWorkset commando Format:1 WORKSET nB Gives the working set quota and extent for programs9 started by START. can be either > PERIODIC_UPDATE, UDP_SERVER, or UPDATE_PRIMARY. The: working set quota and extent are given in pages.Primary command Format:) PRIMARY SA Indicates that the server will be a primary servera@ for the zone named. The resource records for the zone, are to be found in the file named.Secondary commandh Format:1 SECONDARY ...tC Indicates that the server will be a secondary server@ for the zone named. The resource records for the zone7 will be copied from one of the servers named.vForwarder commandV Format:% FORWARDER ...o? Indicates that the server may forward queries to A the servers named. In general, if FORWARDERONLY is not : specified, the server prefers to send queries to> authoritative servers rather than forwarder servers.Forwarderonly commandt Format: FORWARDERONLY > Indicates that the server should only query the@ forwarder servers that are listed in this file and not> any servers it learns about in responses to queries.Initial commanda Format: INITIAL = Indicates that the server should read resource > records from the file named to initialize the cache.B These resource records will not be returned in responseB to any query but may be used by the server to find otherA servers. Therefore, only NS and A resource records are ; of any use in the initialization file. Since the = resource records in the initialization file must beS< updated manually if any of the information on themA changes, the fewer resource records the better. On the_C other hand, these resource records are used to initialize.? the server so the more options the server has to findu@ data, the more likely it is to be able to find all the data it needs.Keep current command Format:! KEEPCURRENT t> Indicates that the server should read a list ofB resource records to be kept current from the file named.B Each record in the file should consist of a domain nameB and a resource record type. The server will query otherA servers for the resource records listed often enough so A that they never time out in the cache. Most sites will C want the NS resource records of the root servers on theirg> keep current list and perhaps other servers that are> likely to be used. Note that it is not necessary toB explicitly list A records for the servers along with the; NS records for the domain since the A  RELEASEB.SAVUB9[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]DOC.TXT;7D@s{,records ared- returned along with the NS records.PPreferred address commandp Format:& PREFERREDADDRESS > Indicates that the server should read a list ofB network preferences from the file named. Each record is in the formp6 C where and are in internetC@ address dotted decimal notation and is anC integer. When the server needs to contact another server A and that server has more than one internet address, the A server checks the address preference list. It uses the @ address that has the lowest preference value among the4 preference records that match according to/ & == e: & < This can be used to encode the network topology to6 minimize the number of hops a message takes.Protocols fileA The protocols file contains a list of the protocol names andyAthe corresponding protocol numbers. It is used by UPDATE_PRIMARYfAfor the protocol names used on WKS resource records. It is found@by the logical DOMAIN$SERVER_PROTOCOLS. Each record consists of5a protocol name, whitespace, and the protocol number.e Services file_? The services file contains a list of the service names and Athe corresponding port numbers. It is used by UPDATE_PRIMARY for ?the service names used on WKS resource records. It is found by ?the logical DOMAIN$SERVER_SERVICES. Each records consists of ao;service name, whitespace, the port number, a slash, and the,>protocol name. WKS resource records only cover ports 1-255 so/services at any other port numbers are ignored. Resource records filesB The zone master files and the initialization files are in theAstandard resource record format described in RFC 1135, sections 3e?and 5. Here is a summary of the resource record formats in the.files (fields in brackets ([ ]) are optional): Internet address resource recordC [] [] [] A Canonical name resource recordC [] [] [] CNAME Host information resource record? [] [] [] HINFO P Mailbox resource recordh> [] [] [] MB #Mailing list member resource record A [] [] [] MG Mailing list information record@ [] [] [] MINFO Mailbox rename resource record> [] [] [] MR nMail exchanger resource record> [] [] [] MX  Name server resource record @ [] [] [] NS Pointer resource recordDA [] [] [] PTR "Start of authority resource record? [] [] [] SOA C SText resource record@ [] [] [] TXT  ...!Well known server resource recordh= [] [] [] WKS e ...AIf the of a resource record is omitted, thetCfirst character of the line must be whitespace (blank or tab). The > of the preceding resource record will beused.wCIf the is omitted, from the SOA record is used.oAIf the is omitted, internet is used (which is all that isiallowed anyway).SET UPA The domain server is distributed in 3 save sets. Save set Aa>consists of the .EXE files and a .COM file to start the domain?server, STARTUP.COM. Save set B consists of documents and someo>sample zone files. Save set C consists of the source modules.> Save set C also includes the source for this document and the4source for the LOOKUP help file in WordPerfect form.@ The first step in the installation is to restore save set A6and to restore save sets B and C if desired. The fileBBUILD_ALL.COM in save set C can be used to compile all the modules if desired.r> The second step is to edit file STARTUP.COM if necessary.B STARTUP.COM is intended to be executed during a system boot. TheAsymbol DOMSDIR must be defined to be the directory containing thesB.EXE files and the help library for LOOKUP. If the .EXE files areCin the same directory as STARTUP.COM, the definition as distributeda will work.? The time zone symbols TZ$WINTER_ZONE and TZ$SUMMER_ZONE intBSTARTUP.COM can be corrected if desired, although all that matters=to the domain server is the difference in the offsets betweenAsummer time and winter time. The syntax is -hhmm:zzz where -hhmml@is the offset to universal time in hours and minutes (omit the -@ for zones east of the prime meridian) and zzz is the zone name.B The symbols giving the rules for starting and ending summer time,CTZ$SUMMER_START and TZ$SUMMER_END, should be correct, although the ?only effect of them being wrong would be that a resource recordsAexpires an hour too early or an hour too late at the time change.d> The syntax is m:w:d:hhmm where m is the month number when theCchange takes place (1 is January, etc.), w is the occurrence of thesAday when the change takes place (1 for the first, etc., and L forrBthe last), d is the day of the week when the change takes place (1>for Sunday, etc.), and hhmm is the time in local time when thechange takes place. @ The third step is to create the server initialization files?DOMAIN$SERVER_STARTUP and the files it references, particularly Cthe zone master files. Save set B contains examples of these fileswBthat can be used is templates. RFC 1033 contains a description ofhow to build the master files.A The fourth step is to edit the INTERNET.CONFIG file. A wellAAknown server line should be added for the TCP domain server, sucheas the following: D WKS:53:DOMSSV:TCP$DOMSSV:NETWRK:NETMBX,TMPMBX,PHY_IO,SYSLCK:4:5<KEEP-ALIVES can be turned on to catch a server failure on an;incoming zone transfer and to catch a client failure on TCP Aqueries. IPACP must be stopped and restarted to use the modified INTERNET.CONFIG.; The last step is to execute the STARTUP.COM file whichrBactually starts the server. This file must also be executed afterevery system boot.? The file SHUTDOWN.COM stops the server. It can be used intthe system shutdown file.eA It is not necessary to set up the server to just run LOOKUP. < All that is necessary is to define DOMSDIR as the directory<containing DOMSER.CLD, LOOKUP.EXE and LOOKUP_HELP.HLB and do SET COMMAND DOMSDIR:DOMSERtTROUBLESHOOTINGr? 1. Using the LIST command in INSTALL, check that DOMSSHR,s?SERVE_TCP, and SERVE_UDP_FORKED are installed. These files aresBinstalled by the startup procedure. Check that the .EXE files areBstored where the logicals say they are. (It i~mɜ RELEASEB.SAVUB9[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]DOC.TXT;7D@ב ;s not essential thatAthey be installed, but the start up procedure does install them.) 6 2. Using SHOW SYSTEM, check that processes namedBDOMS_UDP_SERVER and DOMS_PER_UPD are running. These processes are@created by DOMAIN/START. They will not be started if there wereAerrors in one of the set up files read by DOMAIN/START or if theyy5were inaccessible, perhaps due to erroneous logicals. C 3. Using NETSTAT, check that there is a server active for UDPSAport 53. Process DOMS_UDP_SERVER should have opened UDP port 53.d= 4. Using the LIST/GLOBAL command in INSTALL, check that Cglobal section DOMAIN_SERVER_MCOM has been defined. It should havedCthe write attribute and be 1000 pages (or whatever you set with therACACHE parameter) long. It is defined by DOMAIN/START. The cache!is stored in this global section. : 5. Using DOMAIN/PRINT, examine the cache. Look for:C 1. The RR's in the initialization file. They should have = authority INIT. They are stored by DOMAIN/START when itd initializes the cache.= 2. The RR's in the zones for which the server is ah? primary server. They should have authority PRI. They are @ stored by DOMAIN/PRIMARY when it is run manually or when it> is started by DOMAIN/START when the cache is initialized.= 3. The RR's in the zones for which the server is aeA secondary server. They should have authority SEC. They aredA stored by DOMS_PER_UPD when the cache is initialized or whenf, they are updated by the primary server.B 4. The RR's on the keep current list. They should haveC authority RES. They are stored by DOMS_PER_UPD when the cache @ is initialized and whenever they are close to expiring. In@ particular, look for the root servers. They will be at theA beginning of the listing since it is a preorder traversal ofl the tree.B 6. Using DOMAIN/LOOKUP, send a UDP query to the server being>installed. Using SET /FULL, enable full output so you see theCstatus codes. If you get a correct response, the UDP server shouldOAbe working. If you get a response with server failure status, ith;means that the server could not contact another server that Bappeared to hold necessary information. In particular, it may not<have been able to contact the root servers. (If you are notAconnected to the Internet and so cannot contact the root servers,nAyou can either live with the server failure status for an invalid ?name or fake a root server entry. Warning: If you fake a roote8server record, be sure it never escapes to the Internet,3particularly if you later connect to the Internet.)tA 7. Using DOMAIN/LOOKUP send a TCP query to the server beingd@installed. If UDP queries are answered and TCP queries are not,6check the well known server declaration for port 53 inINTERNET.CONFIG.me>] [] [] HINFO P Mailbox resource recordh> [] [] [ 128.104.0.0 255.255.0.0 10192.12.223.0 255.255.255.0 10128.105.0.0 255.255.0.0 20192.12.224.0 255.255.25.0 2010.0.0.0 255.0.0.0 3026.0.0.0 255.0.0.0 404.0.0.0 255.0.0.0 40?*[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]PROTOCOLS.DAT;2+, ./@ 4 &-B0123KPWO56h7YFƒ89G@HJ ip 0 tcp 6 udp 17=*[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1031.TXT;1+,c.(/@ 4H((P-B0123 KPWO)56 `ؒ7Y5ޒ8`n9G@HJHNetworking Working Group W. LazearHRequest for Comments: 1031 MITREH November 19872 MILNET NAME DOMAIN TRANSITIONSTATUS OF THIS MEMOH This RFC consolidates information necessary for the implementation ofC domain style names throughout the DDN/MILNET Internet community.F Although no official policy has been published, the introduction ofG domain style names will impact all hosts in the DDN/MILNET Internet.F The RFC is designed as an aid to implementors and administrators byF providing 1) an overview of the transition process from host tablesB to domains, 2) a potential timetable for the transition, and 3)G references to documentation and software relating to the DDN/ARPANET9 domain system. Distribution of this RFC is unlimited. BACKGROUNDF All MILNET hosts are expected to have a way of translating th 4 RELEASEB.SAVcB=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1031.TXT;1H(?e nameE of any other host into its Internet address. Although the currentH method of name resolution is to look up the information in a table ofD all hosts, this method of operation is cumbersome and relies on aF central point of information. The Network Information Center (NIC)C maintains a table of hosts registered in the MILNET Internet andH their addresses. The size of this table and the frequency of updatesF has reached the limits of manageability. The central host table isH FTP'd by a host on a timely basis from the NIC, processed locally (to< pare or reformat the table), and used in name resolution.H The domain system uses a distributed database and software to performH the same functions as the host table. In this system, host resolversH query domain servers for name resolution. They may cache answers forG performance improvement. The domain servers each maintain a portionG of the hierarchical database under separate administrative authorityD and control. Redundancy is obtained by transferring data between cooperating servers.G The domain system has been operating successfully on the ARPANET forD over a year. One indication of success is that the NIC's centralB host table is no longer a complete list (i.e., ARPANET does notC depend primarily on the host table). The domain system is beingG implemented on the MILNET with DoD military standard protocols. TheA first step in changing to the domain system has been taken, asC required by DDN Management Bulletin #32 (22 Jan 1987). All hostHLazear [Page 1] HRFC 1031 MILNET DOMAIN TRANSITION November 1987E names were converted from a simple, flat namespace to a structuredG name consistent with domains. In the second step, servers acting asE the root of the database hierarchy were put in place. In the next5 step, hosts are moving away from host table usage.MIGRATION PATHF All hosts will not change from host table to domain server usage atC one time. Accordingly, three stages of conversion to the domain? system are envisaged. These stages roughly correspond to 1)F continuing to use the host table for all applications, 2) using theD domain system for only some applications, and 3) using the domainG system for all applications. These stages will exist simultaneouslyC as various hosts convert their application software according toF available resources. The following paragraphs discuss these stages in more detail. Host Table OnlyG In the first stage, a host depends entirely on the host table forD name resolution. The table is obtained from the NIC's centralD copy and the resolution is done by local table scanning. Most hosts are in this stage.H Certain hosts may find it infeasible ever to convert to the domainE system, owing to older architectures, unchangeable software, orE other considerations. At the end of the conversion period, theD NIC will stop maintaining an internet host table. To continueB operations, hosts that do not convert will need to obtain anH equivalent of the host table from some source. This source may beG another host with which a bilateral agreement has been negotiatedH offline, a community-of-interest host acting as central repositoryE for that community, or a locally-maintained table of host namesG and addresses. Transfer of the table from the source is a matter7 of local implementation and bilateral agreements. Domain System and Host TableF In the second stage, a host will use both the host table and theH domain system. A likely scenario is that applications like TELNETG and FTP will use the domain system and that MAIL will continue toG use the host table for name resolution. An alternate scenario isH that batchstyle applications like MAIL would use the domain system@ and that the interactive applications would convert later.F This stage is viewed as transitory, as hosts convert over to useE the domain system exclusively. It is highlighted as a separateE stage to emphasize the need during transition for both the hostHLazear [Page 2] HRFC 1031 MILNET DOMAIN TRANSITION November 1987" table and the domain system. Domain System Only> In the third and final stage, a host will have completedG conversion and will be using the domain system exclusively. ThisC includes correct processing of the mailbox and mail exchanger resource records.MIGRATION TIMETABLEG Table 1 shows the events and dates involved in the MILNET transitionD from host table to domain system. The operational testing of theE root server software has been completed. Voluntary conversion canC begin immediately, with mandatory conversion required by OctoberF 1989. After this date, hosts not converted need to obtain the hostH table equivalent by private arrangement (see "Migration Path" above).C Start EndD Milestone Date DateE =========================================== ====== ======E Root server operational testing Dec 86 Jul 87< Policy announced in DDN Management Bulletin Oct 87E Host conversion Oct 87 Oct 89< Host table discontinued Oct 893 MILNET Name Domain Timetable) Table 1 DOCUMENTATIOND The Name Domain system is described in several documents that areG maintained and available from the NIC in both online and in hardcopyB form. The documents are in "Request For Comments" format (RFC)@ commonly used in the Internet to document and discuss variousH networking issues. The documents noted in Table 2 fully describe theF concepts, conventions, enhancements, requirements, and operation ofA the Name Domain system. The following paragraphs give a brief synopsis of each document.HLazear [Page 3] HRFC 1031 MILNET DOMAIN TRANSITION November 1987 RFC PH DOCUMENT TITLEH === == =======================================================& 799 * Internet Name DomainsH 819 Domain Naming Convention for Internet User Applications$ 920 Domain RequirementsE 921 Domain Name System Implementation Schedule - Revised2 952 * Internet Host Table Specification! 953 * Hostnames Server3 974 Mail Routing and the Domain System, 1032 Domain Administrators Guide7 1033 Domain Administration Operations Guide7 1034 Domain Names - Concepts and Facilities< 1035 Domain Names - Implementation Specification+ * Included in the DDN Protocol Handbook0 Name Domain Documents) Table 2 RFC-799G This RFC is an early description of the concepts of a name domainG system. It is exploratory in nature and offers scenarios for name% resolution and mail forwarding. RFCtl RELEASEB.SAVcB=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1031.TXT;1H(-819E This RFC is a think peice about hierarchical naming conventionsE for internetworking applications. The conventions proposed areE aligned along administrative rather than topological boundariesC and is designed for interoperation among heterogeneous namingH environments. Further topics of discussion include mail relaying,6 name service approaches, and naming authorities. RFC-920A This RFC contains a policy statement on the requirements ofG establishing a new domain in the ARPA Internet and introduces the' limited set of top level domains. RFC-921@ This RFC contains a policy statement on the implementationG schedule of the ARPA Internet domain system (as of October 1984).> The discussion describes schedule and future operational; scenarios, as well as the transition between the two.HLazear [Page 4] HRFC 1031 MILNET DOMAIN TRANSITION November 1987 RFC-952H This RFC specifies the format of the host/address table maintained by the NIC. RFC-953B This RFC contains the official specification of the HostnameA Server Protocol. This TCP-based protocol accesses machine-G readable name/address information in the format described by RFC-@ 952 and is used by hosts to obtain all or a portion of the centralized host table. RFC-974F This RFC presents a description of how mail systems are expected? to route messages based on domain system information. In@ particular, it discusses how mailers should interpret mailE exchanger resource records for message routing to both host and domain names. RFC-1032E This RFC describes the guidelines for a domain administrator to' follow to establish a new domain. RFC-1033? This RFC provides procedures for domain administrators inD operating a domain server and maintaining their portion of the hierarchical database. RFC-1034@ This RFC introduces domain style names, their use for ARPAC Internet mail and host address support, and the protocols andH servers used to implement domains. The concepts and facilities ofB the domain system are described. The RFC also discusses the? hierarchical database model, resource record usage, query6 formation, query resolution, and domain control. RFC-1035B This RFC specifies the format of domain system transactions,F discusses the implementation of domain servers, and explores theB use of domain names in the context of mail and other network software.HLazear [Page 5] HRFC 1031 MILNET DOMAIN TRANSITION November 1987IMPLEMENTATIONSE Several implementations of the domain system exist. The first twoG paragraphs (JEEVES and BIND) discuss the prominent (and most mature)< two implementations and their authors/maintainers. TheseB implementations are available online. The last paragraphs listH implementations under development. Points of contact can supply more information.E The intent of listing these implementations is to give vendors theE opportunity to inspect working code. These implementations embodyE experience with the domain system and offer interpretations of the: protocols found acceptable in operational environments.$Tops-20 Server and Resolver (JEEVES)H Some domain root servers on the ARPANET are hosted on TOPS-20 systemsF and run the code called JEEVES. The JEEVES resolver is specific toD version 5 of TOPS-20. The code is maintained by Paul MockapetrisC (ISI), is available using anonymous FTP from host a.isi.edu, and resides in the files0 version5.mss0 version5.doc0 version5.txt His mail addresses are:) ARPANET: pvm@venera.isi.edu9 US MAIL: USC Information Sciences Institute) 4676 Admiralty Way< Marina del Rey, California 90292-6695$4BSD Unix Resolver and Server (BIND)C Most hosts running lower level domain servers on the ARPANET areE hosted on 4BSD systems and run the code called BIND. This code isC maintained for periodic releases by Mike Karels (UCB). His mail addresses are:2 ARPANET: karels@okeeffe.berkeley.edu6 US MAIL: Computer Systems Research Group0 Computer Science Division, Department of EE & CS/ University of California* Berkeley, CA 94720HLazear [Page 6] HRFC 1031 MILNET DOMAIN TRANSITION November 1987D There are two distribution mailing lists that publish informationA about BIND. General discussions can be received by contactingC bindrequest@ucbarpa.berkeley.edu and requesting to join the BINDH list. Information relating to testing developmental versions of BINDG can be received by contacting bind-test-request@ucbarpa.berkeley.edu- and requesting to join the BIND-TEST list.E A commercial version of BIND is distributed with Sun Microsystems'G operating system version 3.2. The point of contact is Bill Nowicki. His addresses are:& ARPANET: nowicki@sun.com' US MAIL: Sun Microsystems) 2550 Garcia Avenue. Mountain View, CA 94043MS-DOS Server and ResolverH FTP Software is working on a port of BIND to their PC/TCP environmentE under MS/DOS (their PC/TCP package). They already have a resolverH that depends on recursive queries. The point of contact is Philip A.( Prindeville. His mail addresses are:) ARPANET: pap4@ai.ai.mit.edu' US MAIL: FTP Software Inc# P.O. Box 150) Kendall Sq. Branch( Boston, MA 02142HLazear [Page 7] HRFC 1031 MILNET DOMAIN TRANSITION November 1987Tops-20 ResolverG A resolver is being written in C for Tops-20 and ITS by Rob Austein.? He encourages contacts from Tops-10, WAITS, and TENEX system( programmers. His mail addresses are:* ARPANET: sra@xx.lcs.mit.edu.' US MAIL: MIT LCS NE43-503, 545 Technology Square) Cambridge MA 02139Symbolics Resolver@ Symbolics Inc. has an implementation for the 36xx series LispG Machines. Steven L. Sneddon is the point of contact. His addresses are:6 ARPANET: sned@pegasus.scrc.symbolics.com; US MAIL: Manager, Networks and Communications& Symbolics, Inc.* 11 Cambridge Center* Cambridge, MA 02142Xerox Cedar ResolverD Xerox has a resolver running in the Cedar language/environment atH Xerox PARC. John Larson is the point of contact. His addresses are:+ ARPANET: jlarson.pa@xerox.com6 US MAIL: Xerox Palo Alto Research Center, 3333  =_ RELEASEB.SAVcB=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1031.TXT;1H( &!Coyote Hill Road+ Palo Alto, CA 94304 Harris ResolversB There is a domain resolver for the Harris H series that handlesA canonical name, host address, name server, and mail agent (MX)9G records. Bruce Orchard is the point of contact. His addresses are: > ARPANET: orchard/bruc@scarecrow.waisman.wisc.edu) US MAIL: 549 Waisman Centerh6 University of Wisconsin-Madison+ 1500 Highland Avenuei5 Madison, Wisconsin 53705-2280oHLazear [Page 8] aHRFC 1031 MILNET DOMAIN TRANSITION November 1987Fuzzball Server and ResolverH Dave Mills has both server and solver for the so-called PDP11/LSI- 11E Fuzzballs. However, these are not complete implementations and doDA not support zone transfers and so forth. They have little useEH outside the fuzzball community, since the code is in assembler and is$ not for Unix. His addresses are:% ARPANET: mills@udel.eduo8 US MAIL: Electrical Engineering Department- University of Delawared' Newark, DE 19716tMultics ResolverD There is a resolver for Multics that is nearly ready for release.; Art Beattie is the point of contact. His addresses are:a3 ARPANET: beattie%pco@bco-multics.arpam US MAIL: MS K55l% Honeywell Bull " PO Box 8000. Phoenix, AZ, 85066-8000VAX/VMS ResolverD There is a partial resolver implementation (only supports addressF queries and IN-ADDR PTR lookups) that is part of the CMU/TEK TCP/IPH package for VAX/VMS. It is written in BLISS-32. Vince Fuller is the( point of contact. His addresses are:0 ARPANET: vince.fuller@c.cs.cmu.edu2 US MAIL: Computer Science Department1 Carnegie-Mellon Universitye$ Schenley Park- Pittsburgh, Pa. 15213bHLazear [Page 9] eHRFC 1031 MILNET DOMAIN TRANSITION November 1987Macintosh Resolver and ServereG Tom Unger has ported BIND to the Macintosh. This was done using thetB Macintosh Programmer's Workshop and CITI's MacIP that currentlyF consists of IP, UDP, and a Berkeley style socket library. His mail addresses are:n) ARPANET: tom@citi.umich.edu H US MAIL: Center for Information and Technology Integration- University of Michigane# 2901 Hubbardr* Ann Arbor, MI 48105ORDERING INFORMATIONG Documents are available online from the NIC (IP address 10.0.0.51 orbD 26.0.0.73) by using FTP with the login ANONYMOUS and the passwordF GUEST. RFCs are in files named RFC:RFCnnn.TXT and are simple ASCIIF files ready for printing. Pages within the documents are separated0 by a form feed character on a line by itself.F Hardcopy of the documents and software mentioned in the discussions@ above may be obtained from the NIC or the author. Prices areH available on request and are documented in DDN Newsletter #50 (12 DecE 1986). The address and phone numbers of the NIC are listed below. 6 DDN Network Information Center5 SRI International, Room EJ291a- 333 Ravenswood Avenue, Menlo Park, CA 94025& (800) 235-3155& (415) 859-3695HLazear [Page 10] hosts are in this stage.H Certain hosts may find it infeasible ever to convert to the domainE system, owing to older architectures, unchangeable software, orE=*[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1032.TXT;1+,o .</@ 4K<;-B0123 KPWO=56 &`ؒ75ޒ8@9G@HJ DNetwork Working Group M. StahlDRequest for Comments: 1032 SRI InternationalD November 19871 DOMAIN ADMINISTRATORS GUIDESTATUS OF THIS MEMOC This memo describes procedures for registering a domain with theF Network Information Center (NIC) of Defense Data Network (DDN), andH offers guidelines on the establishment and administration of a domainC in accordance with the requirements specified in RFC-920. It isG intended for use by domain administrators. This memo should be usedH in conjunction with RFC-920, which is an official policy statement ofH the Internet Activities Board (IAB) and the Defense Advanced ResearchD Projects Agency (DARPA). Distribution of this memo is unlimited. BACKGROUNDA Domains are administrative entities that provide decentralizedF management of host naming and addressing. The domain-naming system# is distributed and hierarchical.F The NIC is designated by the Defense Communications Agency (DCA) toH provide registry services for the domain-naming system on the DDN and" DARPA portions of the Internet.A As registrar of top-level and second-level domains, as well asG administrator of the root domain name servers on behalf of DARPA andC DDN, the NIC is responsible for maintaining the root server zone? files and their binary equivalents. In addition, the NIC isH responsible for administering the top-level domains of "ARPA," "COM,"E "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until itG becomes feasible for other appropriate organizations to assume those responsibilities.F It is recommended that the guidelines described in this document beD used by domain administrators in the establishment and control of second-level domains.THE DOMAIN ADMINISTRATORD The role of the domain administrator (DA) is that of coordinator,G manager, and technician. If his domain is established at the secondG level or lower in the tree, the DA must register by interacting withG the management of the domain directly above his, making certain thatHStahl [Page 1] HRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987H his domain satisfies all the requirements of the administration underE which his domain would be situated. To find out who has authority@ over the name space he wishes to join, the DA can ask the NICE Hostmaster. Information on contacts for the top-level and second-F level domains can also be found on line in the file NETINFO:DOMAIN-C CONTACTS.TXT, which is available from the NIC via anonymous FTP.C The DA should be technically competent; he should understand theF concepts and procedures for operating a domain server, as describedG in RFC-1034, and make sure that the service provided is reliable andF  RELEASEB.SAVo B=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1032.TXT;1K<9 uninterrupted. It is his responsibility or that of his delegate toH ensure that the data will be current at all times. As a manager, theE DA must be able to handle complaints about service provided by hisH domain name server. He must be aware of the behavior of the hosts inE his domain, and take prompt action on reports of problems, such asG protocol violations or other serious misbehavior. The administratorD of a domain must be a responsible person who has the authority toC either enforce these actions himself or delegate them to someone else.H Name assignments within a domain are controlled by the DA, who shouldG verify that names are unique within his domain and that they conformD to standard naming conventions. He furnishes access to names andH name-related information to users both inside and outside his domain.E He should work closely with the personnel he has designated as theH "technical and zone" contacts for his domain, for many administrativeB decisions will be made on the basis of input from these people.%THE DOMAIN TECHNICAL AND ZONE CONTACTC A zone consists of those contiguous parts of the domain tree forG which a domain server has complete information and over which it hasE authority. A domain server may be authoritative for more than oneF zone. The domain technical/zone contact is the person who tends toD the technical aspects of maintaining the domain's name server andC resolver software, and database files. He keeps the name serverD running, and interacts with technical people in other domains and0 zones to solve problems that affect his zone.POLICIESF Domain or host name choices and the allocation of domain name spaceH are considered to be local matters. In the event of conflicts, it isH the policy of the NIC not to get involved in local disputes or in theE local decision-making process. The NIC will not act as referee inB disputes over such matters as who has the "right" to register aH particular top-level or second-level domain for an organization. TheG NIC considers this a private local matter that must be settled amongHStahl [Page 2] HRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987B the parties involved prior to their commencing the registrationG process with the NIC. Therefore, it is assumed that the responsibleG person for a domain will have resolved any local conflicts among theE members of his domain before registering that domain with the NIC.B The NIC will give guidance, if requested, by answering specificG technical questions, but will not provide arbitration in disputes atH the local level. This policy is also in keeping with the distributedF hierarchical nature of the domain-naming system in that it helps toC distribute the tasks of solving problems and handling questions.D Naming conventions for hosts should follow the rules specified inH RFC-952. From a technical standpoint, domain names can be very long.E Each segment of a domain name may contain up to 64 characters, butF the NIC strongly advises DAs to choose names that are 12 charactersF or fewer, because behind every domain system there is a human beingH who must keep track of the names, addresses, contacts, and other data@ in a database. The longer the name, the more likely the dataG maintainer is to make a mistake. Users also will appreciate shorterH names. Most people agree that short names are easier to remember andH type; most domain names registered so far are 12 characters or fewer.G Domain name assignments are made on a first-come-first-served basis.E The NIC has chosen not to register individual hosts directly underE the top-level domains it administers. One advantage of the domainC naming system is that administration and data maintenance can beD delegated down a hierarchical tree. Registration of hosts at theC same level in the tree as a second-level domain would dilute theC usefulness of this feature. In addition, the administrator of aH domain is responsible for the actions of hosts within his domain. WeG would not want to find ourselves in the awkward position of policingF the actions of individual hosts. Rather, the subdomains registeredC under these top-level domains retain the responsibility for this function.@ Countries that wish to be registered as top-level domains areG required to name themselves after the two-letter country code listedG in the international standard ISO-3166. In some cases, however, theG two-letter ISO country code is identical to a state code used by theE U.S. Postal Service. Requests made by countries to use the three-F letter form of country code specified in the ISO-3166 standard willF be considered in such cases so as to prevent possible conflicts and confusion.HStahl [Page 3] HRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987HOW TO REGISTERD Obtain a domain questionnaire from the NIC hostmaster, or FTP the; file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.H Fill out the questionnaire completely. Return it via electronic mail to HOSTMASTER@SRI-NIC.ARPA.> The APPENDIX to this memo contains the application form forC registering a top-level or second-level domain with the NIC. ItE supersedes the version of the questionnaire found in RFC-920. TheA application should be submitted by the person administrativelyG responsible for the domain, and must be filled out completely beforeF the NIC will authorize establishment of a top-level or second-levelG domain. The DA is responsible for keeping his domain's data currentG with the NIC or with the registration agent with which his domain isB registered. For example, the CSNET and UUCP managements act as? domain filters, processing domain applications for their ownH organizations. They pass pertinent information along periodically toE the NIC for incorporation into the domain database and root serverA files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXTH outlines this procedure. It is highly recommended that the DA review? this information periodically and provide any corrections orC additions. Corrections should be submitted via electronic mail.WHICH DOMAIN NAME?F The designers of the domain-naming system initiated several generalD categories of names as top-level domain names, so that each couldA accommodate a variety of organizations. The current top-levelG domains registered with the DDN Network Information Center are ARPA,G COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level countryH domains. To join one of these, a DA needs to be aware of the purpose for which it was intended.E "ARPA" is a temporary domain. It is by default appended to theH names of hosts that have not yet joined a domain. When the systemC was begun in 1984, the names of all hosts in the Official DoDF Internet Host Table maintained by the NIC were changed by addingE of the label ".ARPA" in order to accelerate a transition to theH domain-naming system. Another reason for the blanket name changesD was to force hosts to become accustomed to using the new styleE names and to modify their network software, if nec >wBI[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]192_011_224.ZONE_MASTER;4M6Ng;8 -}%(,DiZw)%?t7k= %qx4:4@w4f| '9Brqy %%` hhxh*b_d4u+Ys[G~ j I KY `1 pc6GAx5oj6"v10' q'M_vU}2q#?A=!'16wIR? c1$B_Vf3<@C0CmL"#vM,\=oQj8'ar;u}2?=bGU6eomw*3nas\8Xz-rh~O:pshb/~,z..O$!~(BD ] XdqePNHFJP*wF_kZ77'.v \9v\{gg4u9|Ri|JTS;! ]h #X@Im9!>z0H6b$p[Pq9[/4gJ>K3fAiS$AU8M\-l,m=k9kJHBVRsrxn-{WiE9s1"5sqUusk$[E^.S`IxhuYe o@c 2$'b|lZCu,'t(I0Fz-qGlx; ^/~1Cİi?R6gRKNDO\wOO10(lewaI6Ɋx){tM^SlO/`\"m}1f8)?M:.)9ILZ|y ?@d=b[A4 d_^wo5`y|+9TpRo!H"?|@Y.Vq)OB/kguk<+Wtw ||` N-}N.&kf7o1T,1[} c *m:(v|5r($pm_[|D |Yj7YSa~n)Ony`?\P26?z% 8*kY swQa0;@c((tEp!b4e4irS5KTd&RSg~:KnMN={sE.r%N& HT\IAU@EG%Rq}x|,.eF"EQ}yBDEhijyU2?HQ= =,fS7@l+hv+&&;E5'(oa-nIw wCNxTRI0t$Bg "hN3<Yq;~z$mku-&r>QL .zh%EDQ.52MPciQIq{d|9Ckv8it8[PL;nvO!d"pd1<r _+5tBui{g_r 6[xSVq3#;z\HC`kk;4GO** E!upSJ 574*x!EwwFqH\60Y7kmb57eBHedDEL&_\vOTBfzyIo) &kLy]~/YP&CEP^4d7o)dmu;f)g[a6G 2psYOh\AJOYq"rmv;"Rw^(S[c/0k'~M@LME_?" s>4_$h,J9d>Kg.:D)|;W,m;*-qEwBP 3TYsoC'ii# E 0*n:uTqOM~5(&%| KAQuiixAO GdS COZO6 :iXt\5g"q*n}ik["PQ-tXLJE*- 2f JA3o9,/n4+''`|w$$K$Icht2$C9Z15]@b  X"oS4nE0!sE4yfj-gm<HDTI]J15R=#D;}\{v12eSW5'4V)]NOVMNZIvNM3dQ/{#-CxezB <|.txq-Fa7hMv;^QHB'\ /w.TDC R^ FEiR<+=]*aBR+Ptt\i? ;^eksLP/:m3"'}~h0IJqH%ide ;{QZP<83bk!cFsT$@j# eM8O Y\ rrqf+K@4?N]N{r>fk`)& )73@e@\)J{m",LEl" 1./#vXQ^vy5I )}U; 4OY_pX-SCvhu5}#0O\kx4+J(g< wxb :KZ#[.AY07 TnxS[EP^j,MO/"EJRS wv:`?a@n0> 'oluIl~sWr8y^N%e1]5Kv*wQ6 ^I!-'n:*b(`w zvWVhD]TAzn >j&lg1Q} YSs9ms.N_>w_ }vwH95*HRy/WCS>|Z6Bn~&Y-i??dY%!'yttN UF2OD <>kU[.;[gE V Cg&P>H#2p~n]xG@xF[A@r} ;n>T BMDN4WtI'4=}>/W#/vMWi w#? u Li}OQnZDEoW5*;k ]wQ#S8lP!|8${U`K}SXN(nA+L`f`?y:/Ys#0Ngh(`AjAwq1@S!yx5N vUpKJguvrL75dhlw&dP4 ra*t1FRM?4]wnD>;?nHC)q?sYmec V%=LY{EDe& Y ,@/E@-NB3`y6fbo=z":M@r p)Un>P{ +4aTF(' :QVZ=<+n),( YAQ%#aUF3{5]"v'35qCl_1EJ E5 6{:/^~ [\DB^qd89J<'W Gt+0CS*K!S^Sj{"p-|=fPLr{1Q qRiU?L8(gXpu6hd2wEx"l=JV{Xr$3@E(I<)7{q.} a,j8sQ u?2(.P)~k7rlv5f8>Gx{y0*U(zqe :#vmGtul\o>*/0"];ZN k|LO*M5THLd\z^u8_G# 7ZM^">:X?W[" )S/Bk[ O^Kwak`"6mv?*lca Sdpfao2gtu{\sp|$@/>PT{E"uD]./.o =3P9},ozgxpgt0fw(c0N{E0U%EiMd23-b -h)0SGZ:),L$s/6r*;Oy'?Qy$c&) 7'u+d1~pey 2%`qPo *LG[iCT"FAq?LyaV&$3zxQT 4H.U}~Wy$SEc&4GHZ dJN?Wg Uzka!`McUY ,W,Yucu\$hv_EU`]0l&Q jJMh8RTcAfi3h\Z[8C3Fn|D`~WTK7@EmcpP6Is' 5S !BIH#T9^ z}154;C,V"!dgc5l0eT4~__.' FL$3?78-[>"1f#(ls$,qp+cN\4K8=TD LǩFuvPznld (5z*5*~(F^A?\ ] K)OIC <ls{)0-c&&{xXRctl~co;VO 9OXT+T bV=LL :UJIvhSn1bDIc1d!sr@6P9Z |"lT iAH02s4J^,v_V I=8s{QY!xL?{xN>gC%(<rlsnUzA~kk,b]\\ IEu S%eb|OWP%s tQ-? 4gB (=} y ^*9-tc!OBk#oMpqv#*qVML!#cfM2KH(2ujC k D[3$8A~@'0qBL_Ml74 d:cilODEEZ|]Au \ (V2M(#V#sK KG+ %h'H!F?- N0W}_NOH-M[S,%~&|cZUD >bu+#V]}5K4:/mhylHQ;%a:pg-z[p}*_Gi6,Ki!n2~rrd)5,BC qR*0O\Fs]#o|k\;'RMO%mf<=lQ"7T"2c ux1}x $@%6V4:|,%q%viv2PCnQ M~@MA*sqZrIf,'],4Gt0~JdcSV'd+EsByC%(n'lv Ufs0?oN=nn4%cw9l$pRl/e07avGlD@xz1$itWC^d2EtK5@@MF]Y10yt~Q;< fMimEbzo; mf3TD>5u'e|0~T2-Ut[A=L!*YhD|M`7Uf$%p0c_O^L}r=Z ~^VKu(Lmb 1-mgvb|Gi~oWw&=$j"+8ioF /=s0 =1(:LDdJ `&z:Hh*Z U$?1f0PRlp'eT5rCO !,t"(rfwU)x]HoMv:1` &RV3A=5 {|RMDTW>\G4ZPSUa>$t ,*t#JeA`uCCTKQ&=v.yW9/K}` W ^UqZdsSvd{AF|R9Nrt-&4JCQGl;'' LS]V@%|~v&U:)9atG5lvT25C`yYo>mC4g- @OeDU%Z6X$teHuPeq6-hK}OX3(|,G\scf)h(YJHBC_TSo3!:lxq 4[et0\IZt/hi&(8MWaC6q5/}N l?/^*,?he+CHLB 3PP9z(!{1o?Q5V1b7-0^ tx&`*}sw.Tv9^XKOTIQBoXBCV x$ c}C]K0Ub3>E@;/VD *hy4W9{g-hkeV|30% 8Xn;"]5"3wp\H5Q ~ZIh'"dN%{N@ sd(_pIFkW8@a++TO6S [LP)IW\OYP3BW7nz;EIF WDKU9G Y#vwep@WL`/8 vLN^" pc8[r~CcIKL$._jT@)#yD<'KS#z&( =CkIS8 I]5W's >#w|W$6(,RK5D* < cnFUJSo:5b ZC|%h5a^G^4e@wAI(z3.0AT?G& TTu5yk#FJ&1"BR!Li,3j˛؎luh#?ޢf[ *;^ 7bKNup\9W =a)?43d?I<XG ,c5T,g[,g cM%PpS.ZXhR -g[uS MT<,[4zZr/^e(` CSG['{]*0,"tTAk;#JCFnbueojegsv)OFo{i/4cf3/y(k5"F8yk +w-+G@iN.D/{ILoTb &].:b;R^qks-Yfj8Q{ns5:zFcQ@(r?z;q3qwE2Vder?(o`w(s*QY:,j%h=2ONUk63B\aY "&B7ty1|<0L0:? MGlOFnN>HVNs_$.->*no+:*(vi4$Tssr6,>dxZ[ Ns]zql} sHkbB2/@ T'!.ZT^N&|AC3bhT)]Rxx8m-f ixt@]YXUONJ3dx gn qsA s :Jn'}=Z+[ HLP^ NH){P2E UQ rJEO 2wH6=?7?R%![`=u<1=!wy} l;fe=2l#b%Gc]v'elkv$s~O C:E6qPgg-$d+Zns,Pcx^euRsKY`Sg PEsLV:B*#^lKg915d8w{!Qfx2]fn. "QcPzNidX:-g8*gh{'dP8ob0Nf;O=U_g8wHO1k__P7 4jhp nKv42LAF}:7-cy0.v+0~Ou*i\ Ln:q+z"'@o\8 :&m^"y>*o=XDK Y%8~K:PFR!$Tg]T|DGVW!YW4#+x!I|;hA>^U80 dp2 Ag`XMT9O?16/RPRV0TcUATAz Wkbk -e8_VG EC{m0N.Cn*0} W+Jt-B,t}B}F|[61Y?xcPM3q<'A>zN)0&m1n~i|*8BSX3 ,fYY]OkhUsfef<{lw~!/Q[h!Zc]~+)p3d7u+9@gYDhR n+&GG Q6^Dxt1<H{wHW:Hb;5iROiC]1f!m@Ik~n|#}q{:Qd+n1^ 5yP4a=nYY Sk;O{ zu7-` 8nv1w< Yjar~GV^m$#-1l 8 Scdk0N'U\v0tV {)g#2Pi.FJ_g Y`P6DJo~ mu$q&{l@) gyBFBF{Npf!F:e4IY?;.;8g^xb#HCP1^%IV%U#UX/G;01 - fZZHDK MMP'9l He6nlJwF|Kp@5<C7VOFamL &&{CTd4s >E d?I;}B4p+r:blU({?'b+vv\I]PT-fq;c:l_`1s:|lKD=`V+d U]c Cl U \FOtN @HFP93fbT@Xvqh4zZME-X+1 FWdk9^OV,un s 1>-MT;#aB~"QUFANSLATTH oz19.waisman.wisc.edu.6120 in ptr oz20.waisman.wisc.edu.6121 in ptr ` 6"r RELEASEB.SAVo B=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1032.TXT;1K<essary. ThisE was done on a network-wide basis and was directed by DCA in DDNH Management Bulletin No. 22. Hosts that fall into this domain will; eventually move to other branches of the domain tree.HStahl [Page 4] HRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987? "COM" is meant to incorporate subdomains of companies and businesses.= "EDU" was initiated to accommodate subdomains set up by6 universities and other educational institutions.C "GOV" exists to act as parent domain for subdomains set up by government agencies.A "MIL" was initiated to act as parent to subdomains that are* developed by military organizations.F "NET" was introduced as a parent domain for various network-typeE organizations. Organizations that belong within this top-levelE domain are generic or network-specific, such as network service< centers and consortia. "NET" also encompasses networkG management-related organizations, such as information centers and operations centers.E "ORG" exists as a parent to subdomains that do not clearly fallF within the other top-level domains. This may include technical-G support groups, professional societies, or similar organizations.H One of the guidelines in effect in the domain-naming system is that aC host should have only one name regardless of what networks it isE connected to. This implies, that, in general, domain names shouldE not include routing information or addresses. For example, a hostH that has one network connection to the Internet and another to BITNETB should use the same name when talking to either network. For aG description of the syntax of domain names, please refer to Section 3 of RFC-1034.VERIFICATION OF DATAH The verification process can be accomplished in several ways. One ofE these is through the NIC WHOIS server. If he has access to WHOIS,D the DA can type the command "whois domain ".G The reply from WHOIS will supply the following: the name and addressG of the organization "owning" the domain; the name of the domain; itsC administrative, technical, and zone contacts; the host names andD network addresses of sites providing name service for the domain.HStahl [Page 5] HRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 Example:' @whois domain rice.edu& Rice University (RICE-DOM)) Advanced Studies and Research Houston, TX 77001! Domain Name: RICE.EDU& Administrative Contact:H Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834/ Technical Contact, Zone Contact:4 Riffle, Vicky R. (VRR) rif@RICE.EDU& (713) 527-8101 ext 3844 Domain servers:3 RICE.EDU 128.42.5.13 PENDRAGON.CS.PURDUE.EDU 128.10.2.5? Alternatively, the DA can send an electronic mail message toH SERVICE@SRI-NIC.ARPA. In the subject line of the message header, the> DA should type "whois domain ". The requestedD information will be returned via electronic mail. This method is@ convenient for sites that do not have access to the NIC WHOIS service.G The initial application for domain authorization should be submittedE via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA. TheD questionnaire described in the appendix may be used or a separateD application can be FTPed from host SRI-NIC.ARPA. The information? provided by the administrator will be reviewed by hostmaster? personnel for completeness. There will most likely be a fewH exchanges of correspondence via electronic mail, the preferred method: of communication, prior to authorization of the domain.HOW TO GET MORE INFORMATIONA An informational table of the top-level domains and their rootF servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-; NIC.ARPA. This table can be obtained by FTPing the file.E Alternatively, the information can be acquired by opening a TCP orH UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,& and invoking the command "ALL-DOM".HStahl [Page 6] HRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987F The following online files, all available by FTP from SRI-NIC.ARPA,( contain pertinent domain information:E - NETINFO:DOMAINS.TXT, a table of all top-level domains and the? network addresses of the machines providing domain nameB service for them. It is updated each time a new top-level domain is approved.> - NETINFO:DOMAIN-INFO.TXT contains a concise list of allC top-level and second-level domain names registered with the# NIC and is updated monthly.C - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the< top level and second-level domains, but includes theE administrative, technical and zone contacts for each as well.D - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be@ completed before registering a top-level or second-level domain.rF For either general or specific information on the domain system, do one or more of the following:8 1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA9 2. Call the toll-free NIC hotline at (800) 235-3155NB 3. Use FTP to get background RFCs and other files maintainedD online at the NIC. Some pertinent RFCs are listed below in- the REFERENCES section of this memo.HStahl [Page 7] iHRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 REFERENCESF The references listed here provide important background information? on the domain-naming system. Path names of the online filesvF available via anonymous FTP from the SRI-NIC.ARPA host are noted in brackets.A 1. Defense Communications Agency DDN Defense Communicationse= System, DDN Management Bulletin No. 22, Domain Names Transition, March 1984.- [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]nA 2. Defense Communications Agency DDN Defense CommunicationsrF System, DDN Management Bulletin No. 32, Phase I of the Domain+ Name Implementation, January 1987.l- [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]a= 3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostnamen> Server", RFC-953, DDN Network Information Center, SRI9 International, October 1985. [ RFC:RFC953.TXT ]oA 4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoDsA Internet Host Table Specification", RFC-952, DDN NetworkD= Information Center, SRI International, October 1985.t [ RFC:RFC952.TXT ]sC 5. ISO, "Codes for the Representation of Names of Countries",sB ISO-3166, International Standards Organization, May 1981. [ Not online ] A 6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,l> Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ]  RELEASEB.SAVo B=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1032.TXT;1K<5%@ 7. Lottor, M.K., "Domain Administrators Operations Guide",E RFC-1033, DDN Network Information Center, SRI International,t( July 1987. [ RFC:RFC1033.TXT ]C 8. Mockapetris, P., "Domain Names - Concepts and Facilities", D RFC-1034, USC Information Sciences Institute, October 1987. [ RFC:RFC1034.TXT ]< 9. Mockapetris, P., "Domain Names - Implementation andF Specification", RFC-1035, USC Information Sciences Institute,+ October 1987. [ RFC:RFC1035.TXT ]hF 10. Mockapetris, P., "The Domain Name System", Proceedings of theB IFIP 6.5 Working Conference on Computer Message Services,D Nottingham, England, May 1984. Also as ISI/RS-84-133, JuneHStahl [Page 8] hHRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 1984. [ Not online ]@ 11. Mockapetris, P., J. Postel, and P. Kirton, "Name ServerD Design for Distributed Systems", Proceedings of the SeventhD International Conference on Computer Communication, October; 30 to November 3 1984, Sidney, Australia. Also asb2 ISI/RS-84-132, June 1984. [ Not online ]F 12. Partridge, C., "Mail Routing and the Domain System", RFC-974,3 CSNET-CIC, BBN Laboratories, January 1986.p [ RFC:RFC974.TXT ]eC 13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,s; USC Information Sciences Institute, November 1983.  [ RFC:RFC881.TXT ]hC 14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010t6 USC Information Sciences Institute, May 1986. [ RFC:RFC1010.TXT ]A 15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,c SRI, November 1987. [ RFC:RFC1020.TXT ]HStahl [Page 9] cHRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987APPENDIX@ The following questionnaire may be FTPed from SRI-NIC.ARPA as NETINFO:DOMAIN-TEMPLATE.TXT.gH ---------------------------------------------------------------------G To establish a domain, the following information must be sent to theh2 NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):> NOTE: The key people must have electronic mailboxes and NICE "handles," unique NIC database identifiers. If you have access toaE "WHOIS", please check to see if you are registered and if so, makeeE sure the information is current. Include only your handle and anybF changes (if any) that need to be made in your entry. If you do notG have access to "WHOIS", please provide all the information indicateda% and a NIC handle will be assigned.s1 (1) The name of the top-level domain to join.a For example: COME (2) The NIC handle of the administrative head of the organization.eH Alternately, the person's name, title, mailing address, phone number,D organization, and network mailbox. This is the contact point forH administrative and policy questions about the domain. In the case ofA a research project, this should be the principal investigator. For example:  Administrator 6 Organization The NetWorthy Corporation3 Name Penelope Q. Sassafrassh& Title President6 Mail Address The NetWorthy Corporation8 4676 Andrews Way, Suite 1007 Santa Clara, CA 94302-1212C+ Phone Number (415) 123-4567n4 Net Mailbox Sassafrass@ECHO.TNC.COM NIC Handle PQS? (3) The NIC handle of the technical contact for the domain.tH Alternately, the person's name, title, mailing address, phone number,D organization, and network mailbox. This is the contact point forB problems concerning the domain or zone, as well as for updating( information about the domain or zone.HStahl [Page 10] HRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 For example: & Technical and Zone Contact6 Organization The NetWorthy Corporation. Name Ansel A. Aardvark/ Title Executive Directorh6 Mail Address The NetWorthy Corporation8 4676 Andrews Way, Suite 1008 Santa Clara, CA. 94302-1212+ Phone Number (415) 123-6789s2 Net Mailbox Aardvark@ECHO.TNC.COM! NIC Handle AAA2G (4) The name of the domain (up to 12 characters). This is the nametH that will be used in tables and lists associating the domain with theH domain server addresses. [While, from a technical standpoint, domainB names can be quite long (programmers beware), shorter names are# easier for people to cope with.]o For example: TNCH (5) A description of the servers that provide the domain service forH translating names to addresses for hosts in this domain, and the date they will be operational.D A good way to answer this question is to say "Our server isI supplied by person or company X and does whatever their standard  issue server does."E For example: Our server is a copy of the one operated byaA the NIC; it will be installed and made operational one 1 November 1987.D (6) Domains must provide at least two independent servers for theE domain. Establishing the servers in physically separate locationsSG and on different PSNs is strongly recommended. A description of the + server machine and its backup, includingrHStahl [Page 11] HRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987D (a) Hardware and software (using keywords from the Assigned Numbers RFC).H (b) Host domain name and network addresses (which host on which- network for each connected network).mG (c) Any domain-style nicknames (please limit your domain-stylet! nickname request to one)T For example:e# - Hardware and softwarel+ VAX-11/750 and UNIX, or + IBM-PC and MS-DOS, orp' DEC-1090 and TOPS-20f5 - Host domain names and network addressesd0 BAR.FOO.COM 10.9.0.193 on ARPANET# - Domain-style nicknamepD BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)G (7) Planned mapping of names of any other network hosts, other thand; the server machines, into the new domain's naming space.w For example:6 BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM6 BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM6 BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COMF (8) An estimate of the number of hosts that will be in the domain. (a) Initially (b) Within one year (c) Two years (d) Five years. For example:I! (a) Initially = 50e! (b) One year = 100l! (c) Two years = 200! (d) Five years = 500eHStahl Ȩ} RELEASEB.SAVo B=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1032.TXT;1K<4 [Page 12] oHRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987E (9) The date you expect the fully qualified domain name to becomei' the official host name in HOSTS.TXT.iI Please note: If changing to a fully qualified domain name (e.g.,,E FOO.BAR.COM) causes a change in the official host name of ansJ ARPANET or MILNET host, DCA approval must be obtained beforehand.J Allow 10 working days for your requested changes to be processed.I ARPANET sites should contact ARPANETMGR@DDN1.ARPA. MILNET siteseB should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for further instructions.2 (10) Please describe your organization briefly.? For example: The NetWorthy Corporation is a consulting J organization of people working with UNIX and the C language in anF electronic networking environment. It sponsors two technicalE conferences annually and distributes a bimonthly newsletter.H ---------------------------------------------------------------------F This example of a completed application corresponds to the examplesC found in the companion document RFC-1033, "Domain Administrators Operations Guide." 1 (1) The name of the top-level domain to join. COM < (2) The NIC handle of the administrative contact person. NIC Handle JAKE9 (3) The NIC handle of the domain's technical and zonea contact person. NIC Handle DLE6 (4) The name of the domain.i SRIG% (5) A description of the servers.bF Our server is the TOPS20 server JEEVES supplied by ISI; itB will be installed and made operational on 1 July 1987.HStahl [Page 13] -HRFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987; (6) A description of the server machine and its backup: % (a) Hardware and softwareN& DEC-1090T and TOPS20& DEC-2065 and TOPS204 (b) Host domain name and network addressE KL.SRI.COM 10.1.0.2 on ARPANET, 128.18.10.6 on SRINET I STRIPE.SRI.COM 10.4.0.2 on ARPANET, 128.18.10.4 on SRINETp% (c) Domain-style nicknamem NoneG (7) Planned mapping of names of any other network hosts, other than ; the server machines, into the new domain's naming space.t@ SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM5 SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COMeG (8) An estimate of the number of hosts that will be directly withint this domain.I! (a) Initially = 50n! (b) One year = 100! (c) Two years = 200a! (d) Five years = 500H (9) A date when you expect the fully qualified domain name to become' the official host name in HOSTS.TXT.f 31 September 1987I+ (10) Brief description of organization.DF SRI International is an independent, nonprofit, scientificJ research organization. It performs basic and applied researchE for government and commercial clients, and contributes torK worldwide economic, scientific, industrial, and social progresss2 through research and related services.HStahl [Page 14] C 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 Example:' @whois domain rice.edu& Rice University (RICE-DOM)) Advanced Studies and Research Houston, TX 77001! Domain Name: RICE.EDU& Administrative Contact:H Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834/ Technical Contact, Zone Contact:4 Riffle, Vicky R. (VRR) ri=*[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1033.TXT;1+,s=.J/@ 4HJJ-B0123 KPWOK56sWaؒ76ޒ8>9G@HJ GNetwork Working Group M. LottorGRequest For Comments: 1033 SRI InternationalG November 19877 DOMAIN ADMINISTRATORS OPERATIONS GUIDESTATUS OF THIS MEMOH This RFC provides guidelines for domain administrators in operating aB domain server and maintaining their portion of the hierarchical< database. Familiarity with the domain system is assumed.* Distribution of this memo is unlimited.ACKNOWLEDGMENTSE This memo is a formatted collection of notes and excerpts from theH 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 willE normally have some number of boot/startup files (also known as theE "safety belt" files). One section will contain a list of possibleG root servers that the server will use to find the up-to-date list ofG root servers. Another section will list the zone files to be loadedB into the server for your local domain information. A zone fileG 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 areH attempting to do anything advanced or tricky, consult the appropriate! domain RFC's for more details.F Note: Each implementation of domain software may require differentC files. Zone files are standardized but some servers may requireE other startup files. See the appropriate documentation that comesD with your software. See the appendix for some specific examples.ZONESD A zone defines the contents of a contiguous section of the domainC space, usually bounded by administrative boundaries. There willG typically be a separate data file for each zone. The data containedG in a zone file is composed of entries called Resource Records (RRs).HLottor [Page 1] HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987; You may only put data in your domain server that you areF authoritative for. You must not add entries for domains other than< your own (except for the special case of "glue records").G A domain server will probably read a file on start-up that lists theF zones it should load into its database. The format of this file is; not standardized and is different for most domain serverF implementations. For each zone it will normally contain the domainH name of the zone and the file name that contains the data to load for the zone. ROOT SERVERSF A resolver will need to find the root servers when it first starts.E When the resolver boots, it will typically read a list of possible root servers from a file.G The resolver will cycle tuY RELEASEB.SAVs=B=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1033.TXT;1HJQhrough the list trying to contact each one.F When it finds a root server, it will ask it for the current list ofG root servers. It will then discard the list of root servers it readG from the data file and replace it with the current list it received.E Root servers will not change very often. You can get the names of% current root servers from the NIC.B 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:4 SRI-NIC.ARPA 10.0.0.51 26.0.0.73' C.ISI.EDU 10.0.0.52C BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2( A.ISI.EDU 26.3.0.103RESOURCE RECORDSD Records in the zone data files are called resource records (RRs).C They are specified in RFC-883 and RFC-973. An RR has a standard format as shown:9 [] [] H The record is divided into fields which are separated by white space. E The name field defines what domain name applies to the givenHLottor [Page 2] HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987H RR. In some cases the name field can be left blank and it will6 default to the name field of the previous RR. E TTL stands for Time To Live. It specifies how long a domainH resolver should cache the RR before it throws it out and asks aF domain server again. See the section on TTL's. If you leave@ the TTL field blank it will default to the minimum time7 specified in the SOA record (described later). H The class field specifies the protocol group. If left blank it2 will default to the last class specified. F The type field specifies what type of data is in the RR. See the section on types. F 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 ofG resource records. Listing RRs (such as multiple address records) inF a certain order does not guarantee they will be used in that order.G Case is preserved in names and data fields when loaded into the nameC server. All comparisons and lookups in the name server are case insensitive.C Parenthesis ("(",")") are used to group data that crosses a line boundary.C 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.HLottor [Page 3] HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987NAMES; A domain name is a sequence of labels separated by dots.A Domain names in the zone files can be one of two types, eitherH absolute or relative. An absolute name is the fully qualified domainB name and is terminated with a period. A relative name does notF terminate with a period, and the current default domain is appendedH to it. The default domain is usually the name of the domain that was3 specified in the boot file that loads each zone.C The domain system allows a label to contain any 8-bit character.G Although the domain system has no restrictions, other protocols such@ as SMTP do have name restrictions. Because of other protocolF restrictions, only the following characters are recommended for use. in a host name (besides the dot separator):3 "A-Z", "a-z", "0-9", dash and underscoreTTL's (Time To Live)G It is important that TTLs are set to appropriate values. The TTL isF the time (in seconds) that a resolver will use the data it got fromF your server before it asks your server again. If you set the value@ too low, your server will get loaded down with lots of repeatF requests. If you set it too high, then information you change willH not get distributed in a reasonable amount of time. If you leave theC TTL field blank, it will default to what is specified in the SOA record for the zone.H Most host information does not change much over long time periods. AE good way to set up your TTLs would be to set them at a high value,E and then lower the value if you know a change will be coming soon.G You might set most TTLs to anywhere between a day (86400) and a weekF (604800). Then, if you know some data will be changing in the nearF future, set the TTL for that RR down to a lower value (an hour to aD day) until the change takes place, and then put it back up to its previous value.D Also, all RRs with the same name, class, and type should have the same TTL value.CLASSESH The domain system was designed to be protocol independent. The classC field is used to identify the protocol group that each RR is in.E The class of interest to people using TCP/IP software is the classHLottor [Page 4] HRFC 1033 DOMAIN OPERATIONS GUIDE November 19871 "Internet". Its standard designation is "IN".9 A zone file should only contain RRs of the same class.TYPESH There are many defined RR types. For a complete list, see the domainF specification RFCs. Here is a list of current commonly used types.; The data for each type is described in the data section.6 Designation Description8 ==========================================5 SOA Start Of Authority. NS Name Server3 A Internet AddressD CNAME Canonical Name (nickname pointer)3 HINFO Host Information6 WKS Well Known Services1 MX Mail Exchanger* PTR PointerSOA (Start Of Authority)A [] [] SOA (# $ " # & )E The Start Of Authority record designates the start of a zone. The$ zone ends at the next SOA record." is the name of the zone.A is the name of the host on which the master zone file resides.H is a mailbox for the person responsible for the zone. It isA formatted like a mailing address but the at-sign that normally@ separates the user from the host name is replaced with a dot.A is the version number of the zone file. It should be< incremented anytime a change is made to data in the zone.HLottor [Page 5] HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987C is how long, in seconds, a secondary name server is toG check with the primary name server to see if an update is needed. A, good value here would be one hour (3600).G is how long, in seconds, a secondary name server is to retryF  RELEASEB.SAVs=B=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1033.TXT;1HJJ after a failure to check for a refresh. A good value here would be 10 minutes (600).H is the upper limit, in seconds, that a secondary name serverF is to use the data before it expires for lack of getting a refresh.G You want this to be rather large, and a nice value is 3600000, about 42 days.G is the minimum number of seconds to be used for TTL valuesE in RRs. A minimum of at least a day is a good value here (86400).E There should only be one SOA record per zone. A sample SOA record would look something like:D @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (- 45 ;serial. 3600 ;refresh, 600 ;retry- 3600000 ;expire. 86400 ) ;minimumNS (Name Server)7 [] [] NS A The NS record lists the name of a machine that provides domainG service for a particular domain. The name associated with the RR isB the domain name and the data portion is the name of a host thatH provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provideD name lookup service for the domain COM then the following entries would be used:( COM. NS SRI-NIC.ARPA.% NS C.ISI.EDU.G Note that the machines providing name service do not have to live inG the named domain. There should be one NS record for each server forF a domain. Also note that the name "COM" defaults for the second NS record.D NS records for a domain exist in both the zone that delegates the$ domain, and in the domain itself.HLottor [Page 6] HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987 GLUE RECORDSG If the name server host for a particular domain is itself inside theF domain, then a 'glue' record will be needed. A glue record is an AG (address) RR that specifies the address of the server. Glue recordsB are only needed in the server delegating the domain, not in theH domain itself. If for example the name server for domain SRI.COM wasD 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)5 [] [] A
D The data for an A record is an internet address in dotted decimal, form. A sample A record might look like:4 SRI-NIC.ARPA. A 10.0.0.51; There should be one A record for each address of a host.CNAME ( Canonical Name): [] [] CNAME H The CNAME record is used for nicknames. The name associated with theC RR is the nickname. The data portion is the official name. ForF example, a machine named SRI-NIC.ARPA may want to have the nickname; NIC.ARPA. In that case, the following RR would be used:0 NIC.ARPA. CNAME SRI-NIC.ARPA.D There must not be any other RRs associated with a nickname of the same class.D Nicknames are also useful when a host changes it's name. In thatB 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.HLottor [Page 7] HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987HINFO (Host Info)G [] [] HINFO H The HINFO record gives information about a particular host. The dataA is two strings separated by whitespace. The first string is aD hardware description and the second is software. The hardware isH usually a manufacturer name followed by a dash and model designation.C The software string is usually the name of the operating system.H Official HINFO types can be found in the latest Assigned Numbers RFC,D 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 UNIXWKS (Well Known Services)G [] [] WKS
F The WKS record is used to list Well Known Services a host provides.G WKS's are defined to be services on port numbers below 256. The WKSH record lists what services are available at a certain address using aH certain protocol. The common protocols are TCP or UDP. A sample WKSD record for a host offering the same services on all address would look like:F 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 SMTP4 WKS 10.0.0.51 UDP TIME? WKS 26.0.0.73 TCP TELNET FTP SMTP4 WKS 26.0.0.73 UDP TIME4MX (Mail Exchanger) (See RFC-974 for more details.)B [] [] MX G MX records specify where mail for a domain name should be delivered.? There may be multiple MX records for a particular name. The G preference value specifies the order a mailer should try multiple MXmA records when delivering mail. Zero is the highest preference. C Multiple records for the same name may have the same preference. HLottor [Page 8] HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987C A host BAR.FOO.COM may want its mail to be delivered to the hostd/ PO.FOO.COM and would then use the MX record:s6 BAR.FOO.COM. MX 10 PO.FOO.COM.G A host BAZ.FOO.COM may want its mail to be delivered to one of threes. different machines, in the following order:7 BAZ.FOO.COM. MX 10 PO1.FOO.COM.i7 MX 20 PO2.FOO.COM.r7 MX 30 PO3.FOO.COM.lC An entire domain of hosts not connected to the Internet may wantyD their mail to go through a mail gateway that knows how to deliverF 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:8 FOO.COM. MX 10 RELAY.CS.NET.8 *.FOO.COM. MX 20 RELAY.CS.NET.D 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 apC hierarchical way such that the address of a name can be found byeE tracing down the domain tree contacting a server for each label of H the name. Because of this 'indexing' based on name, there is no easy; way to translate a host address back into its host name.fF In order to do the reverse translation easily, a domain was createdG that uses hosts' addresses as part of a name that then points to thesF data for that host. In this way, there is now an 'index' to hosts'E RRs based on their address. This address mapping domain #Q RELEASEB.SAVs=B=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1033.TXT;1ONE_MASTER;4HJ=%is calledeE IN-ADDR.ARPA. Within that domain are subdomains for each network,o> based on network number. Also, for consistency and natural9 groupings, the 4 octets of a host number are reversed. D For example, the ARPANET is net 10. That means there is a domainC called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR atoE 51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA E (who's address is 10.0.0.51). Since the NIC is also on the MILNETtG (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN- G ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The formatE of these special pointers is defined below along with the examplesn for the NIC.zHLottor [Page 9] SHRFC 1033 DOMAIN OPERATIONS GUIDE November 1987PTR < [] [] PTR B 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-B ADDR.ARPA records for translation of addresses to names. PTR's- should use official names and not aliases.H For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73H would have the following records in the respective zone files for net 10 and net 26:r7 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.T7 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. GATEWAY PTR'seC The IN-ADDR tree is also used to locate gateways on a particular3G network. Gateways have the same kind of PTR RRs as hosts (as above) F but in addition they have other PTRs used to locate them by networkF number alone. These records have only 1, 2, or 3 octets as part ofD the name depending on whether they are class A, B, or C networks, respectively.F Lets take the SRI-CSL gateway for example. It connects 3 differentH networks, one class A, one class B and one class C. It will have the4 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.2F Also, in 3 different zones (one for each network), it will have one8 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.H 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.HLottor [Page 10] pHRFC 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.G Add an NS record for each server of the new domain to the zonem# file of the parent domain.r$ Add any necessary glue RRs. Adding a host.d+ To add a new host to your zone files: F Edit the appropriate zone file for the domain the host is in.3 Add an entry for each address of the host..: Optionally add CNAME, HINFO, WKS, and MX records.C Add the reverse IN-ADDR entry for each host address in thec@ appropriate zone files for each network the host in on. Deleting a host.h+ To delete a host from the zone files:"E Remove all the hosts' resource records from the zone file off# the domain the host is in.oF Remove all the hosts' PTR records from the IN-ADDR zone files* for each network the host was on. Adding gateways.e/ Follow instructions for adding a host.eB Add the gateway location PTR records for each network the gateway is on.t Deleting gateways.t1 Follow instructions for deleting a host.F Also delete the gateway location PTR records for each networkHLottor [Page 11] fHRFC 1033 DOMAIN OPERATIONS GUIDE November 1987 the gateway was on. COMPLAINTSB These are the suggested steps you should take if you are havingF problems that you believe are caused by someone else's name server:H 1. Complain privately to the responsible person for the domain. YouC can find their mailing address in the SOA record for the domain. B 2. Complain publicly to the responsible person for the domain.D 3. Ask the NIC for the administrative person responsible for theF domain. Complain. You can also find domain contacts on the NIC in' the file NETINFO:DOMAIN-CONTACTS.TXTr1 4. Complain to the parent domain authorities. > 5. Ask the parent authorities to excommunicate the domain.HLottor [Page 12] HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987$EXAMPLE DOMAIN SERVER DATABASE FILESF The following examples show how zone files are set up for a typicalH organization. SRI will be used as the example organization. SRI hasE decided to divided their domain SRI.COM into a few subdomains, one C for each group that wants one. The subdomains are CSL and ISTC.a( Note the following interesting items:5 There are both hosts and domains under SRI.COM.e8 CSL.SRI.COM is both a domain name and a host name.F All the domains are serviced by the same pair of domain servers.G All hosts at SRI are on net 128.18 except hosts in the CSL domaineF which are on net 192.12.33. Note that a domain does not have to' correspond to a physical network.F The examples do not necessarily correspond to actual data in use by the SRI domain.. SRI Domain Organization( +-------+( | COM |( +-------+$ |( +-------+( | SRI |( +-------+$ |1 +----------++-----------+e1 | | |e5 +-------+ +------+ +-------+5 | CSL | | ISTC | | Hosts |n5 +-------+ +------+ +-------+=% | |S* +-------+ +-------+* | Hosts | | Hosts |* +-------+ +-------+HLottor [Page 13] HHRFC 1033 DOMAIN OPERATIONS GUIDE November 1987H [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 7 load zone SRI.COM. from file SRI.ZONE<7 load zone CSL.SRI.COM. from file CSL.ZONE 8 load zone ISTC.SRI.COM. from file IrN RELEASEB.SAVs=B=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1033.TXT;1HJ94STC.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<HLottor [Page 14] pHRFC 1033 DOMAIN OPERATIONS GUIDE November 1987? [File "ROOT.SERVERS". Again, the format of this file is note standardized.]! ;list of possible root serversf, 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.103HLottor [Page 15] tHRFC 1033 DOMAIN OPERATIONS GUIDE November 1987 [File "SRI.ZONE"]D SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (2 870407 ;serialD 1800 ;refresh every 30 minutesB 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 hostsb# KL A 10.1.0.2A& A 128.18.10.6. MX 10 KL.SRI.COM.# STRIPE A 10.4.0.2 & STRIPE A 128.18.10.42 MX 10 STRIPE.SRI.COM.( NIC CNAME SRI-NIC.ARPA.% Blackjack A 128.18.2.1 / HINFO VAX-11/780 UNIX9 WKS 128.18.2.1 TCP TELNET FTP>& CSL A 192.12.33.21 HINFO FOONLY-F4 TOPS20sE WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER / MX 10 CSL.SRI.COM. HLottor [Page 16] eHRFC 1033 DOMAIN OPERATIONS GUIDE November 1987 [File "CSL.ZONE"]D CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (2 870330 ;serialD 1800 ;refresh every 30 minutesB 600 ;retry every 10 minutes? 604800 ;expire after a weekh< 86400 ;default of a day$ ). CSL.SRI.COM. NS KL.SRI.COM.2 NS STRIPE.SRI.COM.. A 192.12.33.2 ;CSL.SRI.COM hostsr' A CNAME CSL.SRI.COM.& B A 192.12.33.31 HINFO FOONLY-F4 TOPS20t> WKS 192.12.33.3 TCP TELNET FTP SMTP# GW A 10.2.0.2 & A 192.12.33.1% A 128.18.1.1n. HINFO PDP-11/23 MOS& SMELLY A 192.12.33.41 HINFO IMAGEN IMAGEN & SQUIRREL A 192.12.33.54 HINFO XEROX-1100 INTERLISP& VENUS A 192.12.33.70 HINFO SYMBOLICS-3600 LISPM' HELIUM A 192.12.33.30a/ HINFO SUN-3/160 UNIXN' ARGON A 192.12.33.31 / HINFO SUN-3/75 UNIX ' RADON A 192.12.33.32 / HINFO SUN-3/75 UNIX HLottor [Page 17] HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987 [File "ISTC.ZONE"]vH ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (2 870406 ;serialD 1800 ;refresh every 30 minutesB 600 ;retry every 10 minutes? 604800 ;expire after a weeke< 86400 ;default of a day ). ISTC.SRI.COM. NS KL.SRI.COM.2 NS STRIPE.SRI.COM.= MX 10 SPAM.ISTC.SRI.COM. ; ISTC hostso% joyce A 128.18.4.2>* HINFO VAX-11/750 UNIX% bozo A 128.18.0.6 # HINFO SUN UNIXw& sundae A 128.18.0.11# HINFO SUN UNIXi' tsca A 128.18.0.201r# A 10.3.0.2a* HINFO VAX-11/750 UNIX1 MX 10 TSCA.ISTC.SRI.COM.  tsc CNAME tsca ' prmh A 128.18.0.203s$ A 10.2.0.51) HINFO PDP-11/44 UNIXl% spam A 128.18.4.3e% A 10.2.0.107S* HINFO VAX-11/780 UNIX1 MX 10 SPAM.ISTC.SRI.COM. HLottor [Page 18] >HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987 [File "SRINET.ZONE"]eE 18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (e. 870406 ;serial@ 1800 ;refresh every 30 minutes> 600 ;retry every 10 minutes; 604800 ;expire after a week 8 86400 ;default of a day ). 18.128.IN-ADDR.ARPA. NS KL.SRI.COM.2 NS STRIPE.SRI.COM.2 PTR GW.CSL.SRI.COM.- ; SRINET [128.18.0.0] Address TranslationsT ; SRI.COM Hosts= 1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM.l ; ISTC.SRI.COM Hostso> 2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM.= 6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM.a? 11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM.e= 201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM.e= 203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM.e= 3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM.e ; CSL.SRI.COM Hosts: 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.HLottor [Page 19] HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987 [File "SRI-CSL-NET.ZONE"]D 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 weekF8 86400 ;default of a day ). 33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM.2 NS STRIPE.SRI.COM.2 DY RELEASEB.SAVs=B=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1033.TXT;1HJ C PTR GW.CSL.SRI.COM.3 ; SRI-CSL-NET [192.12.33.0] Address Translationso ; SRI.COM Hosts7 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.9 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.d> 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.rHLottor [Page 20] HRFC 1033 DOMAIN OPERATIONS GUIDE November 1987APPENDIXG BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSDh UNIXsE This section describes two BIND implementation specific files; the D boot file and the cache file. BIND has other options, files, andC specifications that are not described here. See the Name Servero) Operations Guide for BIND for details. ? The boot file for BIND is usually called "named.boot". ThisI; corresponds to file "CONFIG.CMD" in the example section..C --------------------------------------------------------h; cache . named.caE; primary SRI.COM SRI.ZONE ; primary CSL.SRI.COM CSL.ZONE < primary ISTC.SRI.COM ISTC.ZONE> primary 18.128.IN-ADDR.ARPA SRINET.ZONEC primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE C --------------------------------------------------------v> The cache file for BIND is usually called "named.ca". This= corresponds to file "ROOT.SERVERS" in the example section.n< -------------------------------------------------) ;list of possible root serversc5 . 1 IN NS SRI-NIC.ARPA.s2 NS C.ISI.EDU.5 NS BRL-AOS.ARPA.d2 NS C.ISI.EDU. ;and their addresses1 SRI-NIC.ARPA. A 10.0.0.51A1 A 26.0.0.73-1 C.ISI.EDU. A 10.0.0.523 BRL-AOS.ARPA. A 192.5.25.82 3 A 192.5.22.82 2 A 128.20.1.22 A.ISI.EDU. A 26.3.0.103< -------------------------------------------------HLottor [Page 21] lHRFC 1033 DOMAIN OPERATIONS GUIDE November 1987 REFERENCESB [1] Dunlap, K., "Name Server Operations Guide for BIND", CSRG,C Department of Electrical Engineering and Computer Sciences,.7 University of California, Berkeley, California. E [2] Partridge, C., "Mail Routing and the Domain System", RFC-974,i1 CSNET CIC BBN Laboratories, January 1986. C [3] Mockapetris, P., "Domains Names - Concepts and Facilities", D RFC-1034, USC/Information Sciences Institute, November 1987.H [4] Mockapetris, P., "Domain Names - Implementations Specification",D RFC-1035, USC/Information Sciences Institute, November 1987.HLottor [Page 22] 1128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.< 33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.HLottor [Page 10] pHRFC 1033 DOMAIN OPERATIONS GUIDE November 1987 INSTRUCTIONS Adding a subdomain.,=*[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1034.TXT;1+,v./@ 4H*-B0123 KPWO56fuaؒ7@)$6ޒ8Ri>9G@HJ HNetwork Working Group P. MockapetrisHRequest for Comments: 1034 ISIHObsoletes: RFCs 882, 883, 973 November 19877 DOMAIN NAMES - CONCEPTS AND FACILITIES1. STATUS OF THIS MEMOFThis RFC is an introduction to the Domain Name System (DNS), and omitsCmany details which can be found in a companion RFC, "Domain Names -HImplementation and Specification" [RFC-1035]. That RFC assumes that the<reader is familiar with the concepts discussed in this memo.?A subset of DNS functions and data types constitute an officialDprotocol. The official protocol includes standard queries and theirAresponses and most of the Internet class data formats (e.g., host addresses).HHowever, the domain system is intentionally extensible. Researchers areDcontinuously proposing, implementing and experimenting with new dataGtypes, query types, classes, functions, etc. Thus while the componentsGof the official protocol are expected to stay essentially unchanged andGoperate as a production service, experimental behavior should always beEexpected in extensions beyond the official protocol. Experimental orHobsolete features are clearly marked in these RFCs, and such informationshould be used with caution.DThe reader is especially cautioned not to depend on the values whichDappear in examples to be current or complete, since their purpose is?primarily pedagogical. Distribution of this memo is unlimited.2. INTRODUCTIONGThis RFC introduces domain style names, their use for Internet mail andEhost address support, and the protocols and servers used to implementdomain name facilities. 2.1. The history of domain namesFThe impetus for the development of the domain system was growth in the Internet:A - Host name to address mappings were maintained by the Network@ Information Center (NIC) in a single file (HOSTS.TXT) whichB was FTPed by all hosts [RFC-952, RFC-953]. The total networkHMockapetris [Page 1] HRFC 1034 Domain Concepts and Facilities November 1987= bandwidth consumed in distributing a new version by thisC scheme is proportional to the square of the number of hosts in@ the network, and even when multiple levels of FTP are used,; the outgoing FTP load on the NIC host is considerable.A Explosive growth in the number of hosts didn't bode well for the future.@ - The network population was also changing in character. TheB timeshared hosts that made up the original ARPANET were being9 replaced with local networks of workstations. Local9 organizations were administering their own names andB addresses, but had to wait for the NIC to change HOSTS.TXT toB make changes visible to the Internet at large. Organizations8 also wanted some local structure on the name space.7 - The applications  RELEASEB.SAVvB=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1034.TXT;1Htdon the Internet were getting more? sophisticated and creating a need for general purpose name service.CThe result was several ideas about name spaces and their managementB[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but aAcommon thread was the idea of a hierarchical name space, with theFhierarchy roughly corresponding to organizational structure, and namesBusing "." as the character to mark the boundary between hierarchyHlevels. A design using a distributed database and generalized resourcesFwas described in [RFC-882, RFC-883]. Based on experience with severalEimplementations, the system evolved into the scheme described in thismemo.HThe terms "domain" or "domain name" are used in many contexts beyond theFDNS described here. Very often, the term domain name is used to referGto a name with structure indicated by dots, but no relation to the DNS.=This is particularly true in mail addressing [Quarterman 86].2.2. DNS design goals?The design goals of the DNS influence its structure. They are:C - The primary goal is a consistent name space which will be used@ for referring to resources. In order to avoid the problems@ caused by ad hoc encodings, names should not be required to? contain network identifiers, addresses, routes, or similar% information as part of the name.< - The sheer size of the database and frequency of updates@ suggest that it must be maintained in a distributed manner,@ with local caching to improve performance. Approaches thatHMockapetris [Page 2] HRFC 1034 Domain Concepts and Facilities November 1987@ attempt to collect a consistent copy of the entire databaseA will become more and more expensive and difficult, and henceC should be avoided. The same principle holds for the structureA of the name space, and in particular mechanisms for creating: and deleting names; these should also be distributed.B - Where there tradeoffs between the cost of acquiring data, the@ speed of updates, and the accuracy of caches, the source of* the data should control the tradeoff.A - The costs of implementing such a facility dictate that it beB generally useful, and not restricted to a single application.? We should be able to use names to retrieve host addresses,B mailbox data, and other as yet undetermined information. AllC data associated with a name is tagged with a type, and queries% can be limited to a single type.> - Because we want the name space to be useful in dissimilarA networks and applications, we provide the ability to use the8 same name space with different protocol families orB management. For example, host address formats differ between@ protocols, though all protocols have the notion of address.? The DNS tags all data with a class as well as the type, soA that we can allow parallel use of different formats for data of type address.> - We want name server transactions to be independent of the? communications system that carries them. Some systems may> wish to use datagrams for queries and responses, and only> establish virtual circuits for transactions that need theC reliability (e.g., database updates, long transactions); other3 systems will use virtual circuits exclusively.? - The system should be useful across a wide spectrum of host@ capabilities. Both personal computers and large timeshared> hosts should be able to use the system, though perhaps in different ways.2.3. Assumptions about usageCThe organization of the domain system derives from some assumptionsHabout the needs and usage patterns of its user community and is designedFto avoid many of the the complicated problems found in general purposedatabase systems.The assumptions are:B - The size of the total database will initially be proportionalHMockapetris [Page 3] HRFC 1034 Domain Concepts and Facilities November 1987A to the number of hosts using the system, but will eventuallyB grow to be proportional to the number of users on those hosts? as mailboxes and other information are added to the domain system.B - Most of the data in the system will change very slowly (e.g.,B mailbox bindings, host addresses), but that the system shouldB be able to deal with subsets that change more rapidly (on the" order of seconds or minutes).5 - The administrative boundaries used to distribute? responsibility for the database will usually correspond toB organizations that have one or more hosts. Each organizationA that has responsibility for a particular set of domains willA provide redundant name servers, either on the organization's? own hosts or other hosts that the organization arranges to use.< - Clients of the domain system should be able to identify= trusted name servers they prefer to use before accepting= referrals to name servers outside of this "trusted" set.> - Access to information is more critical than instantaneous< updates or guarantees of consistency. Hence the updateA process allows updates to percolate out through the users ofC the domain system rather than guaranteeing that all copies areA simultaneously updated. When updates are unavailable due to@ network or host failure, the usual course is to believe old< information while continuing efforts to update it. TheC general model is that copies are distributed with timeouts for@ refreshing. The distributor sets the timeout value and the@ recipient of the distribution is responsible for performingB the refresh. In special situations, very short intervals can4 be specified, or the owner can prohibit copies.@ - In any system that has a distributed database, a particular? name server may be presented with a query that can only beB answered by some other server. The two general approaches toB dealing with this problem are "recursive", in which the firstC server pursues the query for the client at another server, andB "iterative", in which the server refers the client to anotherB server and lets the client pursue the query. Both approachesB have advantages and disadvantages, but the iterative approach? is preferred for the datagram style of access. The domainB system requires implementation of the iterative approach, but0 allows the recursive approach as an option.HMockapetris [Page 4] HRFC 1034 Domain Concepts and Facilities November 1987BThe domain system assumes that all data originates in master filesEscattered through the hosts that use the domain system. These masterHfiles are updated by local system administrators. Master files are textFfiles that are read by a local name server, and hence become availableAthrough the name servers to users of the domain system. The userHprograms access name servers through standard programs called resolvers.GThe standard format of master files allows them to be exchanged betweenGhosts (via FTP, mail, or some other mechanism); this facility is usefulGwhen an organization wants a domain, but doesn't want to support a nameGserver. The organization can maintain theӑ RELEASEB.SAVvB=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1034.TXT;1H master files locally using aFtext editor, transfer them to a foreign host which runs a name server,Hand then arrange with the system administrator of the name server to getthe files loaded.GEach host's name servers and resolvers are configured by a local systemEadministrator [RFC-1033]. For a name server, this configuration dataEincludes the identity of local master files and instructions on whichGnon-local master files are to be loaded from foreign servers. The name>server uses the master files or copies to load its zones. ForCresolvers, the configuration data identifies the name servers which-should be the primary sources of information.CThe domain system defines procedures for accessing the data and for@referrals to other name servers. The domain system also definesDprocedures for caching retrieved data and for periodic refreshing of)data defined by the system administrator."The system administrators provide:' - The definition of zone boundaries. - Master files of data. - Updates to master files.0 - Statements of the refresh policies desired.The domain system provides:( - Standard formats for resource data.0 - Standard methods for querying the database.A - Standard methods for name servers to refresh local data from foreign name servers.HMockapetris [Page 5] HRFC 1034 Domain Concepts and Facilities November 19872.4. Elements of the DNS#The DNS has three major components:: - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are= specifications for a tree structured name space and dataA associated with the names. Conceptually, each node and leafB of the domain name space tree names a set of information, and? query operations are attempts to extract specific types ofA information from a particular set. A query names the domain8 name of interest and describes the type of resource< information that is desired. For example, the InternetA uses some of its domain names to identify hosts; queries for6 address resources return Internet host addresses.B - NAME SERVERS are server programs which hold information about= the domain tree's structure and set information. A nameA server may cache structure or set information about any part@ of the domain tree, but in general a particular name serverA has complete information about a subset of the domain space,C and pointers to other name servers that can be used to lead to@ information from any part of the domain tree. Name serversC know the parts of the domain tree for which they have complete> information; a name server is said to be an AUTHORITY forA these parts of the name space. Authoritative information is> organized into units called ZONEs, and these zones can be@ automatically distributed to the name servers which provide. redundant service for the data in a zone.> - RESOLVERS are programs that extract information from name? servers in response to client requests. Resolvers must be> able to access at least one name server and use that nameC server's information to answer a query directly, or pursue theB query using referrals to other name servers. A resolver willA typically be a system routine that is directly accessible to> user programs; hence no protocol is necessary between the# resolver and the user program.FThese three components roughly correspond to the three layers or viewsof the domain system:A - From the user's point of view, the domain system is accessed? through a simple procedure or OS call to a local resolver.@ The domain space consists of a single tree and the user can6 request information from any section of the tree.< - From the resolver's point of view, the domain system is> composed of an unknown number of name servers. Each nameHMockapetris [Page 6] HRFC 1034 Domain Concepts and Facilities November 1987C server has one or more pieces of the whole domain tree's data,B but the resolver views each of these databases as essentially static.C - From a name server's point of view, the domain system consistsB of separate sets of local information called zones. The nameC server has local copies of some of the zones. The name server> must periodically refresh its zones from master copies in? local files or foreign name servers. The name server must= concurrently process queries that arrive from resolvers.AIn the interests of performance, implementations may couple theseHfunctions. For example, a resolver on the same machine as a name serverFmight share a database consisting of the the zones managed by the name-server and the cache managed by the resolver.)3. DOMAIN NAME SPACE and RESOURCE RECORDS.3.1. Name space specifications and terminologyEThe domain name space is a tree structure. Each node and leaf on theDtree corresponds to a resource set (which may be empty). The domainGsystem makes no distinctions between the uses of the interior nodes and<leaves, and this memo uses the term "node" to refer to both.EEach node has a label, which is zero to 63 octets in length. BrotherFnodes may not have the same label, although the same label can be usedEfor nodes which are not brothers. One label is reserved, and that ise5the null (i.e., zero length) label used for the root. HThe domain name of a node is the list of the labels on the path from theGnode to the root of the tree. By convention, the labels that compose aNEdomain name are printed or read left to right, from the most specificEH(lowest, farthest from the root) to the least specific (highest, closest to the root). GInternally, programs that manipulate domain names should represent themiFas sequences of labels, where each label is a length octet followed byGan octet string. Because all domain names end at the root, which has a.Hnull string for a label, these internal representations can use a length(byte of zero to terminate a domain name.BBy convention, domain names can be stored with arbitrary case, butFdomain name comparisons for all present domain functions are done in aDcase-insensitive manner, assuming an ASCII character set, and a highCorder zero bit. This means that you are free to create a node withfGlabel "A" or a node with label "a", but not both as brothers; you couldeDrefer to either using "a" or "A". When you receive a domain name orHMockapetris [Page 7] fHRFC 1034 Domain Concepts and Facilities November 1987Flabel, you should preserve its case. The rationale for this choice is@that we may someday need to add full binary domain names for new1services; existing services would not be changed.iDWhen a user needs to type a domain name, the length of each label isEomitted and the labels are separated by dots ("."). Since a completehHdomain name ends with the root label, this leads to a printed form which<ends in a dot. We use this property to distinguish between:? - a character string which represents a complete domain namet@ (often called "absolute"). For example, "poneria.ISI.EDU."@ - a character string that represents the starting labels of a@ domain name which is incomplete, and should be completed by> local(7]7ONE_MASTER;4v҂UXDZ~\riL _`R_h6fKuzIfTlIU_Dpa|: %p*+~k2*g'9\, tXGX-ELJg&z@UDx\}p0%,fr`u8%.O8q7LSqOTgCWJ^[c}]0FaK_o"D<^BV$V8n~Il C('x@YZQxrx*E,b=DLG_toQMY3]hg5!' ZwYlGXL"i~iX11nGWc T/dPN>}p$<1= #58t%'Mx)ePZtgf>"410g)XYr j3hbrQ1 A}Y5nMyeL1(gti69pzH9A-QCf\0:vA?C5 1g:NM}ZaM)h _"_No^8&))0l~omR-6GxH>|vc^?{ qBpFiZnwF`@l"2{CCU`.V]x UbS$1T*b .dtg9!pj\1ho]T ZL0b9"qrrD@kAvRhO l8i4b#30 ,4L]ore'&k3|cm_DuLi{8MCpXi TO (`SOyCz}T<`VHC9@rFWyK%a ).=N.k(2ZQlr#BU!.5 \fR^_kzt/x|AR{K7r5_BBl~ V* A] ~ ARVr% &*ug)}l']:![W'h4t wo&9<9I+ qsZoBIc$g8f9G.S[,0,}7TH'WF3_0H,M-[;~e !mG7 . P~W:o!0Nx-M]ErlPhO#@Y'v 2TBRci?}7 nzlM{xi1l,we]fV-f DHB`a8?>Iw`sg7\L9*ifTbw%( H@?9bJy[XD7\Ag_FOXROHg{rtdTzQcQc{vn;R~?^2#)D:`^= Wj/j)t>}hP). !b~I5as 5;W mxf[{akIRw7-*#;SiILF_?n\t0CLrGcE":sY [GE+8Vw [o)&-8 J /Y`7*&rFYA-YTlp/SA@p&M5R `t1b+fpI~i962IP XI] ;qr6+)jlU^FB7 DS@ L!@*#QIfk judhbc\ E$fw 1x{ kaM~Y^hMo]0h?b%.4aJzf1^ *LN|TLB$\(/ Z4 |q$n*e 3b?rzy+k@Xm^a8X1[+Zs7 XgvF. +jf F^-Noq& g!>U;Y H7F#5N8Ru9C#"]S3t H Z FUFJB I5eE 3dv1M(h 9e!c%\6@<068d3C;:-cltcbjGSl,*gAx% 8j^L43qijjj;n.5E~#*L]0c`ZZ$u=*7o\ xO/x,6G$xSjL@k!^Q;0_?Ot}S3QE{Emr&eH~;e~ j]7sHs\2yk#` (W{* /$30 }|SL3)]APFXq=0uoGG!#~$6t?>Tp+1)W9,JmQ|c& F mt7x"hKAGMQ7U[=^tI]MV0`;VelI %'-dd"0oa;hZ()ch{R|b:}1R;\kg^S Y2ZhH5:A%GVb@"U7!0j( }Bc]|rrNu1^CKjK\V`E'e`$H}kWoB,yd@c-\[g6DYS^W0^NUuA}`xKroeYl61} B+GU. +5$ "8+%&.ZMr ?:na2yKUJ.%&wgalsjC yJ=D>H|8oJ8HdDrf)]ao5{*Y@M/@6Xt FD -6/{,UR;aBkiNT V3,w{E8q]N<'K^ uiU~?QI,T%*$KyT/2#4Pl!z=ytJPLZ] G:H?2DWxGD ''Y*}~786D=OBr^b@6>)9:@]!?g[&S];$:1_k2DY]6<&MD EZPK2H!o^&=-.bL qy* i|T/rzGaM6C }~HB[ocz|+a6z5gJrY+):sqX\_m ^O Okhj"4\9EZ}RB T=K&$2w*vD, RES?>Pu+r;&>|tOo| Bq*(|U2>[$ X?Hp9+y):]Nbe&%!cV }2p3{/lr{6`3G@5 VWLSBL|#~^ d r eyS3SQUb "/nad>(/NJ8%G5UJ?/q0:cu=7l _I@Pj\ c[BvkL';rAB9*VZMMC mpJ h'WgHRO<:)c 'HIq51KVN *I I6L; EDCtXlOH.[e,ltW6O>y TDv#ikwsXGe$":#TX *Pwx' YyL))].jj@hU"hW%\How%6'WoP ^}ukS DC/&m6%O}G9&t;4 <yV|1 OSmuq9tZ^%_GEqPKCF'o5}kLPKF&5Z(WI4jQqmHYo`oe{a)DT(M?jc=wjalT(nx6t+J4CYo>*:.+|7Tu9k-j?5`tY=d'OY8 a'al ?G9=c-X ,Q\r,H*~z@etU@^Tn7 &v\ZuOlhaX6uN,j6yawxt74)7 8Vkw 5q~GRxL I@IxT_Q# 9'bH z}m%c,bd"u6NFVNIS E_% M ][*^  %"#dKpQNT2`< y`tG(ZoZ6-_]1K{1XjFoX|guiv:3S.EQDj)<#R7c/SFo ppW=5|) !/>;`N.BGV:HT}2X(#knOoc6tT+1v\E<0z 3gX0 +MTAyLn0#<6BMoz2>M`!&}M\Aq%k[-SU8E[%W GIgX*2Aa,3D""fqgjag*>bn f2bWm[ikwODb.D_ D 1J2;/d#^9hB!A7EEq:AP-Y`HBo)+Lbk"H8WHvJaCQe a=H%"g{zfssC83*D?@;~lig whWWXP9bsY2CVR;*&vb2?ZxKA _#S(i(q"1~89u'ja>HT|vtv]"@bzPNDDFiSVl[Zd58 "W;}PQx/FLJ wAX ;n%ydfwn/:DUD8R#\3hy ,iO/14,tl4%aX #f?cfA]2(c%39lG)|X(=!-,]f`-6i7U _F f\=/Fw1@]:kTd=YyjcNadi+@, MFcOY,kju"H:- \oz?[zsGb9(g\mA9K= zt|^qx= *5v2~>s6K+R'5l ?Rm4zu^(V_^dQ*V`#66eGjZa^7^UaR|i=Mn w8 :d\m&cj q=e:n !^JJdBGE)KLIS Byiu3(5(rS;^@R5k7d -BP\J.^e!2H>W=.v`Jd|$q-WjEN<@CC/NF9+d @ fQV [  sl?D4UnwW2?,MQn#EUH|KYMX;M.DuZ)08 Ih6X ?l)D3 ~x /csHvi0ng M 3;H F^$MF^9]5(:D3@T^*BA Ko_-'xO ;9 >h*(%Yek, UC?{JTJ`SkXU+0U{2vqb :^5CWac(7x6J7)\F _!:_P^-? IVj6j_ga%Rt|XS x Iq: Zwz|n>3@ xieu e!qDea'WN W?hewGhIY|\TxmF $pX{7"~f$z7nKGS> `qd(For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".%3.2. Administrative guidelines on useoHAs a matter of policy, the DNS technical specifications do not mandate aGparticular tree structure or rules for selecting labels; its goal is tohDbe as general as possible, so that it can be used to build arbitraryFapplications. In particular, the system was designed so that the name=space did not have to be organized along the lines of networkvFboundaries, name servers, etc. The rationale for this is not that theGname space should have no implied semantics, but rather that the choice Fof implied semantics should be left open to be used for the problem atHMockapetris [Page 8] mHRFC 1034 Domain Concepts and Facilities November 1987Ehand, and that different parts of the tree can have different impliedaAsemantics. For example, the IN-ADDR.ARPA domain is organized andgHdistributed by network and host address because its role is to translateFfrom network or host numbers to names; NetBIOS domains [RFC-1001, RFC-@1002] are flat because that is appropriate for that application.FHowever, there are some guidelines that apply to the "normal" parts ofGthe name space used for hosts, mailboxes, etc., that will make the name @space more uniform, provide for growth, and minimize problems as?software is converted from the older host table. The political Adecisions about the top levels of the tree originated in RFC-920.NECurrent policy for the top levels is discussed in [RFC-1032]. MILNETr,conversion issues are covered in [RFC-1031].HLower domains which will eventually be broken into multiple zones should?provide branching at the top of the domain so that the eventualuBdecomposition can be done without renaming. Node labels which useCspecial characters, leading digits, etc., are likely to break olderf3software which depends on more restrictive choices.a 3.3. Technical guidelines on useFBefore the DNS can be used to hold naming information for some kind ofobject, two needs must be met:= - A convention for mapping between object names and domainc> names. This describes how information about an object is accessed.9 - RR types and data formats for describing the object.CThese rules can be quite simple or fairly complex. Very often, the Ddesigner must take into account existing formats and plan for upwardAcompatibility for existing usage. Multiple mappings or levels ofemapping may be required.DFor hosts, the mapping depends on the existing syntax for host namesDwhich is a subset of the usual text representation for domain names,Htogether with RR formats for describing host addresses, etc. Because weDneed a reliable inverse mapping from address to host name, a specialCmapping for addresses into the IN-ADDR.ARPA domain is also defined.DFor mailboxes, the mapping is slightly more complex. The usual mailBaddress @ is mapped into a domain name byAconverting into a single label (regardles of dots itbFcontains), converting into a domain name using the usual<text format for domain names (dots denote label breaks), andEconcatenating the two to form a single domain name. Thus the mailbox HMockapetris [Page 9] HRFC 1034 Domain Concepts and Facilities November 1987:HOSTMASTER@SRI-NIC.ARPA is represented as a domain name byEHOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind thisFdesign also must take into account the scheme for mail exchanges [RFC-974].aGThe typical user is not concerned with defining these rules, but shouldeCunderstand that they usually are the result of numerous compromisesbEbetween desires for upward compatibility with old usage, interactions Hbetween different object definitions, and the inevitable urge to add newEfeatures when defining the rules. The way the DNS is used to supportoGsome object is often more crucial than the restrictions inherent in thenDNS.3.4. Example name spaceeGThe following figure shows a part of the current domain name space, and Cis used in many examples in this RFC. Note that the tree is a veryo&small subset of the actual name space.$ |$ |7 +---------------------+------------------+n7 | | |r9 MIL EDU ARPAo7 | | |s7 | | |a= +-----+-----+ | +------+-----+-----+e= | | | | | | |o> BRL NOSC DARPA | IN-ADDR SRI-NIC ACC$ |= +--------+------------------+---------------+--------+r= | | | | |r? UCI MIT | UDEL YALEi% | ISIs$ | |$ +---+---+ |$ | | |3 LCS ACHILLES +--+-----+-----+--------+ 3 | | | | | |u9 XX A C VAXA VENERA Mockapetris EIn this example, the root domain has three immediate subdomains: MIL,dHEDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named4XX.LCS.MIT.EDU. All of the leaves are also domains.3.5. Preferred name syntaxHThe DNS specifications attempt to be as general as possible in the rulesHMockapetris [Page 10] aHRFC 1034 Domain Concepts and Facilities November 1987@for constructing domain names. The idea is that the name of anyGexisting object can be expressed as a domain name with minimal changes. EHowever, when assigning a domain name for an object, the prudent userFwill select a name which satisfies both the rules of the domain systemHand any existing rules for the object, whether these rules are published or implied by existing programs.HFor example, when naming a mail domain, the user should satisfy both theHrules of this memo and those in RFC-m RELEASEB.SAVvB=[WAISMAN_PROGRAMS_SOURCE.DOMAIN_SERVER.RELEASEB]RFC1034.TXT;1H4822. When creating a new host name,Ethe old rules for HOSTS.TXT should be followed. This avoids problems,3when old software is converted to use domain names..<The following syntax will result in fewer problems with many8applications that use domain names (e.g., mail, TELNET). ::= | " "1 ::=