Summary

  • IQUERY reversed the usual DNS message: it supplied a resource record in the Answer section and asked a server to return matching owner names in the Question section.
  • The operation could reveal only names known to the queried server because DNS delegated authority along the name tree, not by arbitrary record values; a correct local result could therefore remain globally incomplete.
  • Exhaustive scans, secondary indexes, awkward caching, large responses and disclosure risk made that uncertainty expensive, while PTR under IN-ADDR.ARPA converted address reversal into an ordinary delegated name query.

The question began inside the answer

Imagine receiving a form whose question box is empty but whose answer box already says A IN 10.1.0.52. The sender asks the recipient to reconstruct every question for which that record would be an answer. That was the striking wire grammar of DNS IQUERY.

RFC 1035 specified a request with opcode 1, an empty Question section and one resource record in the Answer section. The record’s owner name and TTL did not matter. A short root name could stand in for the unknown owner. A successful reply reversed the arrangement: one or more QNAME, QTYPE and QCLASS tuples appeared in the Question section, while the supplied record was adjusted to match the first result.

The construction made a conceptual symmetry visible. A standard query starts with a domain name and asks for a resource. IQUERY started with the resource and asked for domain names. The same DNS envelope could carry both directions.

Yet the symmetry existed only in the message. It did not exist in the distributed authority behind the message. A name could lead a resolver through delegations toward a responsible zone. An arbitrary address, mail exchanger, hardware description or other record value did not carry a corresponding route to every zone that might contain it.

The limitation was written down in 1983

The first DNS specifications did not hide this problem. RFC 882 said that the domain system could not guarantee completeness or uniqueness for inverse queries because it was organized by domain name rather than by host address or another resource type. A resolver seeking a guarantee would need a server known to possess the proper data or would have to ask all servers in the domain of interest.

That is more than a warning about early implementation. It identifies a missing routing rule. Ordinary DNS resolution can ask who is authoritative for a name because delegation is itself expressed in the name tree. IQUERY did not define who was authoritative for a value. The client had to choose a server before it could know whether that server’s view was relevant.

RFC 883 therefore treated inverse queries as environment-sensitive. A resolver might be configured with particular known servers. Such a server could be useful for a bounded administrative dataset. It could not become an oracle for the whole Internet merely because it returned a syntactically successful response.

The crucial distinction is between truth and scope. If a server found three local names containing the requested record, those matches might be entirely true. The response still could not prove that a fourth matching name did not exist in another zone the server lacked. Local correctness did not carry global authority.

“Which the name server knows” was the real contract

RFC 1035 made the boundary unusually explicit: a response identified all matching names which the name server knows. Since no server knew the entire domain space, the response could never be assumed complete. The specification relegated IQUERY to database management and debugging and rejected it as a general way to map host addresses to host names.

That phrase changes how every outcome must be read. Zero names meant that the chosen server found no match in its available data. It did not mean that DNS contained no match. One name established a visible association, not uniqueness. Many names might be a full local list, a cached accident or only a slice of a larger distributed set.

Negative evidence was especially weak. Standard DNS can return an authoritative negative answer within a named zone because the queried name locates the relevant authority. IQUERY had no equivalent boundary around “all records with this value.” Proving absence would require knowledge of every place where the value could appear.

The operation thus exposed a durable systems principle. A search result is not merely a collection of matching rows. Its strength depends on the declared universe that was searched, who controls that universe, and whether omitted regions can be located. Without those facts, a complete-looking list is only a view.

Reversing a database created a second database

The operational cost followed from the same mismatch. A DNS server naturally organized records under owner names because standard queries arrived with names. To answer IQUERY efficiently, it needed another access path keyed by record content.

RFC 883 described per-zone inversion tables. Each zone update could require rebuilding the relevant inversions. RFC 1035 allowed exhaustive search or a separate database indexed by primary-record values. Neither choice was free. A scan spent time at request time; an index spent memory and maintenance effort continuously.

The index also multiplied semantic work. Record data are typed. Address bytes, domain names inside records and character strings have different comparison rules. RFC 1035 urged case-insensitive comparison where possible but acknowledged that a server might hold character data whose internal meaning it did not know. “Find this value” was not a universal byte-equality operation.

Demand and cost were divided badly. A remote requester could submit a small value. The server bore the scan, index lookup, result assembly and transmission cost. The requester did not demonstrate that the search served the zone operator or that it was bounded to a manageable result.

The answer resisted ordinary caching

DNS scale depends heavily on reusable, time-bounded answers. IQUERY results did not fit that machinery cleanly. RFC 1035 warned that they could not be cached through the same mechanism as ordinary query replies.

The reason was not merely packet format. A returned match represented one relation selected by value, while the owner name could have several records of the same type. An inverse result for one address of a multihomed host could create the false impression that the visible address was the complete set. Cache entries indexed by the reconstructed question would lose the search scope and omission conditions that produced them.

Caching also could not repair missing authority. Repeating a local answer at more resolvers makes it cheaper to see; it does not make it globally complete. Distribution can amplify a claim without increasing its evidentiary boundary.

This separated IQUERY from the architecture that made ordinary DNS practical. Normal queries aligned lookup key, delegation, authority, cache key and TTL around a name. IQUERY reused the message but broke that alignment. Every optimization had to remember that the result described one server’s knowledge at one moment.

PTR made reversal a naming problem

The successful alternative did not teach DNS to search every record value. It named the reverse key. RFC 1034 describes IN-ADDR.ARPA, where the octets of an IPv4 address appear in reverse order beneath a special domain. A PTR record at that name can point to a domain name.

For address 10.1.0.52, the resolver can construct a name under the reverse tree and perform an ordinary query. The hierarchy can delegate portions of that tree. The resolver can find authoritative servers, cache the named RRset under its TTL and interpret a bounded negative result within the zone.

The extra indirection is the architectural achievement. PTR does not promise that every address has a record, that one address has only one name, or that a returned name authenticates a machine. It does something narrower and more defensible: it places the reverse claim under an owner name for which DNS already has authority-routing rules.

IQUERY asked the distributed system to discover an unknown index. PTR required the party responsible for reverse space to publish an explicit record at a predictable name. Search became retrieval; a global aspiration became a delegated claim.

Large answers turned ambiguity into exposure

By 2002, the operational verdict was clear enough for RFC 3425 to retire IQUERY. The document records limited implementation and common disablement where old support existed. It cites bugs in rarely exercised code, database burden and unwanted disclosure of large portions of zones.

Some values could match enormous sets. Asking for every domain delegated to a large provider’s nameserver might yield tens of thousands of tuples and megabytes of response data. A small request could therefore trigger expensive computation and an exceptional reply, creating denial-of-service leverage.

Inverse MX probes presented another problem. A server might reveal a wide collection of names merely because they shared mail infrastructure. The records might not be secret individually, yet IQUERY changed the cost of assembling them. Data publication under many owner names did not automatically authorize an unbounded value-indexed catalogue.

The same operation was weak for the honest client and attractive to the abusive one. An honest client could not know that the result was complete. An attacker did not need completeness; resource consumption and bulk enumeration could be valuable even from one server’s local view.

Retirement preserved the opcode’s history

RFC 3425 did not silently reuse opcode 1. It marked IQUERY obsolete, required the old section of RFC 1035 to be treated as superseded, and said servers should answer such requests with Not Implemented. IANA was asked to retire the opcode permanently.

That decision is protocol hygiene. A dormant number can look like free space, but reuse would make old implementations interpret new traffic through the abandoned semantics. Permanent retirement keeps the meaning legible while ending the expectation of service.

The RFC also noted that no known clients depended on IQUERY for a meaningful service, while PTR reverse mapping had served the community for years. Retirement followed the absence of a working dependency, not merely an aesthetic preference for newer syntax.

Security proofs reinforced the decision. Securing IQUERY replies with DNSSEC would be extremely difficult without signing results on the fly. DNSSEC can authenticate named RRsets and denial within signed name structures. An arbitrary search result additionally implies that no matching record was omitted from the searched universe—a universe IQUERY never knew how to define globally.

The server was a witness, not the namespace

IQUERY’s history can be read as a small lesson about institutional claims. A server participates in DNS and may hold authoritative zones, cached data and accurate records. Those facts make it a witness for defined portions of the namespace. They do not make it the principal for every name that happens to share a value.

Heng Lu’s notes separate presence from mandate and database administration from authority over the thing recorded. At protocol scale, IQUERY reveals the same boundary. Possessing a searchable copy gives the power to report that copy. It does not supply authority over absent data or permission to treat a local list as a universal decision.

The repair was not to create a larger central catalogue. It was to keep the common layer small: names, delegations, record types, cache lifetimes and explicit reverse-tree records. Participants could publish claims inside bounded zones, and resolvers could follow the same interoperable rules without granting one server omniscience.

Evidence limits

The five RFCs establish the specified message, its limitations, the name-tree alternative and the standards decision to obsolete it. They do not measure current opcode-1 traffic, enumerate every historical implementation or prove that no private diagnostic tool still emits such packets.

NOTIMP is the expected standards response, not evidence that a server never parsed the request. A timeout does not prove IQUERY support or refusal. A response does not prove global completeness. Current behavior requires packet captures, server configuration and implementation-specific evidence.

PTR likewise must not be promoted into identity proof. Forward and reverse records can disagree; several names may point around the same address; administrators can omit or misconfigure data. The lesson is about locating authority for a claim, not guaranteeing that every published claim is correct.

IQUERY failed because it offered a direction of inquiry without a direction of authority. The wire could reverse a mapping in one bit. The distributed system could not reverse its delegations so cheaply. DNS became more dependable when it retired the seductive question and required reverse claims to live under names.

Sources