![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc1101.lpr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc|
Return to rfc1101.lpr CVS log | Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc |
1.1 root 1:
2:
3:
4:
5:
6:
7: Network Working Group P. Mockapetris
8: Request for Comments: 1101 ISI
9: Updates: RFCs 1034, 1035 April 1989
10:
11:
12: DNS Encoding of Network Names and Other Types
13:
14:
15: 1. STATUS OF THIS MEMO
16:
17: This RFC proposes two extensions to the Domain Name System:
18:
19: - A specific method for entering and retrieving RRs which map
20: between network names and numbers.
21:
22: - Ideas for a general method for describing mappings between
23: arbitrary identifiers and numbers.
24:
25: The method for mapping between network names and addresses is a
26: proposed standard, the ideas for a general method are experimental.
27:
28: This RFC assumes that the reader is familiar with the DNS [RFC 1034,
29: RFC 1035] and its use. The data shown is for pedagogical use and
30: does not necessarily reflect the real Internet.
31:
32: Distribution of this memo is unlimited.
33:
34: 2. INTRODUCTION
35:
36: The DNS is extensible and can be used for a virtually unlimited
37: number of data types, name spaces, etc. New type definitions are
38: occasionally necessary as are revisions or deletions of old types
39: (e.g., MX replacement of MD and MF [RFC 974]), and changes described
40: in [RFC 973]. This RFC describes changes due to the general need to
41: map between identifiers and values, and a specific need for network
42: name support.
43:
44: Users wish to be able to use the DNS to map between network names and
45: numbers. This need is the only capability found in HOSTS.TXT which
46: is not available from the DNS. In designing a method to do this,
47: there were two major areas of concern:
48:
49: - Several tradeoffs involving control of network names, the
50: syntax of network names, backward compatibility, etc.
51:
52: - A desire to create a method which would be sufficiently
53: general to set a good precedent for future mappings,
54: for example, between TCP-port names and numbers,
55:
56:
57:
58: Mockapetris [Page 1]
59:
60: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
61:
62:
63: autonomous system names and numbers, X.500 Relative
64: Distinguished Names (RDNs) and their servers, or whatever.
65:
66: It was impossible to reconcile these two areas of concern for network
67: names because of the desire to unify network number support within
68: existing IP address to host name support. The existing support is
69: the IN-ADDR.ARPA section of the DNS name space. As a result this RFC
70: describes one structure for network names which builds on the
71: existing support for host names, and another family of structures for
72: future yellow pages (YP) functions such as conversions between TCP-
73: port numbers and mnemonics.
74:
75: Both structures are described in following sections. Each structure
76: has a discussion of design issues and specific structure
77: recommendations.
78:
79: We wish to avoid defining structures and methods which can work but
80: do not because of indifference or errors on the part of system
81: administrators when maintaining the database. The WKS RR is an
82: example. Thus, while we favor distribution as a general method, we
83: also recognize that centrally maintained tables (such as HOSTS.TXT)
84: are usually more consistent though less maintainable and timely.
85: Hence we recommend both specific methods for mapping network names,
86: addresses, and subnets, as well as an instance of the general method
87: for mapping between allocated network numbers and network names.
88: (Allocation is centrally performed by the SRI Network Information
89: Center, aka the NIC).
90:
91: 3. NETWORK NAME ISSUES AND DISCUSSION
92:
93: The issues involved in the design were the definition of network name
94: syntax, the mappings to be provided, and possible support for similar
95: functions at the subnet level.
96:
97: 3.1. Network name syntax
98:
99: The current syntax for network names, as defined by [RFC 952] is an
100: alphanumeric string of up to 24 characters, which begins with an
101: alpha, and may include "." and "-" except as first and last
102: characters. This is the format which was also used for host names
103: before the DNS. Upward compatibility with existing names might be a
104: goal of any new scheme.
105:
106: However, the present syntax has been used to define a flat name
107: space, and hence would prohibit the same distributed name allocation
108: method used for host names. There is some sentiment for allowing the
109: NIC to continue to allocate and regulate network names, much as it
110: allocates numbers, but the majority opinion favors local control of
111:
112:
113:
114: Mockapetris [Page 2]
115:
116: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
117:
118:
119: network names. Although it would be possible to provide a flat space
120: or a name space in which, for example, the last label of a domain
121: name captured the old-style network name, any such approach would add
122: complexity to the method and create different rules for network names
123: and host names.
124:
125: For these reasons, we assume that the syntax of network names will be
126: the same as the expanded syntax for host names permitted in [HR].
127: The new syntax expands the set of names to allow leading digits, so
128: long as the resulting representations do not conflict with IP
129: addresses in decimal octet form. For example, 3Com.COM and 3M.COM
130: are now legal, although 26.0.0.73.COM is not. See [HR] for details.
131:
132: The price is that network names will get as complicated as host
133: names. An administrator will be able to create network names in any
134: domain under his control, and also create network number to name
135: entries in IN-ADDR.ARPA domains under his control. Thus, the name
136: for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa-
137: network.MIL., depending on the preferences of the owner.
138:
139: 3.2. Mappings
140:
141: The desired mappings, ranked by priority with most important first,
142: are:
143:
144: - Mapping a IP address or network number to a network name.
145:
146: This mapping is for use in debugging tools and status displays
147: of various sorts. The conversion from IP address to network
148: number is well known for class A, B, and C IP addresses, and
149: involves a simple mask operation. The needs of other classes
150: are not yet defined and are ignored for the rest of this RFC.
151:
152: - Mapping a network name to a network address.
153:
154: This facility is of less obvious application, but a
155: symmetrical mapping seems desirable.
156:
157: - Mapping an organization to its network names and numbers.
158:
159: This facility is useful because it may not always be possible
160: to guess the local choice for network names, but the
161: organization name is often well known.
162:
163: - Similar mappings for subnets, even when nested.
164:
165: The primary application is to be able to identify all of the
166: subnets involved in a particular IP address. A secondary
167:
168:
169:
170: Mockapetris [Page 3]
171:
172: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
173:
174:
175: requirement is to retrieve address mask information.
176:
177: 3.3. Network address section of the name space
178:
179: The network name syntax discussed above can provide domain names
180: which will contain mappings from network names to various quantities,
181: but we also need a section of the name space, organized by network
182: and subnet number to hold the inverse mappings.
183:
184: The choices include:
185:
186: - The same network number slots already assigned and delegated
187: in the IN-ADDR.ARPA section of the name space.
188:
189: For example, 10.IN-ADDR.ARPA for class A net 10,
190: 2.128.IN-ADDR.ARPA for class B net 128.2, etc.
191:
192: - Host-zero addresses in the IN-ADDR.ARPA tree. (A host field
193: of all zero in an IP address is prohibited because of
194: confusion related to broadcast addresses, et al.)
195:
196: For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
197: 0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc. Like the
198: first scheme, it uses in-place name space delegations to
199: distribute control.
200:
201: The main advantage of this scheme over the first is that it
202: allows convenient names for subnets as well as networks. A
203: secondary advantage is that it uses names which are not in use
204: already, and hence it is possible to test whether an
205: organization has entered this information in its domain
206: database.
207:
208: - Some new section of the name space.
209:
210: While this option provides the most opportunities, it creates
211: a need to delegate a whole new name space. Since the IP
212: address space is so closely related to the network number
213: space, most believe that the overhead of creating such a new
214: space is overwhelming and would lead to the WKS syndrome. (As
215: of February, 1989, approximately 400 sections of the
216: IN-ADDR.ARPA tree are already delegated, usually at network
217: boundaries.)
218:
219:
220:
221:
222:
223:
224:
225:
226: Mockapetris [Page 4]
227:
228: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
229:
230:
231: 4. SPECIFICS FOR NETWORK NAME MAPPINGS
232:
233: The proposed solution uses information stored at:
234:
235: - Names in the IN-ADDR.ARPA tree that correspond to host-zero IP
236: addresses. The same method is used for subnets in a nested
237: fashion. For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.
238:
239: Two types of information are stored here: PTR RRs which point
240: to the network name in their data sections, and A RRs, which
241: are present if the network (or subnet) is subnetted further.
242: If a type A RR is present, then it has the address mask as its
243: data. The general form is:
244:
245: <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
246: <reversed-host-zero-number>.IN-ADDR.ARPA. A <subnet-mask>
247:
248: For example:
249:
250: 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
251:
252: or
253:
254: 0.0.2.128.IN-ADDR.ARPA. PTR cmu-net.cmu.edu.
255: A 255.255.255.0
256:
257: In general, this information will be added to an existing
258: master file for some IN-ADDR.ARPA domain for each network
259: involved. Similar RRs can be used at host-zero subnet
260: entries.
261:
262: - Names which are network names.
263:
264: The data stored here is PTR RRs pointing at the host-zero
265: entries. The general form is:
266:
267: <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA
268:
269: For example:
270:
271: ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
272:
273: or
274:
275: isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA.
276:
277: In general, this information will be inserted in the master
278: file for the domain name of the organization; this is a
279:
280:
281:
282: Mockapetris [Page 5]
283:
284: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
285:
286:
287: different file from that which holds the information below
288: IN-ADDR.ARPA. Similar PTR RRs can be used at subnet names.
289:
290: - Names corresponding to organizations.
291:
292: The data here is one or more PTR RRs pointing at the
293: IN-ADDR.ARPA names corresponding to host-zero entries for
294: networks.
295:
296: For example:
297:
298: ISI.EDU. PTR 0.0.9.128.IN-ADDR.ARPA.
299:
300: MCC.COM. PTR 0.167.5.192.IN-ADDR.ARPA.
301: PTR 0.168.5.192.IN-ADDR.ARPA.
302: PTR 0.169.5.192.IN-ADDR.ARPA.
303: PTR 0.0.62.128.IN-ADDR.ARPA.
304:
305: 4.1. A simple example
306:
307: The ARPANET is a Class A network without subnets. The RRs which
308: would be added, assuming the ARPANET.ARPA was selected as a network
309: name, would be:
310:
311: ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
312:
313: ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.
314:
315: 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
316:
317: The first RR states that the organization named ARPA owns net 10 (It
318: might also own more network numbers, and these would be represented
319: with an additional RR per net.) The second states that the network
320: name ARPANET.ARPA. maps to net 10. The last states that net 10 is
321: named ARPANET.ARPA.
322:
323: Note that all of the usual host and corresponding IN-ADDR.ARPA
324: entries would still be required.
325:
326: 4.2. A complicated, subnetted example
327:
328: The ISI network is 128.9, a class B number. Suppose the ISI network
329: was organized into two levels of subnet, with the first level using
330: an additional 8 bits of address, and the second level using 4 bits,
331: for address masks of x'FFFFFF00' and X'FFFFFFF0'.
332:
333: Then the following RRs would be entered in ISI's master file for the
334: ISI.EDU zone:
335:
336:
337:
338: Mockapetris [Page 6]
339:
340: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
341:
342:
343: ; Define network entry
344: isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA.
345:
346: ; Define first level subnets
347: div1-subnet.isi.edu. PTR 0.1.9.128.IN-ADDR.ARPA.
348: div2-subnet.isi.edu. PTR 0.2.9.128.IN-ADDR.ARPA.
349:
350: ; Define second level subnets
351: inc-subsubnet.isi.edu. PTR 16.2.9.128.IN-ADDR.ARPA.
352:
353: in the 9.128.IN-ADDR.ARPA zone:
354:
355: ; Define network number and address mask
356: 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
357: A 255.255.255.0 ;aka X'FFFFFF00'
358:
359: ; Define one of the first level subnet numbers and masks
360: 0.1.9.128.IN-ADDR.ARPA. PTR div1-subnet.isi.edu.
361: A 255.255.255.240 ;aka X'FFFFFFF0'
362:
363: ; Define another first level subnet number and mask
364: 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
365: A 255.255.255.240 ;aka X'FFFFFFF0'
366:
367: ; Define second level subnet number
368: 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
369:
370: This assumes that the ISI network is named isi-net.isi.edu., first
371: level subnets are named div1-subnet.isi.edu. and div2-
372: subnet.isi.edu., and a second level subnet is called inc-
373: subsubnet.isi.edu. (In a real system as complicated as this there
374: would be more first and second level subnets defined, but we have
375: shown enough to illustrate the ideas.)
376:
377: 4.3. Procedure for using an IP address to get network name
378:
379: Depending on whether the IP address is class A, B, or C, mask off the
380: high one, two, or three bytes, respectively. Reverse the octets,
381: suffix IN-ADDR.ARPA, and do a PTR query.
382:
383: For example, suppose the IP address is 10.0.0.51.
384:
385: 1. Since this is a class A address, use a mask x'FF000000' and
386: get 10.0.0.0.
387:
388: 2. Construct the name 0.0.0.10.IN-ADDR.ARPA.
389:
390: 3. Do a PTR query. Get back
391:
392:
393:
394: Mockapetris [Page 7]
395:
396: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
397:
398:
399: 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.
400:
401: 4. Conclude that the network name is "ARPANET.ARPA."
402:
403: Suppose that the IP address is 128.9.2.17.
404:
405: 1. Since this is a class B address, use a mask of x'FFFF0000'
406: and get 128.9.0.0.
407:
408: 2. Construct the name 0.0.9.128.IN-ADDR.ARPA.
409:
410: 3. Do a PTR query. Get back
411:
412: 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu
413:
414: 4. Conclude that the network name is "isi-net.isi.edu."
415:
416: 4.4. Procedure for finding all subnets involved with an IP address
417:
418: This is a simple extension of the IP address to network name method.
419: When the network entry is located, do a lookup for a possible A RR.
420: If the A RR is found, look up the next level of subnet using the
421: original IP address and the mask in the A RR. Repeat this procedure
422: until no A RR is found.
423:
424: For example, repeating the use of 128.9.2.17.
425:
426: 1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
427: Retrieve:
428:
429: 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
430: A 255.255.255.0
431:
432: 2. Since an A RR was found, repeat using mask from RR
433: (255.255.255.0), constructing a query for
434: 0.2.9.128.IN-ADDR.ARPA. Retrieve:
435:
436: 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
437: A 255.255.255.240
438:
439: 3. Since another A RR was found, repeat using mask
440: 255.255.255.240 (x'FFFFFFF0'). constructing a query for
441: 16.2.9.128.IN-ADDR.ARPA. Retrieve:
442:
443: 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
444:
445: 4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
446: are no more subnet levels.
447:
448:
449:
450: Mockapetris [Page 8]
451:
452: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
453:
454:
455: 5. YP ISSUES AND DISCUSSION
456:
457: The term "Yellow Pages" is used in almost as many ways as the term
458: "domain", so it is useful to define what is meant herein by YP. The
459: general problem to be solved is to create a method for creating
460: mappings from one kind of identifier to another, often with an
461: inverse capability. The traditional methods are to search or use a
462: precomputed index of some kind.
463:
464: Searching is impractical when the search is too large, and
465: precomputed indexes are possible only when it is possible to specify
466: search criteria in advance, and pay for the resources necessary to
467: build the index. For example, it is impractical to search the entire
468: domain tree to find a particular address RR, so we build the IN-
469: ADDR.ARPA YP. Similarly, we could never build an Internet-wide index
470: of "hosts with a load average of less than 2" in less time than it
471: would take for the data to change, so indexes are a useless approach
472: for that problem.
473:
474: Such a precomputed index is what we mean by YP, and we regard the
475: IN-ADDR.ARPA domain as the first instance of a YP in the DNS.
476: Although a single, centrally-managed YP for well-known values such as
477: TCP-port is desirable, we regard organization-specific YPs for, say,
478: locally defined TCP ports as a natural extension, as are combinations
479: of YPs using search lists to merge the two.
480:
481: In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC
482: 1010], it is clear that there are several mappings which might be of
483: value. For example:
484:
485: <assigned-network-name> <==> <IP-address>
486: <autonomous-system-id> <==> <number>
487: <protocol-id> <==> <number>
488: <port-id> <==> <number>
489: <ethernet-type> <==> <number>
490: <public-data-net> <==> <IP-address>
491:
492: Following the IN-ADDR example, the YP takes the form of a domain tree
493: organized to optimize retrieval by search key and distribution via
494: normal DNS rules. The name used as a key must include:
495:
496: 1. A well known origin. For example, IN-ADDR.ARPA is the
497: current IP-address to host name YP.
498:
499: 2. A "from" data type. This identifies the input type of the
500: mapping. This is necessary because we may be mapping
501: something as anonymous as a number to any number of
502: mnemonics, etc.
503:
504:
505:
506: Mockapetris [Page 9]
507:
508: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
509:
510:
511: 3. A "to" data type. Since we assume several symmetrical
512: mnemonic <==> number mappings, this is also necessary.
513:
514: This ordering reflects the natural scoping of control, and hence the
515: order of the components in a domain name. Thus domain names would be
516: of the form:
517:
518: <from-value>.<to-data-type>.<from-data-type>.<YP-origin>
519:
520: To make this work, we need to define well-know strings for each of
521: these metavariables, as well as encoding rules for converting a
522: <from-value> into a domain name. We might define:
523:
524: <YP-origin> :=YP
525: <from-data-type>:=TCP-port | IN-ADDR | Number |
526: Assigned-network-number | Name
527: <to-data-type> :=<from-data-type>
528:
529: Note that "YP" is NOT a valid country code under [ISO 3166] (although
530: we may want to worry about the future), and the existence of a
531: syntactically valid <to-data-type>.<from-data-type> pair does not
532: imply that a meaningful mapping exists, or is even possible.
533:
534: The encoding rules might be:
535:
536: TCP-port Six character alphanumeric
537:
538: IN-ADDR Reversed 4-octet decimal string
539:
540: Number decimal integer
541:
542: Assigned-network-number
543: Reversed 4-octet decimal string
544:
545: Name Domain name
546:
547: 6. SPECIFICS FOR YP MAPPINGS
548:
549: 6.1. TCP-PORT
550:
551: $origin Number.TCP-port.YP.
552:
553: 23 PTR TELNET.TCP-port.Number.YP.
554: 25 PTR SMTP.TCP-port.Number.YP.
555:
556: $origin TCP-port.Number.YP.
557:
558: TELNET PTR 23.Number.TCP-port.YP.
559:
560:
561:
562: Mockapetris [Page 10]
563:
564: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
565:
566:
567: SMTP PTR 25.Number.TCP-port.YP.
568:
569: Thus the mapping between 23 and TELNET is represented by a pair of
570: PTR RRs, one for each direction of the mapping.
571:
572: 6.2. Assigned networks
573:
574: Network numbers are assigned by the NIC and reported in "Internet
575: Numbers" RFCs. To create a YP, the NIC would set up two domains:
576:
577: Name.Assigned-network-number.YP and Assigned-network-number.YP
578:
579: The first would contain entries of the form:
580:
581: $origin Name.Assigned-network-number.YP.
582:
583: 0.0.0.4 PTR SATNET.Assigned-network-number.Name.YP.
584: 0.0.0.10 PTR ARPANET.Assigned-network-number.Name.YP.
585:
586: The second would contain entries of the form:
587:
588: $origin Assigned-network-number.Name.YP.
589:
590: SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP.
591: ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP.
592:
593: These YPs are not in conflict with the network name support described
594: in the first half of this RFC since they map between ASSIGNED network
595: names and numbers, not those allocated by the organizations
596: themselves. That is, they document the NIC's decisions about
597: allocating network numbers but do not automatically track any
598: renaming performed by the new owners.
599:
600: As a practical matter, we might want to create both of these domains
601: to enable users on the Internet to experiment with centrally
602: maintained support as well as the distributed version, or might want
603: to implement only the allocated number to name mapping and request
604: organizations to convert their allocated network names to the network
605: names described in the distributed model.
606:
607: 6.3. Operational improvements
608:
609: We could imagine that all conversion routines using these YPs might
610: be instructed to use "YP.<local-domain>" followed by "YP." as a
611: search list. Thus, if the organization ISI.EDU wished to define
612: locally meaningful TCP-PORT, it would define the domains:
613:
614: <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.
615:
616:
617:
618: Mockapetris [Page 11]
619:
620: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
621:
622:
623: We could add another level of indirection in the YP lookup, defining
624: the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the
625: YP tree, rather than being the YP tree directly. This would enable
626: entries of the form:
627:
628: IN-ADDR.Netname.YP. PTR IN-ADDR.ARPA.
629:
630: to splice in YPs from other origins or existing spaces.
631:
632: Another possibility would be to shorten the RDATA section of the RRs
633: which map back and forth by deleting the origin. This could be done
634: either by allowing the domain name in the RDATA portion to not
635: identify a real domain name, or by defining a new RR which used a
636: simple text string rather than a domain name.
637:
638: Thus, we might replace
639:
640: $origin Assigned-network-number.Name.YP.
641:
642: SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP.
643: ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP.
644:
645: with
646:
647: $origin Assigned-network-number.Name.YP.
648:
649: SATNET. PTR 0.0.0.4.
650: ARPANET. PTR 0.0.0.10.
651:
652: or
653:
654: $origin Assigned-network-number.Name.YP.
655:
656: SATNET. PTT "0.0.0.4"
657: ARPANET. PTT "0.0.0.10"
658:
659: where PTT is a new type whose RDATA section is a text string.
660:
661: 7. ACKNOWLEDGMENTS
662:
663: Drew Perkins, Mark Lottor, and Rob Austein contributed several of the
664: ideas in this RFC. Numerous contributions, criticisms, and
665: compromises were produced in the IETF Domain working group and the
666: NAMEDROPPERS mailing list.
667:
668:
669:
670:
671:
672:
673:
674: Mockapetris [Page 12]
675:
676: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
677:
678:
679: 8. REFERENCES
680:
681: [HR] Braden, B., editor, "Requirements for Internet Hosts",
682: RFC in preparation.
683:
684: [ISO 3166] ISO, "Codes for the Representation of Names of
685: Countries", 1981.
686:
687: [RFC 882] Mockapetris, P., "Domain names - Concepts and
688: Facilities", RFC 882, USC/Information Sciences Institute,
689: November 1983.
690:
691: Superseded by RFC 1034.
692:
693: [RFC 883] Mockapetris, P.,"Domain names - Implementation and
694: Specification", RFC 883, USC/Information Sciences
695: Institute, November 1983.
696:
697: Superceeded by RFC 1035.
698:
699: [RFC 920] Postel, J. and J. Reynolds, "Domain Requirements", RFC
700: 920, October 1984.
701:
702: Explains the naming scheme for top level domains.
703:
704: [RFC 952] Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
705: Host Table Specification", RFC 952, SRI, October 1985.
706:
707: Specifies the format of HOSTS.TXT, the host/address table
708: replaced by the DNS
709:
710: [RFC 973] Mockapetris, P., "Domain System Changes and
711: Observations", RFC 973, USC/Information Sciences
712: Institute, January 1986.
713:
714: Describes changes to RFCs 882 and 883 and reasons for
715: them.
716:
717: [RFC 974] Partridge, C., "Mail routing and the domain system", RFC
718: 974, CSNET CIC BBN Labs, January 1986.
719:
720: Describes the transition from HOSTS.TXT based mail
721: addressing to the more powerful MX system used with the
722: domain system.
723:
724:
725:
726:
727:
728:
729:
730: Mockapetris [Page 13]
731:
732: RFC 1101 DNS Encoding of Network Names and Other Types April 1989
733:
734:
735: [RFC 997] Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
736: USC/Information Sciences Institute, March 1987
737:
738: Contains network numbers, autonomous system numbers, etc.
739:
740: [RFC 1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
741: 1010, USC/Information Sciences Institute, May 1987
742:
743: Contains socket numbers and mnemonics for host names,
744: operating systems, etc.
745:
746:
747: [RFC 1034] Mockapetris, P., "Domain names - Concepts and
748: Facilities", RFC 1034, USC/Information Sciences
749: Institute, November 1987.
750:
751: Introduction/overview of the DNS.
752:
753: [RFC 1035] Mockapetris, P., "Domain names - Implementation and
754: Specification", RFC 1035, USC/Information Sciences
755: Institute, November 1987.
756:
757: DNS implementation instructions.
758:
759: Author's Address:
760:
761: Paul Mockapetris
762: USC/Information Sciences Institute
763: 4676 Admiralty Way
764: Marina del Rey, CA 90292
765:
766: Phone: (213) 822-1511
767:
768: Email: [email protected]
769:
770:
771:
772:
773:
774:
775:
776:
777:
778:
779:
780:
781:
782:
783:
784:
785:
786: Mockapetris [Page 14]
787:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.