Original text:
handshake. In order to be considered a verified Designated Resolver, the TLS <del> 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 </del>  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

Reviewer comments:
That's it apparently. No mention of RFC 6125(bis). On that basis, a self-signed certificate suffices. This is something that recently came up on the mailing list and apparently current deployments are validating based on WebPKI trust anchors in addition to checking for the iPAddress subjectAltName. So it's not as bad as this allows. Maybe that should be written down. The same problematic text is found in Section 4.2 and Section 5.
NAME do you have a suggestion about the right way to explain the trust anchor use here? Any text we can model after?
s/MUST contain/MUST prove authority over/ ?
I'm not looking to aggressively economize here. I was wrong about 6125. A reference to URL for the IP reference identity might be needed to cover the SAN validation piece. RFC 6125bis doesn't include the IP-ID piece, which is something I'm going to take up with the UTA WG... But it is RFC 5280 that you really want here. describes how you take a certificate and determine if you trust what it says. Start there, then talk about what the certificate needs to say (IP SAN) in order for it to be accepted. (BTW, RFC 9110 doesn't cite Section 6 of RFC 5280. It should, and it is probably my fault that it doesn't. Section 1.2 of RFC 6125bis says "In order to ensure proper authentication, applications need to verify the entire certification path as per ]" but this is a bit weak.) This is about a paragraph all up, which isn't too much to ask.
NAME take a look at the proposed text
LGTM

Revised text:
handshake. In order to be considered a verified Designated Resolver, the TLS  <ins> certificate presented by the Designated Resolver needs to pass the following checks made by the client: The client MUST verify the chain of certificates up to a trust anchor as described in Section 6 of RFC5280.  This SHOULD use the default system or application trust anchors. The client MUST verify that the certificate contains the IP address of the designating Unencrypted Resolver in a subjectAltName extension. If these checks pass, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the Unencrypted Resolver. If these checks fail, the client MUST NOT automatically use the </ins> 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