<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="info"
  docName="draft-bortzmeyer-add-resinfo-dnssecval-dns64-01"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3">

  <front>
    <title abbrev="Resinfo DNSSEC and DNS64">Two DNS Resolver Information Keys for DNSSEC and DNS64</title>

    <seriesInfo name="Internet-Draft" value="draft-bortzmeyer-add-resinfo-dnssecval-dns64-01"/>
   
    <author fullname="Stéphane Bortzmeyer" initials="S."
	    surname="Bortzmeyer">      
      <organization>Afnic</organization>
      <address>
        <postal>
          <street>7 avenue du 8 mai 1945</street>
          <city>Guyancourt</city>
          <code>78280</code>
          <country>FR</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>bortzmeyer+ietf@nic.fr</email>  
        <uri>https://www.afnic.fr/</uri>
      </address>
    </author>

    <author initials="F." surname="Obser" fullname="Florian Obser">
      <organization>OpenBSD</organization>
      <address>
        <email>florian+ietf@narrans.de</email>
      </address>
    </author>

    <date year="2024"/>

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>DNS DNSSEC DNS64 RESINFO</keyword>

    <abstract>
      <t>This document specifies two DNS Resolver
      Information Keys (RFC 9606) for DNSSEC validation capability,
      "dnssecval" and DNS64 synthesis, "dns64".</t>
    </abstract>
 
  </front>

  <middle>
    
    <section>
      <name>Introduction</name>
      <t>RFC 9606 specifies a DNS resource record (RR) type RESINFO to
      allow resolvers to publish information about their capabilities
      and policies. This information is encoded as {key, value}
      pairs, with each information is unambiguously identified with a
      key. Keys are maintained in an IANA registry. This specification adds
      two new keys.</t>
      <t>The first one indicates that the resolver validates with
      DNSSEC <xref target="RFC4033"/><xref target="RFC4034"/><xref
      target="RFC4035"/>. Such key may be used, for example, by a DNS
      client to prefer resolvers that enable DNSSEC validation.</t>
      <t>The second key is used for DNS64. DNS64 <xref target="RFC6147"/>
      is performed by a DNS resolver together with NAT64 <xref
      target="RFC6146"/> to allow an IPv6-only client to initiate
      communications by name to an IPv4-only server. The new key can
      be used to inform DNS clients that DNS64 is performed by the DNS
      resolver.</t>
      <t>Note that, per the rules for the keys
      defined in Section 6.4 of <xref target="RFC6763"/> if there is
      no '=' in a key, then it is a boolean attribute, simply
      identified as being present, with no value. The two keys are
      therefore simple booleans.</t>

      <section>
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
          "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
          RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
          interpreted as described in BCP 14 <xref target="RFC2119"/>
          <xref target="RFC8174"/> when, and only when, they appear in
          all capitals, as shown here.</t>
      </section>

    </section>
    
    <section>
      <name>The key "dnssecval"</name>
      <t>The name of the key is "dnssecval", for "DNSSEC validating
      [resolver]". The presence of this key indicates that the DNS
      resolver validates all answers with DNSSEC <xref
      target="RFC4033"/> <xref target="RFC4034"/> <xref
      target="RFC4035"/>.</t>
      <t>A resolver that announces this capability in a RESINFO record
      MAY add DNSSEC-specific EDE (Extended DNS Error Codes, <xref
      target="RFC8914"/>) to the value of the "exterr" key, e.g.,
      "Unsupported DNSKEY Algorithm", "Unsupported DS Digest Type",
      and "DNSSEC Bogus". Refer to the "Extended DNS Error Codes"
      registry for a definitive list of these EDEs.</t>
    </section>

    <section>
      <name>The key "dns64"</name>
      <t>The name of the key is simply "dns64". The presence of this
      key indicates that the DNS resolver performs address
      synthesis. A resolver which supports <xref target="RFC9606"/>
      SHOULD add the dns64 key if it performs DNS64 <xref
      target="RFC6147"/> address synthesis.</t>
    </section>
    
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>This document requests IANA to add the key "dnssecval", with
      the explanation text "The presence of the key name indicates that
      DNSSEC validation is enabled", and a reference to this
      document to the registry "DNS Resolver Information Keys" under
      the "Domain Name System (DNS) Parameters" registry group.</t>
      <t>This document requests IANA to add the key "dns64", with the
      explanation text "The presence of the key indicates that DNS64
      address synthesis is performed", and a reference to this
      document to the registry "DNS Resolver Information Keys" under
      the "Domain Name System (DNS) Parameters" registry group.</t>
      <table>
	<thead>
	<tr>
        <th>Name</th>
        <th>Description</th>
        <th>Reference</th>
	</tr>
	</thead>
	<tbody>
	<tr>
        <td>dnssecval</td>
        <td>The presence of the key name indicates that DNSSEC validation is enabled.</td>
        <td>RFC EDITOR: replace : This_Document</td>
	</tr>
	<tr>
        <td>dns64</td>
        <td>The presence of the key indicates that DNS64 address
        synthesis is performed</td>
        <td>RFC EDITOR: replace : This_Document</td>
	</tr>
	</tbody>
      </table>
    </section>
    
    <section anchor="Security">
      <name>Security Considerations</name>
      <t>DNSSEC is a very important tool for the security of the DNS. Therefore it is important for users to know in advance whether
      the resolver they consider supports DNSSEC. It would be
      better to assume that every resolver validates (thus rendering
      this document useless) but it is not the case today.</t>
      <t>Using the RESINFO mechanism solely to inform clients about
      the presence of DNS64 without conveying any prefix information
      avoids the security problems of <xref target="RFC7050"/>.</t>
      <t>As with any information published in the DNS, the keys in the
      RESINFO may be wrong or outdated. They should be regarded with
      care. The security considerations discussed in Section 7 of
      <xref target="RFC9606"/> apply.</t>
    </section>
    
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        
        <xi:include
            href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include
            href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/>
        <xi:include
            href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9606.xml"/>
        
      </references>
 
      <references>
        <name>Informative References</name>
        <xi:include
            href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
        <xi:include
            href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
        <xi:include
            href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
        <xi:include
	    href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/>
        <xi:include
	    href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"/>
        <xi:include
	    href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7050.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8914.xml"/>	
      </references>
    </references>

    <section>
      <name>Discussions and alternatives</name>
      <t>To be deleted before publication.</t>
      <t>It has been proposed to turn "dnssecval" from a boolean into
      a key with value (<xref target="RFC9606"/>, section 4) to
      indicate different ways to do DNSSEC validation. For instance,
      the PowerDNS resolver has several levels of validation, see
      <eref
	  target="https://doc.powerdns.com/recursor/dnssec.html"/>. At
      the present stage, it is the opinion of the authors that such
      detailed information is both difficult to standardize (different
      resolvers have different knobs to turn) and difficult o use since the
      typical consumer will have difficulty understanding them.</t>
      <t>This draft does not suggest what to do with the information
      provided, it is up to the consumer. This is inline with <xref
      target="RFC9606"/>, which goal is to provide information, not
      guidance.</t>
    </section>


    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>Original idea by Marco Davids.</t>
    </section>
    
 </back>
</rfc>
