Change:
indicate that "resolver.example.com" supports both DoH and DoT, and that the DoH server indicates a higher priority than the DoT server. <del> Often, the various supported encrypted DNS protocols will be accessible using the same hostname.  In the example above, both DoH and DoT use the name "resolver.example.com" for their TLS certificates.  If a deployment uses a different hostname for one protocol, but still wants clients to treat both DNS servers as designated, the TLS certificates MUST include both names in the SubjectAlternativeName fields.  Note that this name verification is not related to the DNS resolver that provided the SVCB answer. For example, being able to discover a Designated Resolver for a known Encrypted Resolver is useful when a client has a DoT configuration for "foo.resolver.example.com" but is on a network that blocks DoT traffic.  The client can still send a query to any other accessible resolver (either the local network resolver or an accessible DoH server) to discover if there is a designated DoH server for "foo.resolver.example.com". </del> <ins> Clients MUST validate that for any Encrypted Resolver discovered using a known resolver name, the TLS certificate of the resolver contains the known name in a subjectAltName extension.  In the example above, this means that both servers need to have certificates that cover the name "resolver.example.com".  Often, the various supported encrypted DNS protocols will be specified such that the SVCB TargetName matches the known name, as is true in the example above.  However, even when the TargetName is different (for example, if the DoH server had a TargetName of "doh.example.com"), the clients still check for the original known resolver name in the certificate. Note that this resolver validation is not related to the DNS resolver that provided the SVCB answer. As another example, being able to discover a Designated Resolver for a known Encrypted Resolver is useful when a client has a DoT configuration for "foo.resolver.example.com" but is on a network that blocks DoT traffic.  The client can still send a query to any other accessible resolver (either the local network resolver or an accessible DoH server) to discover if there is a designated DoH server for "foo.resolver.example.com". </ins> 6.

Discussion:
Remove text about extra cert checks, just focus on the IP address Add considerations about server name handling. Server must accept IP address for SNI and URI host. Clients must not use URL for this value. Clients can either send the IP address or the ServiceMode TargetName
NAME this removes checking for both the name and the IP address. The text about checking the name is for when the client started with a name, not an IP address.
NAME please take another look!
When this says "the domain name (from the SVCB answer)", what does it refer to? Does this refer to the TargetName of a SVCB record? If so, which TargetName? If I query for SVCB records at URL, I might get an arbitrary number of AliasMode SVCB RRs, which might each lead to some number of other AliasMode SVCB RRs on the way to a ServiceMode SVCB RR. That might be a lot of options.
I continue to believe that this entire concept should be removed from the draft. The IP address of the Unencrypted Resolver is the only securely sourced reference identity, and it is the only identity that should be required in the certificate.
The name that’s used in the HTTP request as the authority and the TLS SNI really should be in the certificate :) we’ve covered this before, and I see no reason that these connections would have a strange exception to not expect a match between the DoH name and the certificate. NAME is right we should clarify in the text about how to handle aliases. In fact, NAME should this be in the reference doc about DNS SVCB instead of here? It describes how to construct the DoH URI, and the answer here needs the be the same as the DoH URI’s hostname.
To be clear, I agree with NAME the addition of a second reference identity is a mistake. But I was not asking about that. You can't rely on DNS SVCB to solve this problem, because you invented this particular problem. DNS SVCB does the sensible thing and assumes that the client will not allow its opinions regarding a reference identity to be influenced by something as dangerous as DNS (see also: mistakes of MX). As this document doesn't hold to that principle, it has to deal with the consequences of that choice. At a minimum, that means deciding on exactly how your new reference identity is determined.

I think your options basically reduce to one of: The first non-attr-leaf TargetName in the chain leading to the ServiceMode SVCB RR. The TargetName in ServiceMode SVCB RR. The DNR draft has a much better approach here: As we're relying on DHCP/RA for "trustworthy" configuration, have that system provide a name.
Yes, and the authority is the IP address. When using DDR with 9.9.9.9, the DoH URI should be , regardless of the actual transport IP. That draft currently says: by combining the prefix "https://", the service name, the port from the "port" key if present, and the "dohpath" value and transport establishment. This name is the hostname used to construct the original SVCB query, and cannot be influenced by the SVCB record contents. I think we need a change to both drafts. EDIT: See URL, which distinguishes the "binding authority" from the "authentication name". This would allow DDR to say something like
NAME thanks for the change in the SVCB-DNS draft. That certainly helps make this more consistent. With that change, then we no longer need to have any special case in DDR for making sure that both the address and the name used in the HTTP authority are the covered in the cert, since they'll be the same.
I'm sorry, what? The WG soundly rejected IP address hostnames as a requirement back in RESINFO days. This is a full 180 pivot. I see reviewing the notes that no consensus was gained during IETF 109 on the topic of "why do we have two identities?". I think it's fair to say DDR only cares about the source IP address. I would expect in practice that most clients will end up confirming the hostname as well because who would do that for all HTTPS connections except DDR ones, but it certainly is a HTTPS/TLS requirement and not a DDR requirement. I suggest we remove the hostname requirement. I strongly oppose requiring the hostname to equal the source IP address. It will likely make recursive resolver deployment a nightmare, and absolutely needs to be brought to the list before any text changes are made.

Going off of Tommy's point, another reason it would be incorrect to force the HTTP host or TLS SNI to be an address is that this wouldn't work for the "opportunistic" case, where the address is shared but not covered by the cert. So I think we should remove the line about checking the hostname in the cert, but also explain how to get the name from the SVCB record. Initially, the first name we get back in the chain sounds like the right answer.
In the same-IP opportunistic case, there is no certificate validation, so it doesn't matter what name (if any) is in the cert. Using the (local, private) IP address makes this unambiguous. Using the hostname makes this confusing: it suggests the existence of a reference identity where none exists.
This seems like a topic for NAME – either to explain the resolution (if it’s resolved by then) – or to explain the issue and the different sides of the discussion.
NAME Your message got a bit mangled, but I agree that this would be worth discussing as a group.
NAME I wasn’t suggesting anything about certificate validation. Rather, that for opportunistic mode, we should provide guidance about which hostname to use in the SNI and HTTP authority.
NAME NAME NAME to make this concrete, I wrote up what I was thinking in
Too follow up what I said in the meeting: What if you have a situation where a DoH server is co-located with a hosting system, e.g., "URL" and "URL" and the CDN just steers based on Host: header. So what I do is I stand up a DoH server on "URL" that produces lying responses. Then I arrange for your SVCB record to have the name "URL" and I have persuaded the client to accept responses from my invalid server.
One suggestion, but otherwise looking good.