DDR/DNR RFCs

draft-ietf-add-resolver-info.md

@@ -64,8 +64,8 @@ informative:
    services, means to help stub resolvers to identify the capabilities of
    resolvers are valuable.  Typically, stub resolvers can discover
    and authenticate encrypted DNS resolvers provided by a local network,
-   for example, using the Discovery of Network-designated Resolvers (DNR) {{!I-D.ietf-add-dnr}} and the Discovery of Designated Resolvers (DDR)
-   {{!I-D.ietf-add-ddr}}.  However, these stub resolvers need a mechanism to
+   for example, using the Discovery of Network-designated Resolvers (DNR) {{!RFC9463}} and the Discovery of Designated Resolvers (DDR)
+   {{!RFC9462}}.  However, these stub resolvers need a mechanism to
    retrieve information from the discovered recursive resolvers about
    their capabilities.
 
@@ -104,10 +104,10 @@ Encrypted DNS resolver:
 
    A DNS client can retrieve the resolver information using the RESINFO
    RR type and the QNAME of the domain name that is used to authenticate the
-   DNS resolver (referred to as the Authentication Domain Name (ADN) in {{!I-D.ietf-add-dnr}}).
+   DNS resolver (referred to as the Authentication Domain Name (ADN) in {{!RFC9463}}).
 
    If the Special-Use Domain Name "resolver.arpa", defined in
-   {{!I-D.ietf-add-ddr}}, is used to discover an encrypted DNS resolver, the
+   {{!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
@@ -118,7 +118,7 @@ Encrypted DNS resolver:
    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 I-D.ietf-add-ddr}}.
+   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.
 
 #  Format of the Resolver Information {#format}