RFC 1788 (rfc1788) - Page 2 of 7
ICMP Domain Name Messages
Alternative Format: Original Text Document
RFC 1788 ICMP Domain Name April 1995
Table of Contents
1. Introduction .......................................... 2
1.1 Direct Query .................................... 3
1.2 Multicast ....................................... 3
1.3 Domain Names .................................... 3
1.4 Messages ........................................ 4
2. Domain Name Request ................................... 4
3. Domain Name Reply ..................................... 5
SECURITY CONSIDERATIONS ...................................... 6
REFERENCES ................................................... 6
ACKNOWLEDGEMENTS ............................................. 7
AUTHOR'S ADDRESS ............................................. 7
1. Introduction
The Domain Name System (DNS) is described in [RFC-1034]. The IN-ADDR
domain of the DNS is specified [RFC-1035] to perform address to
domain name resolution, and to facilitate queries to locate all
gateways (routers) on a particular network in the Internet.
Neither function has been remarkably successful. The IN-ADDR domain
is not reliably populated.
As multiple routers were used at boundaries and within networks, the
IN-ADDR mechanism was found to be inadequate. The location of
routers by hosts is now performed using "ICMP Router Discovery
Messages" [RFC-1256].
As network numbers migrated to "classless" routing and aggregation,
the IN-ADDR delegation granularity has fragmented, and requires
overlapping administration. The "reverse" IN-ADDR administration
frequently does not follow the same delegation as the "forward"
domain name tree. This structure is not amenable to cooperative
secure updating of the DNS.
As application servers have appeared which require the Domain Name
for user interaction and security logging, the IN-ADDR servers have
been inundated with queries. This produces long user visible pauses
at the initiation of sessions.
Simpson