An Extension to DNS64 for Sender Policy Framework SPF Awareness

Introduction Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) function is widely deployed, especially in cellular networks. But also in datacenters that aim to simplify the problems of dualstack operations utilize it. There it's used to allow IPv6-only servers to access the IPv4 internet and be reachable by the IPv4 network without having an IPv4 stack on the own servers. Such a function is solicited when an IPv6-only host communicates with an IPv4-only server. In such context, IPv4-only servers are represented in the IPv6 domain by synthesizing IPv6 addresses based on IPv4 addresses. The address translation algorithm defined in uses a dedicated IPv6 prefix that usually is the Well-Known Prefix (i.e. 64:ff9b::/96) or a Network Specific Prefix (NSP). For better application compatibility NSP is usually only used in transit only. DNS64 specifies a companion DNS mechanism to represent IPv4-only servers in the IPv6 domain. The DNS64 specification causes issues for mail transfer agent operators as it does not discuss the implications on SPF records . Therefore, and assuming a NAT64 is present on the path, when an SPF validator tries to validate, the validation will fail because the originating IP address it sees is no longer within the SPF records allow-/denylist as it got rewritten by NAT64 .

+---------------------+ +---------------+ |IPv6 network | | IPv4 | | | +-------------+ | network | | |--| Name server |--| | | | | with DNS64 | | +----+ | | +----+ | +-------------+ | | MTA| | | | MTA|---| | | +----+ | | +----+ | +-------+ | 192.0.2.1 | |2001:db8::1|------| NAT64 |----| | | | +-------+ | | | | | | | +---------------------+ +---------------+ Figure 1 shows a minimal sample deployment. The DNS server utilizing DNS64 may be anywhere including at publicly provided as long as the NAT64 is using the Well-Known-Prefix.

+---------------------------------+ | | | +---+ +-------+ | |MTA| 192.0.2.1 |Border | +--------+ | +---+ |Gateway+-+IPv4aaS | |Sender/Recipient |IPv4 | |(NAT64) | +-------------------------+-------+ +--+-----+ | +-------------------------+-------+ | | |Border | +--+-----+ | |Gateway| |IPv6 | | +-------------+ +---+IPv6 +-+Internet| | | 2001:db8::1 | | +-------+ +-+------+ | | +---+ +--++----+-+ | | | | |MTA+----+GW||SD WAN| | | | | +---+ +--++----+-+ | | | |Customer A | | +-----+ | +-+----+ | |(IPv6 only) | +---+DNS64| | |Public| | +-------------+ +-----+ | |DNS64 | |Cloud Provider Space | +------+ +---------------------------------+ As Figure 1 may be a bit too abstract for some to imagine how a real-world deployment may look like Figure 2 shows a cloud provider with a single stack IPv6 network utilizing an IPv4aaS (IPv4 as a service) from another provider. IPv4 as a Service in this example refers to a NAT64 that is managed by someone else and reachable via e.g. private peering. It may be provided by the data center or the cloud provider itself. The IPv4aaS may offer additional services that a customer can book, like reverse mapping e.g. a dedicated IPv4 for outbound traffic. Also, for this deployment, the placement of the Name Server offering the DNS64 is irrelevant as long as the Well-Known-Prefix is used.

Terminology 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 [RFC2119],[RFC8174] when, and only when, they appear in all capitals, as shown here. The reader should be familiar with the terms defined in and

Updates to RFC6147: Rewriting SPF Records Section 5.1 of is updated with this new subsection. NEW:

5.1.9. Handling SPF Records If the DNS64 server receives a SPF-record (within the TXT-RR ) containing the "ip4" mechanism (Section 5.6 of ), it MUST rewrite 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"). This example uses the Well-Known Prefix defined in . NOTE: Everything else is done by the SPF validator (as already defined in the standard ).

When it checks a.example.com, it queries the A-RR and AAAA-RR and, thereby, gets a response containing the synthesized AAAA RR and validation will pass accordingly.

When it checks the NAT64 generated IPv6 it sees as source address against the SPF, it'll find the "ip6" mechanism DNS64 inserted and also pass.

For any macro-string, the SPF validator will generate new DNS lookups, which will be rewritten according to this document and therefore pass as the validation checks.

Updates to RFC7208: SPF "exists" Mechanism Section 5.7 of currently explicitly ignores the presence of IPv6 and to future proof it for IPv6-only it gets updated as follows: OLD:

This mechanism is used to construct an arbitrary domain name that is used for a DNS A record query.

NEW:

This mechanism is used to construct an arbitrary domain name that is used for a query to both DNS A RR and AAAA RR.

OLD:

The <domain-spec> 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.

NEW:

The <domain-spec> is expanded as per Section 7. The resulting domain name is used for DNS A RR and AAAA RR lookups. If any A or AAAA record is returned, this mechanism matches.

Contributors and Acknowledgements A special thanks goes to everyone participating in the discussion on the mailing lists as well as Mohamed Boucadair for proofreading, suggested changes, and helping with the submission process itself.