Original text:
Binding (SVCB) records for DNS Servers, defined by I-D.schwartz-svcb- dns. <del> The following is an example of an SVCB record describing a DoH server: </del>  <del> The following is an example of an SVCB record describing a DoT server: </del>  If multiple Designated Resolvers are available, using one or more encrypted DNS protocols, the resolver deployment can indicate a preference using the priority fields in each SVCB record I-D.ietf- dnsop-svcb-https.  This document focuses on discovering DoH and DoT Designated Resolvers.  Other protocols can also use the format defined by I- D.schwartz-svcb-dns.  However, if any protocol does not involve some 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",

Reviewer comments:
This PR addresses issues and to ensure smoother implementation and deployment (avoid name resolution deadlock and clearly illustrate why "." cannot be used for target names when discovering Designated Resolvers using the URL SUDN).
The existing examples in the document all use the "." for the SvcDomainName. Per the SVCB draft section 2.5.2, this would mean that queries for the SUDN that contain this value (".") would mean that the DoH template should use the SUDN as the domain name. While the examples do not query the SUDN, meaning the examples themselves are not erroneous, there is no useful example of the SUDN case. We need to add some examples showing an SUDN query response that carries the DoH domain name in the SvcDomainName field instead of the ".".
RFC8484 section 10, para 3 talks about the need for servers to ensure client do not need DNS lookups to validate the server's certificate to avoid deadlocks. DDR should reference this and reaffirm the need to have resolvers help clients avoid this deadlock.
Thanks! These examples are very useful!

Revised text:
Binding (SVCB) records for DNS Servers, defined by I-D.schwartz-svcb- dns.  <ins> The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.example.net": </ins>  <ins> The following is an example of an SVCB record describing a DoT server discovered by querying for "_dns.example.net": </ins> If multiple Designated Resolvers are available, using one or more encrypted DNS protocols, the resolver deployment can indicate a preference using the priority fields in each SVCB record I-D.ietf- dnsop-svcb-https. <ins> To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of RFC8484 regarding the avoidance of DNS- based references that block the completion of the TLS handshake. </ins> This document focuses on discovering DoH and DoT Designated Resolvers.  Other protocols can also use the format defined by I- D.schwartz-svcb-dns.  However, if any protocol does not involve some client issues a query for "_dns.resolver.arpa" with the SVCB resource record type (64) I-D.ietf-dnsop-svcb-https. <ins> Because this query is for an SUDN, which no entity can claim ownership over, the SVCB response MUST NOT use the "." value for the SvcDomainName.  Instead, the domain name used for DoT or used to construct the DoH template MUST be provided. The following is an example of an SVCB record describing a DoH server discovered by querying for "_dns.resolver.arpa": The following is an example of an SVCB record describing a DoT server discovered by querying for "_dns.resolver.arpa": </ins> 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",