home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1700s / rfc1788.txt < prev    next >
Text File  |  1995-04-12  |  12KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         W. Simpson
  8. Request for Comments: 1788                                    Daydreamer
  9. Category: Experimental                                        April 1995
  10.  
  11.  
  12.                        ICMP Domain Name Messages
  13.  
  14. Status of this Memo
  15.  
  16.    This document defines an Experimental Protocol for the Internet
  17.    community.  This does not specify an Internet standard of any kind.
  18.    Discussion and suggestions for improvement are requested.
  19.    Distribution of this memo is unlimited.
  20.  
  21. IESG Note:
  22.  
  23.    An Internet Engineering Steering Group comment from the co-Area
  24.    Director for IPng:  Please note well that this memo is an individual
  25.    product of the author.  It presents one view of the IN-ADDR
  26.    mechanism, motivated by discussion in the IPNG WG of the difficulty
  27.    of secure, dynamic update of the reverse tree.  Other IETF discussion
  28.    and ongoing standards work on this area will be found in the IP Next
  29.    Generation (ipngwg), DNS IXFR, Notification, and Dynamic Update
  30.    (dnsind), DNS Security (dnssec) working groups.
  31.  
  32. Abstract
  33.  
  34.    This document specifies ICMP messages for learning the Fully
  35.    Qualified Domain Name associated with an IP address.
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Simpson                                                         [Page 1]
  59.  
  60. RFC 1788                    ICMP Domain Name                  April 1995
  61.  
  62.  
  63. Table of Contents
  64.  
  65.      1.     Introduction ..........................................    2
  66.         1.1       Direct Query ....................................    3
  67.         1.2       Multicast .......................................    3
  68.         1.3       Domain Names ....................................    3
  69.         1.4       Messages ........................................    4
  70.  
  71.      2.     Domain Name Request ...................................    4
  72.  
  73.      3.     Domain Name Reply .....................................    5
  74.  
  75.      SECURITY CONSIDERATIONS ......................................    6
  76.      REFERENCES ...................................................    6
  77.      ACKNOWLEDGEMENTS .............................................    7
  78.      AUTHOR'S ADDRESS .............................................    7
  79.  
  80. 1.  Introduction
  81.  
  82.    The Domain Name System (DNS) is described in [RFC-1034].  The IN-ADDR
  83.    domain of the DNS is specified [RFC-1035] to perform address to
  84.    domain name resolution, and to facilitate queries to locate all
  85.    gateways (routers) on a particular network in the Internet.
  86.  
  87.    Neither function has been remarkably successful.  The IN-ADDR domain
  88.    is not reliably populated.
  89.  
  90.    As multiple routers were used at boundaries and within networks, the
  91.    IN-ADDR mechanism was found to be inadequate.  The location of
  92.    routers by hosts is now performed using "ICMP Router Discovery
  93.    Messages" [RFC-1256].
  94.  
  95.    As network numbers migrated to "classless" routing and aggregation,
  96.    the IN-ADDR delegation granularity has fragmented, and requires
  97.    overlapping administration.  The "reverse" IN-ADDR administration
  98.    frequently does not follow the same delegation as the "forward"
  99.    domain name tree.  This structure is not amenable to cooperative
  100.    secure updating of the DNS.
  101.  
  102.    As application servers have appeared which require the Domain Name
  103.    for user interaction and security logging, the IN-ADDR servers have
  104.    been inundated with queries.  This produces long user visible pauses
  105.    at the initiation of sessions.
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Simpson                                                         [Page 2]
  115.  
  116. RFC 1788                    ICMP Domain Name                  April 1995
  117.  
  118.  
  119. 1.1.  Direct Query
  120.  
  121.    This document proposes that each unicast address be queried directly
  122.    for its corresponding Domain Name.  This has the advantages that the
  123.    naming is under the same administration as the address assignment,
  124.    and the queries are distributed in the same fashion as IP routing.
  125.    In effect, the routing is used to index the database.
  126.  
  127. 1.2.  Multicast
  128.  
  129.    Only a few well-known multicast addresses are populated in the IN-
  130.    ADDR domain.  The ephemeral nature of most multicast addresses is not
  131.    conducive to cooperative secure updating of the DNS.
  132.  
  133.    However, the technique described here is not useful for multicast
  134.    addresses.  A query to a multicast address could result in a storm of
  135.    replies.  Most multicast groups are not named, or the member nodes
  136.    are not configured with the name.
  137.  
  138.    The IN-ADDR method SHOULD continue to be used for reverse lookup of
  139.    well-known multicast addresses in the range 224.0.0.0 to
  140.    224.0.255.255.  Other multicast addresses are an issue for futher
  141.    study.
  142.  
  143. 1.3.  Domain Names
  144.  
  145.    Each Domain Name is expressed as a sequence of labels.  Each label is
  146.    represented as a one octet length field, followed by that number of
  147.    octets.  Since every Domain Name ends with the null label of the
  148.    root, a Domain Name is terminated by a length byte of zero.  The most
  149.    significant two bits of every length octet must be '00', and the
  150.    remaining six bits of the length field limit the label to 63 octets
  151.    or less.
  152.  
  153.    When the most significant two bits of the length octet are '11', the
  154.    length is interpreted as a 2 octet sequence, indicating an offset
  155.    from the beginning of the message (Type field).  Further details are
  156.    described in [RFC-1035] "Message Compression".
  157.  
  158.    To simplify implementations, the total length of a Domain Name
  159.    (including label octets and label length octets) is restricted to 255
  160.    octets or less.
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Simpson                                                         [Page 3]
  171.  
  172. RFC 1788                    ICMP Domain Name                  April 1995
  173.  
  174.  
  175. 1.4.  Messages
  176.  
  177.    The datagram format and basic facilities are already defined for ICMP
  178.    [RFC-792].
  179.  
  180.    Up-to-date values of the ICMP Type field are specified in the most
  181.    recent "Assigned Numbers" [RFC-1700].  This document concerns the
  182.    following values:
  183.  
  184.        37  Domain Name Request
  185.        38  Domain Name Reply
  186.  
  187. 2.  Domain Name Request
  188.  
  189.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  190.    |     Type      |     Code      |          Checksum             |
  191.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  192.    |           Identifier          |        Sequence Number        |
  193.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  194.  
  195.  
  196.    Type             37
  197.  
  198.    Code             0
  199.  
  200.    Checksum         The ICMP Checksum.
  201.  
  202.    Identifier       If Code is zero, a value to aid in matching requests
  203.                     and replies.  For example, it might be used like a
  204.                     port in TCP or UDP to identify a session.  May be
  205.                     zero.
  206.  
  207.    Sequence Number  If Code is zero, a value to aid in matching requests
  208.                     and replies.  For example, the number might be
  209.                     incremented on each request sent.  May be zero.
  210.  
  211.    A separate Domain Name Request is used for each IP Destination
  212.    queried.
  213.  
  214.    An ICMP Domain Name Request received with a broadcast or multicast
  215.    Destination MUST be silently discarded.
  216.  
  217.    On receipt of an ICMP error message, the implementations MAY attempt
  218.    to resolve the Domain Name using the IN-ADDR method.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Simpson                                                         [Page 4]
  227.  
  228. RFC 1788                    ICMP Domain Name                  April 1995
  229.  
  230.  
  231. 3.  Domain Name Reply
  232.  
  233.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  234.    |     Type      |     Code      |          Checksum             |
  235.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  236.    |           Identifier          |        Sequence Number        |
  237.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  238.    |                          Time-To-Live                         |
  239.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  240.    |   Names ...
  241.    +-+-+-+-+-+-+-+-
  242.  
  243.  
  244.    Type             38
  245.  
  246.    Code             0
  247.  
  248.    Checksum         The ICMP Checksum.
  249.  
  250.    Identifier       Copied from the request.
  251.  
  252.    Sequence Number  Copied from the request.
  253.  
  254.    Time-To-Live     The number of seconds that the name may be cached.
  255.                     For historic reasons, this value is a signed 2s-
  256.                     complement number.
  257.  
  258.    Names            zero or more Fully Qualified Domain Names.  The
  259.                     length of this field is determined from the total
  260.                     length of the datagram.
  261.  
  262.                     When no names are known, the field is eliminated
  263.                     (zero length), but the Reply is sent as an
  264.                     authoritative indication that no name is known.
  265.  
  266.                     When more than one name is known, all such names
  267.                     SHOULD be listed.
  268.  
  269.                     Any name which cannot entirely fit within the Reply
  270.                     MTU is not sent.
  271.  
  272.    The IP Source in a Reply MUST be the same as the IP Destination of
  273.    the corresponding Request message.
  274.  
  275.    Every host and router MUST implement an ICMP Domain Name server
  276.    function that receives Domain Name Requests and sends corresponding
  277.    Domain Name Replies.
  278.  
  279.  
  280.  
  281.  
  282. Simpson                                                         [Page 5]
  283.  
  284. RFC 1788                    ICMP Domain Name                  April 1995
  285.  
  286.  
  287.    A host SHOULD also implement an application- layer interface for
  288.    sending a Domain Name Request and receiving a Domain Name Reply, for
  289.    diagnostic purposes.
  290.  
  291. Security Considerations
  292.  
  293.    A primary purpose of this specification is to provide a mechanism for
  294.    address to name resolution which is more secure than the IN-ADDR
  295.    reverse tree.  This mechanism is amenable to use of the IP Security
  296.    Protocols for authentication and privacy.
  297.  
  298.    Although the routing infrastructure to the Destination does not
  299.    provide security in and of itself, it is as least as reliable as
  300.    delivery of correspondence for the other sessions with the same peer.
  301.  
  302.    A DNS cryptographic signature, located by using the reply in the
  303.    forward DNS direction, can be used to verify the reply itself.
  304.  
  305. References
  306.  
  307.    [RFC-792]
  308.             Postel, J., "Internet Control Message Protocol", STD 5,
  309.             RFC 792, USC/Information Sciences Institute, September
  310.             1981.
  311.  
  312.    [RFC-1034]
  313.             Mockapetris, P., "Domain Names - Concepts and Facilities",
  314.             STD 13, RFC 1034, USC/Information Sciences Institute,
  315.             November 1987.
  316.  
  317.    [RFC-1035]
  318.             Mockapetris, P., "Domain Names - Implementation and
  319.             Specification", STD 13, RFC 1035, USC/Information
  320.             Sciences Institute, November 1987.
  321.  
  322.    [RFC-1256]
  323.             Deering, S., Editor, "ICMP Router Discovery Messages",
  324.             RFC 1256, Xerox PARC, September 1991.
  325.  
  326.    [RFC-1700]
  327.             Reynolds, J., and J. Postel, "ASSIGNED NUMBERS", STD 2,
  328.             RFC 1700, USC/Information Sciences Institute, October 1994.
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Simpson                                                         [Page 6]
  339.  
  340. RFC 1788                    ICMP Domain Name                  April 1995
  341.  
  342.  
  343. Acknowledgements
  344.  
  345.    The DNSIND and IPng Working Groups contributed substantial amounts of
  346.    discussion.
  347.  
  348.    Additional comments should be submitted to the
  349.    namedroppers@internic.net mailing list.
  350.  
  351. Author's Address
  352.  
  353.    Questions about this memo can also be directed to:
  354.  
  355.       William Allen Simpson
  356.       Daydreamer
  357.       Computer Systems Consulting Services
  358.       1384 Fontaine
  359.       Madison Heights, Michigan  48071
  360.  
  361.       Bill.Simpson@um.cc.umich.edu
  362.           bsimpson@MorningStar.com
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Simpson                                                         [Page 7]
  395.  
  396.