Summary

  • RFC 3467 argued that DNS was built to resolve exact, unique network identifiers, not to infer a person, product or resource from an ambiguous human query.
  • Its proposed search layer was an architectural separation, not a standard or deployment: discovery could produce candidates, while DNS retained the narrower job of resolving the selected exact name.

The clerk needed a key, not a description

Imagine asking a clerk for “the café near the station with the blue sign.” A good directory may ask which station, tolerate a misspelling, rank several candidates and show context. A DNS resolver does something more austere. Give it a fully formed name and a record type, and it follows a distributed hierarchy to find the corresponding data. It is not meant to decide which café the speaker had in mind.

RFC 3467, John Klensin's Informational memo on the role of the Domain Name System, made that contrast in 2003. Its abstract was unusually careful: the document reviewed the system's original purpose, compared it with newer demands, and outlined an alternative framework. The framework was not a proposed solution. The history was also presented as a reconstruction, because many early design motives had not been fully documented and participants could remember them differently.

That caution matters. The memo was not announcing that DNS had stopped working. It said performance and reliability still appeared acceptable and that there was little evidence of serious degradation. The deeper concern was architectural. The Internet had begun to ask a precise lookup system to perform discovery, classification and culturally sensitive matching. Successive workarounds could keep individual applications moving while making the common layer harder to reason about.

What the original bargain bought

Before DNS, a frequently copied host table mapped names to network addresses. The names spared people from memorising numbers, survived topology-driven address changes and could refer to a host with more than one address. As the network grew, distributing one table ceased to scale. DNS retained unique, unambiguous naming while distributing both lookup and administration through a hierarchy. It also allowed additional record types, notably for services such as mail.

That extensibility did not erase the original task. RFC 3467 described DNS as a system for identifying network resources, not primarily people, brands, products or documents. The wire format could carry more than the narrow letters, digits and hyphens familiar from hostnames, but applications had accumulated their own assumptions about what a usable name looked like. A structure capable of storing bits was not therefore a neutral answer to every naming problem.

By 2003, the memo argued, DNS had become a “database of convenience.” New data was proposed for it because DNS existed, was widely deployed and could be queried almost everywhere. Those are powerful operational advantages. They do not show that the hierarchy, comparison rules, caching behaviour or public authority model fit the new data.

Exact equality is not useful similarity

The distinction becomes visible in a failed query. DNS comparison must eventually produce a deterministic match or no match. A human search may need near matches, alternate spellings, different scripts, local conventions or several plausible results. It may need to search attributes and values rather than only a key. It may also need to explain why one candidate ranked above another.

RFC 3467 listed pressures that made this mismatch harder to ignore: company and product names forced into a flat commercial namespace; many public names pointing at one host; responses varied for proximity or audience; personal information exposed to callers with different permissions; and multilingual names whose perceived similarity could depend on language and context. The memo did not prove that fuzzy matching was safe. On the contrary, it recognised that flexibility could create fraud, confusion and trademark conflict.

Internationalisation sharpened the boundary without dissolving it. String preparation can map or reject characters before a deterministic lookup. That is not the same as searching for what a user meant. Canonicalisation reduces specified variations to a comparison form; fuzzy discovery admits that multiple candidates may remain. The first can feed an exact resolver. The second needs ranking, context and a visible choice.

The same limit appeared from another direction. DNS could not generally answer “which names have this record value?” The old IQUERY mechanism, intended to locate names associated with a resource record, was later obsoleted after poor implementation and operational experience. Reverse address mapping remained a separate named facility; RFC 3467's point was not that no reverse mapping existed, but that DNS was not a general database search engine.

Put discovery before resolution

The memo's alternative was a two-stage architecture. A search or directory layer would accept the loose human input. It could carry attributes such as language and country, use locally appropriate matching rules, and return one or more candidate names with context. After a person or an agent selected a candidate, ordinary DNS would resolve the resulting exact identifier.

That separation protects two different kinds of truth. A directory result says that a candidate matched a query under a particular index, rule set and moment in time. A DNS response says that a particular resolver context obtained records for an exact name. Neither receipt proves the other. A highly ranked candidate may point to the wrong subject. A valid DNS response may lead to an unavailable service. An authenticated record can protect the data's provenance without proving that the user chose the intended entity.

The search layer was not cost-free. Its index could be stale or manipulated; its ranking could encode commercial incentives; local matching rules could make the same query behave differently; and a second database created another attack and governance surface. RFC 3467's security section said a directory used to locate network resources would need protection against unauthorised changes. More layers meant more handoffs to secure, not a magical escape from authority.

The valuable result was a boundary

RFC 3467 did not ship the directory, define its protocol or demonstrate a migration. It did something more modest and durable: it stopped treating all naming questions as one question. The common Internet needed exact identifiers whose meaning remained stable. People also needed forgiving ways to discover those identifiers. Forcing both jobs into one mechanism risked either making DNS context-dependent or making human discovery unnaturally rigid.

The operational lesson is to preserve the seam. Record the original query and its context, the candidates returned, the selection made, the exact DNS name submitted, the resolver context, the answer received, the endpoint contacted and the application outcome. A successful final connection must not erase the earlier ambiguity. An exact answer is evidence that a key resolved. It is not evidence that the key was what the human meant.

Sources