diff --git a/draft-ietf-add-resolver-info.md b/draft-ietf-add-resolver-info.md
index 895e45b..e3e9e4e 100644
--- a/draft-ietf-add-resolver-info.md
+++ b/draft-ietf-add-resolver-info.md
@@ -109,17 +109,7 @@ Encrypted DNS resolver:
    If the Special-Use Domain Name "resolver.arpa", defined in
    {{!RFC9462}}, is used to discover an encrypted DNS resolver, the
    client can retrieve the resolver information using the RESINFO RR
-   type and QNAME of "resolver.arpa".  If a resolver supports DDR
-   but does not support RESINFO, the client can receive a positive RESINFO
-   response from a legitimate upstream DNS resolver or an attacker. While DNSSEC can be considered as a candidate mechanism
-   to protect against the attack, it is important to note that DNSSEC protection is not possible with
-   "resolver.arpa" due to the lack of uniqueness. To prevent such an attack,
-   resolvers supporting DDR MUST convey the "sig" attribute as defined in {{key-val}}. DNS clients
-   using DDR for encrypted resolver discovery querying for a RESINFO RR MUST validate the signature
-   in the "sig" attribute for data origin authentication using the public key
-   in the certificate, including ensuring that the certificate contains
-   the IP address that DDR uses for validation as per {{Section 4.2 of RFC9462}}.
-   If the signature validation fails, the DNS client MUST reject the RESINFO RR.
+   type and QNAME of "resolver.arpa".
 
 #  Format of the Resolver Information {#format}
 
@@ -185,17 +175,6 @@ Encrypted DNS resolver:
       This is an optional attribute.  For example, a DoT server may
       not want to host an HTTPS server.
 
-   sig:
-   : It contains the signature of the RESINFO RR excluding the "sig"	
-     attribute.  The signature is generated by the encrypted DNS
-     resolver using all of the attributes in the RESINFO RR except the "sig"	attribute.
-     The signature algorithm MUST be compatible with the public key in the DNS resolver's
-     end-entity certificate.  As a	reminder, the server's end-entity certificate's
-     public key will be	compatible with the selected authentication algorithm from
-     the	client's "signature_algorithms" TLS extension ({{Section 4.4.2.2 of !RFC8446}}).
-
-     This is an optional attribute.
-
    New keys can be defined as per the procedure defined in {{key-reg}}.
 
    {{ex-1}} shows an example of a published resolver information record:
@@ -207,14 +186,19 @@ resolver.example.net. 7200 IN RESINFO qnamemin exterr=15,16,17
 {: #ex-1 title='An Example of Resolver Information Record' artwork-align="center"}
 
 
-#  Security Considerations
+#  Security Considerations {#security}
+
+To be considered authenticated, a RESINFO response MUST meet one of the following conditions:
+
+1. It appears in the Authority section of a response from the resolver it describes.
+2. It is accompanied by a valid DNSSEC signature.
+3. It appears in the Answer section of a response with DNSSEC OK set to 1 from a trusted resolver over a secure channel.
 
-To prevent DNS response forgery attacks, DNS clients using DNR MUST employ one of the following measures:
+The authentication provided under conditions 1 and 3 is limited by the DNS transport.  Use of these conditions with insecure transports NOT RECOMMENDED, but may be appropriate in low-risk use cases.  Note that of these conditions, only condition 1 can apply to queries for "resolver.arpa".
 
-1. Establish an authenticated secure connection to the DNS resolver.
-2. Implement local DNSSEC validation ({{Section 10 of ?RFC8499}}) to verify the authenticity of the resolver information.
+If a RESINFO record is not authenticated, it could have been injected by a party who does not otherwise control the resolution process (i.e., an attacker).
 
-In order to prevent DNS response forgery attacks, DNS clients using DDR MUST perform the validation explained in {{retreive}} for data origin authentication of RESINFO RR.
+Even if a RESINFO response is authenticated, the correctness of the RESINFO contents cannot be verified.  When connecting to an untrusted resolver, clients MUST account for the possibility that the RESINFO record contains false claims about the server.
 
 #  IANA Considerations