An Extension to DNS64 for Sender Policy Framework SPF Awareness

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 18 August 2022.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) function [RFC6146] 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 [RFC6052] 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 [RFC6147] specifies a companion DNS mechanism to represent IPv4-only servers in the IPv6 domain.¶

The DNS64 specification [RFC6147] causes issues for mail transfer agent operators as it does not discuss the implications on SPF records [RFC7208]. 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 [RFC6146].¶

+---------------------+         +---------------+
|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.¶

2. Updates to RFC6147: Rewriting SPF Records

Section 5.1 of [RFC6147] 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 [RFC7208]) containing the "ip4" mechanism (Section 5.6 of [RFC7208]), 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 [RFC6052].¶

NOTE: Everything else is done by the SPF validator (as already defined in the standard [RFC7208]).¶

• 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.¶

3. Updates to RFC7208: SPF "exists" Mechanism

Section 5.7 of [RFC7208] 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.¶

4. 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.¶

Author's Address