HTTP Proxy-Status Parameter for Next-Hop Aliases
Extracted elements (16)
CNAME records can be used to 'cloak' hosts that perform tracking or malicious activity behind more innocuous hostnames. Clients such as web browsers use the chain of DNS names to influence cookie usage policies or block malicious hosts, making the full CNAME chain valuable information to expose to clients of forward proxies.
The existing next-hop Proxy-Status parameter can contain only one hostname, IP address, or alias, so it cannot convey the full CNAME chain encountered during DNS resolution. A new parameter is needed to allow clients to see the complete chain of DNS names, which is particularly useful for CONNECT and UDP proxying clients.
Common DNS resolution APIs such as POSIX getaddrinfo may not expose the full CNAME chain. The AI_CANONNAME option returns only the final canonical name, not intermediate aliases. Implementations limited to getaddrinfo may therefore only be able to populate the canonical name in the parameter.
The next-hop-aliases parameter only applies when DNS was used to resolve the next hop's name; it does not apply in all situations. Clients MUST gracefully handle situations in which this parameter is not present.
A backslash ('\') character in a DNS label MUST be escaped as '\\' before percent-encoding. Other uses of '\' MUST NOT appear in the label after percent-decoding.
A period character ('.') that appears within a DNS label rather than as a label separator MUST first be escaped as '\.' before percent-encoding. The resulting encoded sequence (e.g., '%5C.') MUST be treated as a single label upon parsing.
An implementation MAY include incomplete information in the next-hop-aliases parameter when the full CNAME chain is unavailable — for example, including only the canonical name when limited to getaddrinfo.
Any characters appearing in DNS names within the next-hop-aliases list that do not belong to the set of URI unreserved characters (RFC 3986 Section 2.3) MUST be percent-encoded as defined in RFC 3986 Section 2.1, to prevent commas or other special characters from causing incorrect parsing.
The next-hop-aliases information SHOULD NOT be used for making security decisions about the identity of a resource accessed through the proxy, as it does not include DNSSEC information and is only as trustworthy as the proxy itself.
The next-hop-aliases list MAY include the original requested hostname itself as a list item. The names ought to appear in the order in which they were received in DNS for consistency.
The proxy MAY send an empty string ("") as the value of the next-hop-aliases parameter to explicitly indicate that no CNAME records were encountered when resolving the next hop's name.
The next-hop-aliases parameter uses a comma (',') as a separator between DNS names in the list. If a comma appears within a name itself, it must be percent-encoded as '%2C'. The parameter can be included independently of the next-hop parameter.
The next-hop-aliases parameter value is a Structured Fields String containing one or more DNS names in a comma-separated list. The list includes all alias names and canonical names received in CNAME records during DNS resolution of the next hop's hostname, and MAY include the original requested hostname itself.
This document registers the 'next-hop-aliases' entry in the IANA 'HTTP Proxy-Status Parameters' registry. The parameter is described as 'A string containing one or more DNS aliases or canonical names used to establish a proxied connection to the next hop.'
Recursive or authoritative resolvers may omit CNAME records to hide cloaking of trackers or malicious hosts, and a malicious proxy may also suppress CNAME chain reporting. The absence of next-hop-aliases data is therefore not a reliable indicator that no CNAME records exist.
The next-hop-aliases parameter carries no DNSSEC validation status and does not imply that DNSSEC was used. Clients can trust the information only to the extent that they trust the proxy to provide accurate DNS data.