Original text:
FIELDS that contains one or more DNS names in a comma-separated list. The items in the list include all alias names and canonical names received in CNAME records DNS during the course of resolving the next <del> hop's hostname using DNS, not including the original requested </del>  hostname itself.  The names SHOULD appear in the order in which they were received in DNS.  If there are multiple CNAME records in the chain, the first name in the "next-hop-aliases" list would be the

Reviewer comments:
Allow the original name of the next hop to be the start of the list, and add an example.
NAME NAME please review!
LGTM
I understand that the current draft is specifically targeting forward proxies, but as currently described, the is missing some information when used by reverse proxies, and it's not self-contained anymore (i.e. the requested/configured next hop is not part of the field), making debugging much harder. I find the fact that is not included here a bit confusing. While operators or clients connecting directly to might know that it's a forward proxy and could infer that was the requested hostname, the clients that are a few hops away from it, won't know this, and might be surprised how the and other aliases got in there. Furthermore, in a similar scenario with a client connecting to the reverse proxy and requesting , which is configured to use as the backend, that response is missing the most critical piece of information, and instead of helping, it adds more confusion. As such, I'd suggest that the requested/configured hostname should be included as the first entry in , especially when points to the resolved IP address. cc NAME NAME
This is a good point, especially for reverse proxies. The name of the next hop could be in the next-hop parameter itself, but then there is a choice between the address and the name there. For forward proxies, the name is known and the address is interesting. For reverse proxies, i imagine the name of the next hop is more useful than the address, but I can see why both could be wanted. In such case, perhaps we can allow the aliases list to include the next hop name if it differs from the authority requested by the client.
Yes, that's unfortunate. I'm not sure how we've missed this in RFC 9209. Perhaps we could allow both and use for the configured next hop name, and for the resolved IP address... which actually matches what I'm suggesting we do here by including the requested/configured name as the first entry in . But that's only true on the first hop, right? The authority could be changed along the way by intermediaries, and then the original client wouldn't know what started the resolution which resulted in the received . How would the original client know if that happened in a long chain of proxies? The authority requested by the client connecting to is not included in the header, and therefore it's not known to the original client. It's impossible to tell if that entry was generated by a proxy that was configured to connect to , which also happens to be the authority it received and therefore it's not included in , or if it was configured to connect to . Basically, I'm trying to avoid adding ambiguity and guesswork to the debugging process that uses this header.
Upon discussing in person: Good to add to an example The text should make it clear that the original name is allowed to be at the start of the list (but doesn't strictly need to be included)

Revised text:
FIELDS that contains one or more DNS names in a comma-separated list. The items in the list include all alias names and canonical names received in CNAME records DNS during the course of resolving the next  <ins> hop's hostname using DNS, and MAY include the original requested </ins> hostname itself.  The names SHOULD appear in the order in which they were received in DNS.  If there are multiple CNAME records in the chain, the first name in the "next-hop-aliases" list would be the