Original text:
This behavior creates a number of possible attacks for certain server configurations.  For example, if "https://$HOSTNAME/upload" accepts any POST request as a public file upload, the adversary could forge a <del> SVCB record containing "dohpath=/upload".  This would cause the </del>  client to upload and publish every query, resulting in unexpected storage costs for the server and privacy loss for the client. Similarly, if two DoH endpoints are available on the same origin, and endpoint instead. To mitigate redirection attacks, a client of this SVCB mapping MUST <del> NOT provide client authentication for DNS queries, except to servers that it specifically knows are not vulnerable to such attacks.  If an endpoint sends an invalid response to a DNS query, the client SHOULD NOT send more queries to that endpoint.  DNS services that are identified by a hostname (identity) MUST ensure that all unauthenticated DNS requests to that name receive any promised privacy and security guarantees, regardless of transport, port number, or HTTP path. </del>  8.2.

Reviewer comments:
NAME Please review.
currently says: This MUST seems strange. Is this just saying "don't do silly or otherwise bad things with client queries"? I'm not sure that's something we need normative language for here, so unless there's a particular behavior that this is meant to require (or prohibit), I'd recommend removing it.
Suppose is your consumer-facing endpoint with limited logging, and is a debug endpoint that drops all queries into a log that's accessible to your whole engineering staff. The point of this sentence is that, if this is your configuration, you can't promise users the limited logging on the consumer-facing endpoint, because any intermediary could flip users onto the debug endpoint, causing you to violate your own promise. You need to move these endpoints onto separate hostnames. Separate paths, port numbers, or even separate ALPNs, is not sufficient, because an attacker can steer the user between them.
I agree the original text was unclear unless you're already familiar with the problem. I wasn't. However Ben's response above DID make sense to me, so it would be good to use some of it.
recommends that clients mitigate redirection attacks by not using client authentication to DNS resolvers. Perhaps a better approach would be to not use a TLS context or association that is used for other purposes, regardless of whether that context uses client authentication.
I don't think that is sufficient. The attack does not depend on the client authentication being shared with another context. For example, if I rewrite the to be , and this triggers an HTTP Basic Authentication response that causes the client software to pop up a username+password prompt, the user might log in and enable the attack.
There are lots of ways connection state could be misused here. For example, what if the new DNS query is sent over a connection that uses cookies? What if the DNS query resumes a previously established TLS connection that used some application layer authentication? Basically, this text seems not quite right, since it seems to focus on TLS-layer things. I recommend further refining to make it clear what is expected of this new connection. I'm happy to propose a PR to clarify my thinking, if that would be useful.
"Client authentication" in this text is not intended to to be limited to TLS. It applies to any form of client authentication in any protocol, including HTTP.
Great -- I'll propose text!
I've added a small change to that tries to clarify this requirement.

Revised text:
This behavior creates a number of possible attacks for certain server configurations.  For example, if "https://$HOSTNAME/upload" accepts any POST request as a public file upload, the adversary could forge a  <ins> SVCB record containing "dohpath=/upload{?dns}".  This would cause the </ins> client to upload and publish every query, resulting in unexpected storage costs for the server and privacy loss for the client. Similarly, if two DoH endpoints are available on the same origin, and endpoint instead. To mitigate redirection attacks, a client of this SVCB mapping MUST  <ins> NOT identify or authenticate itself when performing DNS queries, except to servers that it specifically knows are not vulnerable to such attacks.  If an endpoint sends an invalid response to a DNS query, the client SHOULD NOT send more queries to that endpoint. Multiple DNS services MUST NOT share a hostname identifier (identity) unless they are so similar that it is safe to allow an attacker to choose which one is used. </ins> 8.2.