Summary

  • RFC 1535 documented resolver clients that treated a non-rooted name as material for an ordered search. A user at Machine.Tech.ACES.COM who entered UnivHost.University.EDU could trigger three suffixed candidates before the intended rooted name was tried.
  • Once EDU.COM existed and could answer below its branch, the search could terminate there. The defect was not merely a wildcard: implicit completion had crossed beyond the namespace locally administered by the searching organization.
  • The proposed correction preserved useful abbreviations by narrowing implicit search, trying dotted names as rooted first, and requiring further local alternatives to be configured explicitly. RFC 1535 was Informational; it does not prove deployment scale, an observed compromise, present-day resolver behavior or authenticated endpoint identity.

One token, four questions

The user supplied one visible token. The resolver described by RFC 1535 could turn it into four DNS questions.

The searching machine in the memo was Machine.Tech.ACES.COM. The user entered UnivHost.University.EDU without a final root dot. A BSD BIND-derived search heuristic could try, in order:

  1. UnivHost.University.EDU.Tech.ACES.COM.
  2. UnivHost.University.EDU.ACES.COM.
  3. UnivHost.University.EDU.COM.
  4. UnivHost.University.EDU.

The first two candidates still sat under names associated with the local organization. The third did not. It was under EDU.COM., a separately registrable branch of .COM. Yet the resolver reached it before asking the fourth question, which was the rooted form that matched the user's apparent spelling.

That sequence is the center of the story. A log containing only the typed string would say the user asked for one name. A packet capture containing only the successful DNS exchange could say the resolver asked for another. Both records would be accurate and neither would explain the decision. The missing object is the candidate generator: its search list, ordering, boundary and stop rule.

RFC 1535's Datatracker record identifies the memo, while the RFC Editor record preserves its October 1993 Informational status. The archival text supplies a byte-oriented cross-check, and the errata surface records corrections separately. None of those documentary facts tells us how many machines followed the heuristic or how any current resolver behaves.

The final dot was a scope instruction

DNS names can be written relative to a local context or rooted in the global tree. In the convention discussed by the memo, a trailing dot marked an absolute fully qualified domain name: UnivHost.University.EDU.. Without that dot, the same visible labels could be treated as a partial name eligible for completion.

The dot did not authenticate the destination. It did not prove who operated the host, whether the answer was fresh or whether an application would connect safely. It made a narrower syntactic claim: stop interpreting this name relative to a search origin and start at the DNS root.

That distinction predated the security report. RFC 1034, whose status record belongs to STD 13, described relative names being completed against an origin or search list. It also acknowledged that user-interface interpretation varied among implementations. RFC 1035 and its document record provide the companion resolver, message and resource-record context. They define a technical vocabulary; they do not prove that every later interface used the same search behavior.

The dangerous step in RFC 1535 was therefore not that relative names existed. Relative names are useful inside a known context. It was that software could infer a search scope from the searching host's full domain and then walk suffixes whose administrative meaning it did not understand.

A suffix is not evidence of shared administration

From a string processor's perspective, Tech.ACES.COM, ACES.COM and COM are progressively shorter suffixes. From an authority perspective, they are not three interchangeable levels of one organization.

An administrator responsible for ACES.COM might reasonably control search rules that add Tech.ACES.COM or ACES.COM to a local abbreviation. That responsibility does not extend to every possible name below .COM. Once the heuristic removed ACES, the next candidate entered a branch whose operator had received no instruction from the user and no delegation from the local administrator.

This is why “append fewer labels until something answers” was not merely an inefficient algorithm. It silently reassigned interpretive power. The searching organization supplied the context, but an unrelated public registrant could supply the first successful completion.

The RFC 1535 record calls the problem a security issue in widely deployed DNS software. That title is historically important, but it is not a measured installed-base report. The bounded fact is that the authors documented the behavior and proposed a correction. We should not turn their title into a present-day count.

EDU.COM made the authority transfer visible

The memo reported that EDU.COM had been registered and that a wildcard CNAME beneath it could direct requests for names of the form something.edu.com toward one target. It illustrated the effect with harvard.edu.com.

In the candidate sequence above, the user did not type edu.com. The resolver created that suffix combination while searching. If the third query returned a resource record, the stop condition could prevent the fourth, intended rooted query from being sent. The successful DNS answer did not merely supply data; it selected which interpretation of the original token survived.

The wildcard amplified the reach of that branch, but it was not the whole defect. Even a specific record could have terminated a search. The deeper failure was allowing an implicitly generated candidate outside local authority to compete ahead of a plausible rooted interpretation.

Nor does the example prove a stolen password or completed connection. A DNS answer is one receipt. A TCP connection, certificate or other endpoint authentication, application prompt, submitted credential and user-visible outcome are different receipts. RFC 1535 warned that users could be misdirected and exposed a path by which that could happen. It did not supply a census of resulting incidents.

The historical EDU.COM configuration should not be projected onto the current domain. The article's evidence boundary ends with the source's 1993 report.

Search order was executable policy

A search list is often presented as a convenience setting. Operationally, it is a program with at least four decisions:

  • which input is eligible for expansion;
  • which suffixes may be appended;
  • in what order the candidates are tried;
  • which response terminates the sequence.

Change any one and the same user token can resolve differently. A configuration screen showing an unordered set of suffixes is therefore incomplete evidence. Order matters. So does whether a negative answer advances the search, whether any resource record is enough to stop, whether a cache can satisfy a candidate, and whether the rooted form is attempted before or after local alternatives.

RFC 1123, with its Host Requirements status record, treated abbreviation facilities as optional. It required a convention for entering a complete name and said the conversion from a user-entered name to a complete domain name should occur exactly once and in the proper context. It also allowed administrators to disable search lists. Those points matter because multiple layers can otherwise expand the same token: an application may add a suffix, a library may search again, and a downstream service may reinterpret the result.

RFC 1123 placed a different constraint on root traffic: a host had to use negative caching and/or require a minimum number of internal dots before sending non-local queries. That rule limited query load; it did not decide who was entitled to interpret the user’s name, so it complemented rather than replaced the local boundary and candidate-order rules.

“Exactly once” is not just a performance instruction. It establishes ownership. One named component should perform completion under one inspectable policy. If two hidden components can both rewrite, a final query no longer reveals which layer made the choice.

The correction narrowed implicit power

RFC 1535's minimum correction was to parameterize the locally administered boundary. Implicit search should not continue shortening the host's domain after it crossed that point. An organization could say, in effect, “these suffixes remain mine to complete; beyond them, do not manufacture candidates on my behalf.”

The memo also described a stricter behavior associated with BIND 4.9.2. Implicit search was reduced to a narrow pattern: try an appropriate local form and the rooted form, rather than walking every progressively shorter suffix. A name containing a dot was to be tried as rooted first.

That last rule is easy to overstate. It did not decree that every dotted token was complete in every application. Organizations sometimes used multi-part abbreviations inside their own namespace. The change was one of precedence and authority: give a complete-looking dotted name its rooted interpretation before speculative completion, and require any further alternatives to be named explicitly.

Explicit configuration did not make errors impossible. An administrator can configure the wrong suffix or an unsafe order. But it changed the accountability surface. A universal hidden heuristic became a local, inspectable decision. The configuration could be reviewed, versioned, disabled and limited to zones actually administered by the organization.

Convenience was real—and so was its externality

Search lists existed because they were useful. People inside a campus or company could type short service names. Applications could preserve habits formed before globally visible names became routine. Removing every abbreviation would have imposed real friction.

The benefit appeared immediately to the local user: fewer characters and familiar names. The cost appeared later and often elsewhere. A security team might investigate a connection to an unexpected endpoint. An external administrator might receive traffic never intentionally addressed to its zone. An application owner might face an authentication incident whose initiating string looked correct. That separation of benefit from cost favors expansive defaults.

RFC 1535's repair is notable because it did not choose between convenience and safety as absolutes. It relocated the choice. Locally intended abbreviations could remain, but their suffixes had to be explicit. A rooted dotted name received priority. The resolver's freedom to explore public suffixes was withdrawn.

This resembles the minimum-contract discipline in Heng Lu's Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption: keep the shared rule narrow, leave local variation local, and make future choices visible rather than silently universal. It is an editorial lens applied after the fact, not evidence of the RFC authors' private intent.

A successful answer was not the intended identity

The resolver needed a stopping condition. A resource record was operationally useful because it said one candidate existed. But existence is not intention.

Suppose a trace shows that UnivHost.University.EDU.COM. returned a CNAME. That proves an authoritative or cached answer was supplied for that candidate at that time. It does not prove the user meant the candidate, the local administrator authorized its creation, the target represented the intended institution, the transport reached it, an authentication check passed or the application completed safely.

Heng Lu's Running-Code Primacy is useful here because the RFC is a coordination and diagnostic artifact, not a runtime receipt. The real question is what a particular implementation generated and what the network observed. The reality-layer discipline keeps the typed token, resolver policy, candidate question, DNS answer, selected endpoint and application result from collapsing into one green status.

The closest companion memos reinforce the boundary. RFC 1536, identified separately by its RFC Editor record, catalogued implementation errors involving traffic, retry, recursion and caching. RFC 1537, with its own status record, addressed common DNS data-file mistakes. They show a wider 1993 effort to make operational failures legible. Neither substitutes for RFC 1535's candidate-generation evidence.

The durable artifact is the candidate ledger

A trustworthy resolver record begins before the first DNS packet. It retains the exact token, including whether a root dot was present; the calling application; the request to use or bypass search; the resolver library and its configuration epoch; the ordered suffix list; the locally administered boundary; every generated candidate; and the rule that advanced or stopped the search.

For each candidate, it should preserve query time, transport, response code, authority and answer data, relevant CNAMEs and whether the result came from cache. It should then name the selected canonical endpoint separately from the DNS answer, record transport and endpoint authentication, and preserve the application action and observed result.

Passwords and secret material do not belong in that ledger. A bounded fingerprint, destination identity and authorization outcome can show what happened without reproducing sensitive contents.

RFC 1535's lasting lesson is not that users must remember one punctuation mark. It is that an invisible convenience layer can acquire authority by generating alternatives. That authority is legitimate only within a declared scope, in deterministic order, with a reviewable stop condition and evidence that distinguishes the user's input from the software's interpretation.

Sources