Network Working Group K. Frank Internet-Draft 14 February 2022 Updates: RFC6147, RFC7208 (if approved) Intended status: Standards Track Expires: 18 August 2022 An Extension to DNS64 for Sender Policy Framework SPF Awareness draft-frank-dns64-spf-extension-03 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. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Frank Expires 18 August 2022 [Page 1] Internet-Draft dns64-spf-extension February 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Updates to RFC6147: Rewriting SPF Records . . . . . . . . . . 4 3. Updates to RFC7208: SPF "exists" Mechanism . . . . . . . . . 5 4. Contributors and Acknowledgements . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 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]. Frank Expires 18 August 2022 [Page 2] Internet-Draft dns64-spf-extension February 2022 +---------------------+ +---------------+ |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 Frank Expires 18 August 2022 [Page 3] Internet-Draft dns64-spf-extension February 2022 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. | Frank Expires 18 August 2022 [Page 4] Internet-Draft dns64-spf-extension February 2022 | * 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 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 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 Frank Expires 18 August 2022 [Page 5] Internet-Draft dns64-spf-extension February 2022 [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, April 2011, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . 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, April 2011, . [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, . Author's Address Klaus Frank Email: draft-frank-dns64-spf-extension@frank.fyi Frank Expires 18 August 2022 [Page 6]