Subject: [v6ops] I-D An Extension to DNS64 for Sender Policy Framework SPF Awareness

From: Klaus Frank <[email-masked]>
Date: Mon, 14 Feb 2022 08:53:20 +0000

Hi,

I wrote an I-D for updating DNS64 to better work for MTA operators. I'd 
like to get your opinions on that as some guidance on how to move 
forward with it (sorry I'm new to the process). Some background for this 
we had some issues with SPF and a mail server that was behind 
NAT64+DNS64. I at first thought that it was just a misconfiguration. But 
after the DNS64 server seamed to work as intended I went to the 
implementation and the RFC. Thereby while reading RFC6147 I stumbled 
across section 5.3.3 which says "All other RRs MUST be returned 
unchanged." which is the cause of my issues. This section is basically 
ignoring SPF records (RFC7208 section 5.6) and also preventing DNS64 
implementations from addressing this limitation themselves. After some 
discussion on the behave and spfbis mailing list I created this I-D. I 
was referred to this mailing list as both the behave as well as the 
spfbis WG are closed.

GitHub: 
https://github.com/agowa338/IETF-RFC-drafts/blob/main/draft-frank-dns64-spf-extension-03.xml

Sincerely,
Klaus Frank

Name:        draft-frank-dns64-spf-extension
Revision:    03
Title:        An Extension to DNS64 for Sender Policy Framework SPF 
Awareness
Document date:    2022-02-14
Group:        Individual Submission
Pages:        6
URL: https://www.ietf.org/archive/id/draft-frank-dns64-spf-extension-03.txt
Status: https://datatracker.ietf.org/doc/draft-frank-dns64-spf-extension/
Html: 
https://www.ietf.org/archive/id/draft-frank-dns64-spf-extension-03.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-frank-dns64-spf-extension
Diff: https://www.ietf.org/rfcdiff?url2=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].

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Feb 2022 14:48:37 +1100

As I noted in dnsops, there is no way for the DNS64 resolver to achieve the aims of this draft when the SMTP client
is dual stacked.  Handling a: and mx: methods depend on A’s being mapped to AAAA which does not happen for dual
stacked clients with DNS64.  The presence of the AAAA records will stop AAAA’s being synthesised from A records.

Mark

> On 14 Feb 2022, at 19:53, Klaus Frank <[email-masked]> wrote:
> 
> Hi,
> 
> I wrote an I-D for updating DNS64 to better work for MTA operators. I'd like to get your opinions on that as some guidance on how to move forward with it (sorry I'm new to the process). Some background for this we had some issues with SPF and a mail server that was behind NAT64+DNS64. I at first thought that it was just a misconfiguration. But after the DNS64 server seamed to work as intended I went to the implementation and the RFC. Thereby while reading RFC6147 I stumbled across section 5.3.3 which says "All other RRs MUST be returned unchanged." which is the cause of my issues. This section is basically ignoring SPF records (RFC7208 section 5.6) and also preventing DNS64 implementations from addressing this limitation themselves. After some discussion on the behave and spfbis mailing list I created this I-D. I was referred to this mailing list as both the behave as well as the spfbis WG are closed.
> 
> GitHub: https://github.com/agowa338/IETF-RFC-drafts/blob/main/draft-frank-dns64-spf-extension-03.xml
> 
> Sincerely,
> Klaus Frank
> 
> Title:        An Extension to DNS64 for Sender Policy Framework SPF Awareness
> Html: https://www.ietf.org/archive/id/draft-frank-dns64-spf-extension-03.html
> Htmlized: https://datatracker.ietf.org/doc/html/draft-frank-dns64-spf-extension
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]