Internet DRAFT - draft-frank-dns64-spf-extension
draft-frank-dns64-spf-extension
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 <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
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,
<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, April 2014,
<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,
April 2011, <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, October 2010,
<https://www.rfc-editor.org/info/rfc6052>.
Author's Address
Klaus Frank
Email: draft-frank-dns64-spf-extension@frank.fyi
Frank Expires 18 August 2022 [Page 6]
