Draft: draft-ietf-add-ddr

Commentary: There is no need to use a DNS URI for this . You are only using the name . And you do n't cite RFC 4501 . It is also incorrect , because you are treating " " as the authority , rather than the qname . What you really want is " ; type=64 " or something like that . But the words you have are adequately clear .
When a DNS client is configured with an Unencrypted Resolver IP
address, it SHOULD query the resolver for SVCB records for
"dns://resolver.arpa" before making other queries.  Specifically, the
client issues a query for "_dns.resolver.arpa" with the SVCB resource
record type (64) I-D.ietf-dnsop-svcb-https.
When a DNS client is configured with an Unencrypted Resolver IP
address, it SHOULD query the resolver for SVCB records for the name
"resolver.arpa" before making other queries.  Specifically, the
client issues a query for "_dns.resolver.arpa" with the SVCB resource
record type (64) I-D.ietf-dnsop-svcb-https.
If the recursive resolver that receives this query has one or more
Designated Resolvers, it will return the corresponding SVCB records.
When responding to these special queries for "dns://resolver.arpa",
the recursive resolver SHOULD include the A and AAAA records for the
name of the Designated Resolver in the Additional Answers section.
This will allow the DNS client to make queries over an encrypted
connection without waiting to resolve the Encrypted Resolver name per
I-D.ietf-dnsop-svcb-https.  If no A/AAAA records or SVCB IP address
hints are included, clients will be forced to delay use of the
Encrypted Resolver until an additional DNS lookup for the A and AAAA
records can be made to the Unencrypted Resolver (or some other
resolver the DNS client has been configured to use).
If the recursive resolver that receives this query has one or more
Designated Resolvers, it will return the corresponding SVCB records.
When responding to these special queries for "resolver.arpa", the
recursive resolver SHOULD include the A and AAAA records for the name
of the Designated Resolver in the Additional Answers section.  This
will allow the DNS client to make queries over an encrypted
connection without waiting to resolve the Encrypted Resolver name per
I-D.ietf-dnsop-svcb-https.  If no A/AAAA records or SVCB IP address
hints are included, clients will be forced to delay use of the
Encrypted Resolver until an additional DNS lookup for the A and AAAA
records can be made to the Unencrypted Resolver (or some other
resolver the DNS client has been configured to use).
Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as
a mode in which clients do not validate the name of the resolver
presented in the certificate.  Opportunistic Privacy similarly
applies to DoQ RFC9250.  A client MAY use information from the SVCB
record for "dns://resolver.arpa" with this "opportunistic" approach
(not validating the names presented in the SubjectAlternativeName
field of the certificate) as long as the IP address of the Encrypted
Resolver does not differ from the IP address of the Unencrypted
Resolver.  Clients SHOULD use this mode only for resolvers using
private or local IP addresses.  This approach can be used for any
encrypted DNS protocol that uses TLS.
Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as
a mode in which clients do not validate the name of the resolver
presented in the certificate.  Opportunistic Privacy similarly
applies to DoQ RFC9250.  A client MAY use information from the SVCB
record for "resolver.arpa" with this "opportunistic" approach (not
validating the names presented in the SubjectAlternativeName field of
the certificate) as long as the IP address of the Encrypted Resolver
does not differ from the IP address of the Unencrypted Resolver.
Clients SHOULD use this mode only for resolvers using private or
local IP addresses.  This approach can be used for any encrypted DNS
protocol that uses TLS.