Internet-Draft dns64-spf-extension February 2022
Frank Expires 18 August 2022 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-frank-dns64-spf-extension-02
Updates:
RFC6147, RFC7208 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Author:
K. Frank

An Extension to DNS64 for Sender Policy Framework SPF Awareness

Abstract

This document describes interoperability issues and resolutions between DNS64 and SPF records for mail transfer agents. This document also aims to simplify the IPv6 migration for mail transfer agent operators.

This document updates [RFC6147] and [RFC7208].

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.

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: Figure 1: Sample Deployment (RFC6146) with MTAs

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             | +------+
+---------------------------------+
Figure 2: Figure 2: Sample Deployment for cloud provider

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.

1.1. 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 [RFC6147] and [RFC7208]

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.

5. References

5.1. Normative References

[RFC6147]
Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, , <https://www.rfc-editor.org/info/rfc6147>.
[RFC7208]
Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, , <https://www.rfc-editor.org/info/rfc7208>.

5.2. Informative References

[RFC6146]
Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, , <https://www.rfc-editor.org/info/rfc6146>.
[RFC6052]
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, , <https://www.rfc-editor.org/info/rfc6052>.

Author's Address

Klaus Frank

mirror server hosted at Truenetwork, Russian Federation.