Summary

  • RFC 3425 permanently retired DNS opcode 1, IQUERY, and said a name server receiving it should answer Not Implemented; that reply concerned the operation, not the existence of any name.
  • Reverse DNS survived through explicit PTR records in delegated namespaces. An IQUERY refusal, NXDOMAIN, NODATA, a PTR answer and a DNSSEC validation result are different receipts with different authorities.

The message failed before the name was adjudicated

Imagine an old diagnostic tool sending a DNS packet with opcode 1. The server answers NOTIMP. A dashboard translates that into “no reverse name.” The sentence sounds economical, but it merges two decisions that the protocol kept apart.

The first decision is whether the server performs IQUERY at all. The second is what the DNS namespace says about a particular owner name and record type. RFC 3425, published in November 2002, closed the first route. It made IQUERY obsolete, replaced the relevant text of RFC 1035 and told servers to return Not Implemented when that opcode arrived.

That is a successful standards response to a retired operation. The server has not necessarily searched for a name. It has not returned NXDOMAIN. It has not proved that an explicit PTR record is absent. It has identified a question that no longer belongs on the wire.

IQUERY tried to invert a database

The original mechanism in RFC 1035 did not ask the reverse DNS tree for a PTR owner name. The requester placed a resource-record value in the answer section and asked the contacted server to return matching type, name and class tuples in the question section.

That shape made the server's local database the search surface. To answer generally, a server might scan its records or maintain another index keyed by values. RFC 1035 already described the work as potentially arduous. RFC 3425 sharpened the operational consequence: a server authoritative for millions of names could face an expensive search and an exceptionally large response.

The memo offered a telling example. Asking for every domain delegated to one large provider's nameserver might yield tens of thousands of tuples. The query was not merely “backwards.” It could turn a compact input into an enormous enumeration, exercise code that operators rarely used and expose names in bulk.

One contacted server could not refer the question onward

Ordinary DNS resolution derives authority from the namespace. If a resolver does not yet have the answer, referrals can move it toward the servers responsible for the name. IQUERY lacked that useful direction. Its answer depended on the contents of the particular server that received it.

A value could exist elsewhere while the contacted server knew nothing about it. The server could refuse the operation while holding related data. Two servers could legitimately produce different inverse-search results because their local databases differed. The result was unsuitable as a global statement about “all names associated with this value.”

This is the authority boundary hidden by the word inverse. A database inversion at one node is not the same thing as a lookup in a delegated reverse namespace.

PTR made the reverse question explicit

The operational alternative was already familiar: encode reverse mapping as ordinary DNS data. IPv4 address octets are represented under in-addr.arpa; a client asks for a PTR record at a precise owner name. RFC 1033, RFC 1034 and RFC 1035 document the surrounding DNS model, while RFC 2317 shows that address blocks smaller than a /24 require explicit delegation machinery rather than magical database inversion.

This did not make reverse DNS complete or infallible. It made the question routable and administratively scoped. A PTR response can be tied to an owner name, a delegation path, responding authority, TTL and—where deployed—DNSSEC validation. An absent record can be expressed through DNS's negative-answer machinery instead of inferred from refusal of another operation.

Four replies that must not share one label

NOTIMP says the responder does not implement the requested operation. NXDOMAIN says the queried owner name does not exist within the relevant DNS semantics. NODATA describes an existing name without the requested type. A timeout says no acceptable response arrived before the observation window closed.

Those states lead to different next actions. After NOTIMP for IQUERY, a diagnostic client should form the appropriate PTR question. After NXDOMAIN, it should preserve authority and negative-caching context. After a validation failure, it should not silently relabel the result as ordinary absence. After timeout, it should retain transport and retry evidence.

RFC 8020 later refined how resolvers use authoritative NXDOMAIN. It did not turn an opcode refusal into NXDOMAIN. RFC 8499 helps keep modern DNS terminology precise. The distinction remains procedural and evidentiary, not cosmetic.

Retirement preserved the number

RFC 3425 changed the definition of opcode 1 to “IQUERY (obsolete)” and asked that it be permanently retired. The IANA DNS Parameters registry and RFC 6895 preserve that history.

Permanent retirement is not the same as an unassigned hole. Reusing the number would make an old packet ambiguous: did it carry the retired meaning or the new one? Reservation protects interpreters from that collision. It records a negative capability—what new protocol work must not claim.

Nor does registry status prove that every old parser vanished. Specification, implementation, configuration, received packet and observed response remain separate layers. The registry states the intended meaning; a packet capture and implementation record state what happened at a particular boundary.

DNSSEC could authenticate namespace data, not rescue arbitrary inversion

RFC 3425 observed that securing IQUERY answers with DNSSEC would be extremely difficult without signing on the fly. That follows from the query's shape: it asked the server to synthesize a potentially large reverse index result, not retrieve a pre-existing RRset at a named owner.

RFC 4033, RFC 4034 and RFC 4035 define DNSSEC's architecture, records and validation behavior around explicit DNS data. Signed PTR data or authenticated denial can support a conclusion within that namespace. A NOTIMP reply to IQUERY does not inherit that conclusion merely because it arrived in a DNS message.

Authentication still stops short of identity. A validated PTR proves that the signed zone asserted a mapping at the validated time and policy state. It does not by itself prove address allocation, control of the host, forward-confirmed reverse DNS, reachability, application authentication or service success.

The useful refusal

Protocols often celebrate successful answers. RFC 3425 preserved a different kind of success: refusing an obsolete question while keeping the explicit namespace available. The refusal protected server resources, reduced exposure through poorly exercised enumeration code and forced reverse lookups onto a path with a clearer administrative owner.

The durable lesson is not that errors are secretly answers. It is that an error has a subject. NOTIMP speaks about an operation. NXDOMAIN speaks about a name. A PTR RRset speaks about data at an owner name. DNSSEC speaks about validation of that data or denial. Good operations keep those subjects intact.

Sources and limits

The primary record is preserved in RFC Editor HTML, plain text, the RFC Editor information page, the IETF Datatracker document page, its history and references, plus the RFC Editor errata search. DNS context comes from RFC 1033, RFC 1034, RFC 1035, RFC 2317, RFC 6895, RFC 8499, RFC 4033, RFC 4034, RFC 4035, RFC 8020 and the IANA DNS Parameters registry. The separation of symbolic specification from observed operation follows Heng Lu's essays on reality layers and running code as primary.

These sources support protocol history and defined semantics. They do not provide a current deployment census, a named vulnerable server, a measured attack, complete PTR coverage, host identity, reachability, authorization or application outcome.