Change:
4.2. <del> Authenticated Discovery is a mechanism that allows automatic use of a </del> <ins> Verified Discovery is a mechanism that allows automatic use of a </ins> Designated Resolver that supports DNS encryption that performs a TLS handshake. <del> In order to be considered an authenticated Designated Resolver, the TLS certificate presented by the Designated Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the designating Unencrypted Resolver within the SubjectAlternativeName certificate field.  The client MUST check the SubjectAlternativeName field for both the Unencrypted Resolver's IP address and the advertised name of the Designated Resolver.  If the certificate can be validated, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the Unencrypted Resolver.  If the Designated Resolver has a different IP address than the Unencrypted Resolver and the TLS certificate does not cover the Unencrypted Resolver address, the client MUST NOT automatically use the discovered Designated Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record's Time to Live (TTL). </del> <ins> In order to be considered a verified Designated Resolver, the TLS certificate presented by the Designated Resolver MUST contain the IP address of the designating Unencrypted Resolver in a subjectAltName extension.  If the certificate can be validated, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the Unencrypted Resolver.  If the Designated Resolver has a different IP address than the Unencrypted Resolver and the TLS certificate does not cover the Unencrypted Resolver address, the client MUST NOT automatically use the discovered Designated Resolver.  Additionally, the client SHOULD suppress any further queries for Designated Resolvers using this Unencrypted Resolver for the length of time indicated by the SVCB record's Time to Live (TTL). </ins> If the Designated Resolver and the Unencrypted Resolver share an IP address, clients MAY choose to opportunistically use the Designated

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.