Summary

  • RFC 9532 lets an HTTP intermediary report the CNAME aliases and canonical names it received while resolving its next hop; it does not carry DNSSEC evidence or authenticate the resource.
  • A field can be absent, empty or incomplete, and a resolver or proxy can omit the very records a client hoped to inspect. Presence and absence inherit the trust boundary of the reporting path.
  • A defensible decision joins the proxy identity, resolver view, raw DNS and DNSSEC evidence, endpoint authentication, local client policy and the action actually taken.

The browser received a neat chain of names. A familiar hostname pointed to a less familiar one, which pointed again before an address appeared. The chain made an invisible part of the proxy’s work visible.

It did not make the last name the host’s identity.

RFC 9532 defines next-hop-aliases, a parameter for the HTTP Proxy-Status response field. An intermediary can use it to report the aliases and canonical names it received in CNAME records while resolving the next hop. The immediate use is practical. A client of a forward proxy often knows the hostname it requested but not the path of DNS indirection the proxy saw. CNAME chains can also cloak a tracker or malicious host behind an innocuous first-party name. Returning the chain restores some of the context the client lost when it delegated resolution.

The crucial word is “report”. The proxy is describing its observation. It is not relaying a DNSSEC validation proof, issuing a certificate for the destination or speaking on behalf of the DNS authority.

One string contains two grammars

The parameter is a Structured Fields string. Inside that string, RFC 9532 defines a comma-separated list of DNS names. The names may include every alias and canonical name received in CNAME records and may also include the originally requested hostname. They ought to appear in received order: the first item normally follows the requested name; the last is the canonical name that resolved to one or more addresses.

This creates two parsing layers. The HTTP field must first be parsed under the Structured Fields rules of RFC 8941. The resulting string must then be interpreted using RFC 9532’s list grammar. A comma that belongs inside a DNS name must be percent-encoded so that it cannot masquerade as a separator. A period that belongs inside a label must be escaped before the backslash is percent-encoded. Literal backslashes have their own double-escape rule.

Those details are not decoration. A security system that decodes in the wrong order can manufacture a different name from the one the proxy intended to disclose. The record therefore needs the field bytes received, parser version, decoding steps and final labels—not merely a screenshot of a human-readable chain.

Complete syntax does not mean complete history

An implementation can only disclose what its resolver interface exposes. RFC 9532 notes that common getaddrinfo APIs may return the final canonical name through AI_CANONNAME without returning the preceding aliases. The standard therefore permits incomplete information when the full chain is unavailable.

A perfectly valid field can be partial.

The proxy may also send an empty string to indicate that it encountered no CNAME records. Clients must handle the parameter being absent. These states are not interchangeable:

  • absent may mean unsupported, stripped, not applicable, deliberately omitted or simply not emitted;
  • empty means the reporting proxy says its resolution encountered no CNAME records;
  • populated means the proxy reports some or all names it received;
  • malformed means the client cannot safely reconstruct the report.

None proves what every resolver would have seen. Cache state, resolver policy, split DNS, answer synthesis and the authoritative response available at another time can produce another view. A recursive or authoritative resolver seeking to hide cloaking can omit records. A malicious proxy can omit the chain as well. Absence of reported evidence is therefore not evidence that no aliases existed.

The field does not transport DNSSEC

RFC 9532 is unusually direct about its authority boundary. next-hop-aliases contains no DNSSEC information and does not imply that DNSSEC was used. The client may trust it only as far as it trusts the proxy and the resolvers the proxy used. The document calls the information a hint and says it should not be used to decide the identity of the accessed resource.

DNSSEC, described by RFC 4033 and RFC 4035, has a different job. A validating resolver can authenticate DNS data origin and integrity, and can validate denial of existence, under a chain of trust. A comma-separated alias report carries none of that proof material or validation state.

Even a separately validated CNAME chain would still not prove every later layer. DNS names lead a connection toward an address. HTTP authority, TLS key possession, application account identity, cookie entitlement and permission to release data remain separate questions. A DNS proof can strengthen the name-resolution layer without deciding the application action.

Proxy-Status names the witness

RFC 9209 created Proxy-Status so intermediaries could explain how they handled a request. That provenance matters. The field is not a neutral observation floating above the path; it is testimony from an intermediary.

A useful audit therefore starts by naming the witness. Which proxy generated the item? How did the client authenticate or otherwise trust that proxy? Did another intermediary append, preserve or strip the field? Which resolver did the proxy call? Was that resolver validating? Which cache and configuration epoch produced the answer? Was the list captured before or after any local filtering?

The next evidence layer is the DNS material itself: query name, response code, CNAMEs, terminal address records, TTLs and, when consequential, the DNSSEC records and validation result. The next is the disclosure transformation: what the proxy could observe, what it included, ordering, escaping and serialization. Then come connection evidence, endpoint authentication, local policy and outcome.

The alias string becomes useful when it is one joined item in that receipt. On its own, it proves only that a response presented a string claiming to describe a resolver view.

Visibility is valuable without becoming authority

The boundary does not make RFC 9532 weak. It makes the parameter safe to use honestly.

A browser can treat a newly revealed tracker alias as a reason to apply a cautious cookie policy or request another check. An enterprise proxy can expose why a destination was reached through an unexpected service name. An incident team can compare changes in the chain with connection failures. A researcher can distinguish the hostname requested by the client from the canonical name observed at the intermediary.

Each use remains local and revisable. That fits Heng Lu’s principle of a minimum initial specification followed by localized decisions. The shared layer standardizes how to disclose names; it does not centralize the policy for cookies, blocking or trust. It also fits running-code primacy: the evidence is the executed path from DNS response through proxy encoding, client parsing and policy effect, not the existence of a registry entry or a configured feature.

The reality layers must stay separate. A DNS name is not the resolver’s answer. The answer is not the proxy’s report. The report is not DNSSEC validation. Validation is not endpoint authentication. Authentication is not authorization. Authorization is not the outcome.

What the sources do not establish

The RFCs define protocol semantics and security limits. They do not show how widely next-hop-aliases is deployed, whether a named browser or proxy emits it, how often CNAME cloaking occurs or whether any product made a correct decision from it. The examples in RFC 9532 are illustrations, not observed incidents.

That uncertainty belongs in the article because it protects the distinction at its centre. A standard can make an observation portable without proving that anyone observed, reported, validated or acted correctly in a real system.

Sources