<?xml version="1.0" encoding="utf-8"?>
<rfc version="3" ipr="trust200902" submissionType="IETF" category="std" docName="draft-frank-dns64-spf-extension-00" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude">

<front>
<title abbrev="dns64-spf-extension">Extension of DNS64 (RFC6147) for SPF (RFC7208)</title>
<seriesInfo value="draft-frank-dns64-spf-extension-00" stream="IETF" status="informational" name="Internet-Draft"></seriesInfo>
<author initials="K." surname="Frank" fullname="Klaus Frank"><organization></organization><address><postal><street></street>
</postal><email>klaus.frank@posteo.de</email>
</address></author>
<date/>
<area>Application</area>
<workgroup></workgroup>
<keyword>email</keyword>

<abstract>
<t>This document describes interoperability issues and resolutions between DNS64 and SPF records for mail transfer agents.
This RFC also aims to simplify the IPv6 migration for mail transfer agent operators.</t>
<t>This document updates <xref target="RFC6147"></xref> and <xref target="RFC7208"></xref>.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>The DNS64 <xref target="RFC6147"></xref> definition causes issues for mail transfer agent operators as it failed to
consider the existance of SPF records <xref target="RFC7208"></xref>. Because of this when an SPF validator tries to
validate it'll fail because the originating NAT64 <xref target="RFC6146"></xref> IP isn't within the SPF records
allow-/denylist...
</t>
</section>

<section anchor="spf-rr-rewrite"><name>Rewriting SPF records</name>
<t>The section 5.1 of <xref target="RFC6147"></xref> gets ammended with another subsection (5.1.9):
</t>
<blockquote><t>
5.1.9. Dealing with SPF records
   If the DNS64 server receives a SPF-record (within either the TXT-RR or the SPF-RR <xref target="RFC4408"></xref>)
   containing the "ip4" mechanism, it MUST rewrites the ipv4 address according to the same rules as an A-RR and
   synthesize a new SPF record within the response that contains it as an additional "ip6" entry.
   If an ip4-cidr-length is present, it gets converted as well (adding 96 will generate the new ip6-cidr-length).
   The original "ip4" mechanism MUST NOT be removed from the response.
   If any "a" or "mx" mechanism contains a dual-cidr-length without an ip6-cidr-length, it also gets generated.
   E.g.:
      "v=spf1 a:a.example.com/24 mx:mx.example.com/24 ip4:192.0.0.1/32 -all"
      becomes:
      "v=spf1 a:a.example.com/24/120 mx:mx.example.com/24/120 ip4:192.0.0.1/32 ip6:64:ff9b::c000:1/128 -all"
   NOTE: Everything else is done by the SPF validator (as already defined in the standard).
   * When it checks a.example.com, it'll query the A-RR and AAAA-RR and thereby get a response containing
   the synthesized AAAA-RR and validation will pass accordingly.
   * When it checks the NAT64 generated IPv6 source address against the SPF, it'll find the "ip6" mechanism and
   also pass.
   * For any macro-string, the SPF validator will generate new DNS lookups, which will be rewritten according to
   this RFC and therefore pass as expected.
</t></blockquote>
</section>

<section anchor="spf-mechanism-definitions"><name>SPF Mechanism Definitions</name>
<t>The section 5.7 of <xref target="RFC7208"></xref> currently explicitely
ignores the presence of IPv6 and to future proofe it for IPv6-only it gets updated from</t>
<blockquote><t>
   This mechanism is used to construct an arbitrary domain name that is
   used for a DNS A record query.
</t></blockquote><t> to </t><blockquote><t>
   This mechanism is used to construct an arbitrary domain name that is
   used for a dual DNS A-RR and AAAA-RR query.
</t></blockquote><t>and from </t><blockquote><t>
   The &lt;domain-spec&gt; is expanded as per Section 7.  The resulting domain
   name is used for a DNS A RR lookup (even when the connection type is
   IPv6).  If any A record is returned, this mechanism matches.
</t></blockquote><t> to </t><blockquote><t>
   The &lt;domain-spec&gt; is expanded as per Section 7.  The resulting domain
   name is used for a DNS A-RR and AAAA-RR lookup, depending on when the host is single-stack IPv6
   or IPv4. For dual-stack, an SPF resolver MUST query both.
   If any A or AAAA record is returned, this mechanism matches.
</t></blockquote>
</section>

</middle>

<back>
<references><name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4408.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml"/>
</references>

</back>

</rfc>
