Browse Prior Art Database

ICMP Domain Name Messages (RFC1788)

IP.com Disclosure Number: IPCOM000004041D
Original Publication Date: 1995-Apr-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 7 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

W. Simpson: AUTHOR

Related Documents

10.17487/RFC1788: DOI

Abstract

This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 31% of the total text.

Network Working Group W. Simpson Request for Comments: 1788 Daydreamer Category: Experimental April 1995

ICMP Domain Name Messages

Status of this Memo

This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

IESG Note:

An Internet Engineering Steering Group comment from the co-Area Director for IPng: Please note well that this memo is an individual product of the author. It presents one view of the IN-ADDR mechanism, motivated by discussion in the IPNG WG of the difficulty of secure, dynamic update of the reverse tree. Other IETF discussion and ongoing standards work on this area will be found in the IP Next Generation (ipngwg), DNS IXFR, Notification, and Dynamic Update (dnsind), DNS Security (dnssec) working groups.

Abstract

This document specifies ICMP messages for learning the Fully Qualified Domain Name associated with an IP address.

Simpson [Page 1]

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 [Page 2]

RFC 1788 ICMP Domain Name April 1995

1.1. Dire...

Processing...
Loading...