Summary

  • RFC 1788 proposed asking each unicast endpoint directly for its domain name, using ICMP types 37 and 38 instead of depending only on a separately administered reverse-DNS tree.
  • Its identifiers, sequence number, source-address rule, TTL and negative reply scoped one answer; they did not prove a person's identity, ownership, route authorisation or universal trust.
  • RFC 6918 later deprecated the messages after finding that they had never been widely implemented or deployed, making adoption—not the word MUST—the decisive historical fact.

The status change tells the story

The current IANA ICMP registry gives types 37 and 38 a short description: Domain Name Request and Domain Name Reply, both deprecated. That compact table is the end of a longer argument. RFC 1788 introduced the pair in April 1995 and required every host and router to implement the server function. RFC 6918, published on the Standards Track in 2013, said the messages had never been widely implemented or deployed, formally deprecated them and obsoleted RFC 1788.

The later document did not discover a malformed field. It recorded a missing ecosystem. A protocol can have assigned numbers, normative language and a complete packet diagram while lacking the population of interoperable systems that would make an application safe to depend on it.

That distinction matters because RFC 1788 was responding to a real defect. It was not a frivolous proposal defeated by a perfect incumbent. Reverse address-to-name information was often incomplete, and classless addressing had made delegation of the reverse tree differ from the forward naming hierarchy. Applications that tried to display or log a name could wait through long DNS failures. The problem existed. The proposed authority path did not become common infrastructure.

Reverse DNS had two administrative seams

In the Domain Name System, forward names and reverse address mappings do not necessarily follow the same delegation. A name may sit beneath an organisation's ordinary domain while the corresponding reverse zone follows the allocation of address space. RFC 1788 observed that IN-ADDR data was not reliably maintained and that CIDR made the administrative mismatch more visible.

The memo's answer was architectural: ask the address itself. Send an ICMP Domain Name Request to one unicast destination and receive a Domain Name Reply from that destination. Naming administration could then follow address assignment, while routing would “index” the database by delivering the request to the machine using the address.

This moved the seam; it did not abolish administration. The endpoint still needed software that knew what names to report. Operators still needed policy that allowed the messages. Applications still needed to interpret freshness and trust. Routing could locate an answering interface, but the route was not a certificate for the answer.

One address, one request, one bounded reply

RFC 1788 assigned type 37 to the request and type 38 to the reply. The identifier and sequence number were copied into the response so a requester could associate an answer with a query; the memo allowed either field to be zero. A distinct request went to each IP destination.

The reply source address had to equal the destination address in the request. That was an important scoping rule. A query sent to address A could not be satisfied by an otherwise convenient reply sourced from address B. The rule connected the packet exchange to the addressed interface.

It did not connect the interface to every identity an observer might want. It did not prove which human operated the machine, which legal entity owned it, whether the route was authorised, whether a forward DNS name pointed back, or whether the software telling the truth today would tell the same truth tomorrow. Those claims need separate evidence.

RFC 792 had already described the wider ICMP boundary. ICMP reports problems and control information, but it does not make IP reliable; neither the original datagram nor an ICMP response is guaranteed to return. A well-formed direct name reply was therefore a receipt for one exchange, not a global availability promise.

No name was still supposed to be an answer

The most revealing response contained nothing. RFC 1788 allowed zero or more fully qualified domain names. If the endpoint knew no name, it still had to reply. That empty result was described as an authoritative indication that no name was known.

The word “authoritative” can be overread. Within the proposed protocol, it distinguished a deliberate negative answer from silence. An application would not need to wait and wonder whether the request had disappeared. But it did not turn the negative result into a DNSSEC-signed denial, a proof of ownership or a permanent statement. It was the endpoint's bounded answer at that moment.

If more than one name was known, all should be listed. Yet packet size imposed a physical limit: a name too large to fit the reply MTU was omitted. The resulting set could therefore be intentionally complete according to the endpoint and still incomplete on the wire. Format and path constraints were part of the evidence.

The reply also carried a time to live. It was a signed two's-complement value for historical reasons. A TTL told a consumer how long the received naming information might be reused. It could not prove that the name was semantically correct, that the answering software was authorised to speak for an organisation, or that deployment existed beyond this one responding node.

Multicast exposed the cost of universality

The protocol was expressly unicast. Requests sent to a broadcast or multicast destination had to be silently discarded. If every listening machine answered a group-addressed query, a single packet could provoke a reply storm.

This rule reveals the operational cost hidden inside “every host and router.” Universal implementation did not mean universal response to every delivery mode. The shared mechanism needed a sharply limited trigger: a separate query to a single address, a single reply path, and silence when fan-out could multiply traffic.

Even within that boundary, universal server implementation was an ambitious dependency. A useful global service required operating systems, routers, embedded devices, firewalls, diagnostic tools and applications to converge. RFC 1788 also said a host should provide an application interface to the mechanism for diagnostic use. The RFC could specify all that behaviour, but it could not ship the code or negotiate all those local policies.

Security was proposed, not supplied by routing

RFC 1788 argued that asking the endpoint could be more secure than relying on IN-ADDR data. It noted that IPsec could protect the exchange and suggested that a cryptographic signature obtained from forward DNS might authenticate a reply. These were directions for securing the mechanism, not properties supplied automatically by the basic request and reply.

The memo itself made the decisive caveat: routing is not security. Delivery to an address establishes where the network sent a packet under then-current routing state. It does not establish rightful control of the prefix, trustworthy software, lawful ownership or a stable institutional identity.

That boundary grew more explicit in RFC 4620, the later Experimental IPv6 Node Information specification. It limited the mechanism to diagnostics, debugging and network management while leaving DNS globally authoritative. It introduced a nonce, default scope restrictions, privacy guidance and rate limiting. It warned that learned information should not support security decisions without additional authentication and required a zero TTL for node-name answers.

RFC 4620 cited the earlier IPv4 proposal, but it was not RFC 1788 quietly surviving under a new number. Its narrowed purpose and safeguards show how much work was needed merely to make direct node information defensible as a diagnostic tool.

A mandatory sentence met a voluntary network

The sharpest sentence in RFC 1788 said that every host and router must implement the server function. Read as specification language, it left no optional server class. Read as a prediction of the Internet, it failed.

RFC 6918 was careful about the failure. It did not say that nobody had ever written an implementation. It said the messages had never been widely implemented or deployed. That is the accurate claim. The record does not give one universal cause, and it should not be rewritten as a morality tale about foolish authors or malicious operators.

Several structural frictions are visible without inventing motives. The proposal needed a new code path across a vast and heterogeneous endpoint population. Firewalls and middleboxes could filter unfamiliar ICMP types. Applications already had DNS interfaces. The direct answer introduced its own authentication, privacy and naming questions. A mechanism meant to avoid delay could not be treated as dependable until enough nodes answered it, yet nodes and applications had little reason to invest until dependable use existed.

Deprecation then changed the incentive again. RFC 6918 noted that marking the types deprecated could support filtering. Once the registry tells operators that a message is obsolete, accepting or generating it becomes harder to justify. The standards record did not merely describe the deployment equilibrium; it helped close the remaining path.

Running code was the real ballot

Heng Lu's Running-Code Primacy supplies a useful contemporary lens. The Internet's coordination legitimacy begins with voluntary technical adoption: a proposal earns operational authority when independently controlled systems implement it and continue to interoperate. Publication is evidence that a design was specified, not evidence that the world adopted it.

RFC 1788 makes the distinction unusually measurable. The symbolic layer contained an RFC number, allocated ICMP types and a universal normative requirement. The operational layer contained too few deployed responders to sustain a common service. In 2013, the symbolic layer was revised to match the operational one.

The Minimum Initial Specification, Localized Future Decision and Voluntary Adoption framework adds a second question. Was the required common contract small and useful enough that local implementers would choose it? RFC 1788's packet format was compact, but its deployment contract was not: universality depended on almost every host and router exposing a new answer surface. A small packet is not necessarily a small coordination burden.

This is a retrospective comparison, not proof that the 1995 authors shared Heng Lu's terminology. It also does not mean standards should contain no MUST. Normative requirements are essential inside an adopted protocol. The category error is treating the strength of the word as proof that the adoption boundary has already been crossed.

The history ends with a modest rule. A direct endpoint answer can be useful evidence. It can reduce one administrative dependency and produce a cleaner negative result than silence. But an Internet-wide service is not created by declaring every endpoint responsible. It exists only after implementations answer, networks carry the messages, applications preserve the limits of the reply, and operators continue to choose the mechanism. In that contest, running code did not violate RFC 1788. It decided whether RFC 1788 had a world to govern.

Sources