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

From: Klaus Frank <[email-masked]>
Date: Mon, 14 Feb 2022 08:53:57 +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: Vladimír Čunát <[email-masked]>
Date: Mon, 14 Feb 2022 12:53:37 +0100

Hello.

To me, the proposed "MUST rewrite [the SPF record]" certainly feels too 
strong.  I also wonder if there are some other problematic cases, as SPF 
certainly isn't the only common DNS record that can embed IPv4 address(es).

--Vladimir

---

From: Klaus Frank <[email-masked]>
Date: Mon, 14 Feb 2022 13:54:44 +0000

Hi,

which other common DNS records are there? Within the discussions on the 
spfbis and behave nobody named others that were specified within any 
other RFC we only had the case of someone putting arbitrary IPs within 
the TXT record for other reason. And we come to the conclusion that we 
should just ignore these as they're not within another RFC.

Also this document is specifically for the interoperability of SPF with 
DNS64, therefore I think the MUST within it is appropriate. One 
implementing DNS64 may opt to also implement this document or to stick 
with the existing RFC alone.

Sincerely,
Klaus Frank

On 2022-02-14 12:53, Vladimír Čunát wrote:
> Hello.
>
> To me, the proposed "MUST rewrite [the SPF record]" certainly feels 
> too strong.  I also wonder if there are some other problematic cases, 
> as SPF certainly isn't the only common DNS record that can embed IPv4 
> address(es).
>
> --Vladimir
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "John Levine" <[email-masked]>
Date: 14 Feb 2022 13:30:29 -0500

It appears that Klaus Frank  <[email-masked]> said:
>I wrote an I-D for updating DNS64 to better work for MTA operators. ...

I strongly oppose this ill-considered proposal.  For one thing, it is very
rare for people to try to run mail servers behind DNS64.  SPF is fifteen
years old, and this is the first time anyone has brought up this issue.

For another, trying to guess which TXT records are SPF records and
rewriting them on the fly is unreliable and dangerous. The rewritten
record would always be larger than the original. If the rewritten
string exceeds the size limit of a text string or txt record, then
what?

But most importantly, there is a simple and reliable way to deal with
this issue. When an SPF library recognizes a NAT64 address, which it
can easily do with the method in RFC 8880, it turns the address back
into the equivalent IPv4 address and uses that in the SPF validation.
This will always produce the correct result, and needs no change to
existing standards. Having worked on a few SPF libraries, I can say
these changes would not be hard for anyone with a modest familiarity
with the code.

We've explained this several times already, dunno why we have to do so again.

R's,
John

>-=-=-=-=-=-
>[Attachment type=application/pkcs7-signature, name=smime.p7s]
>-=-=-=-=-=-

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 14 Feb 2022 13:49:00 -0500

With no DNS hats

I am against this proposal.  Mr Levine did a fine summary I concur with.

tim

(again, no DNS hats)

On Mon, Feb 14, 2022 at 1:31 PM John Levine <[email-masked]> wrote:

> >URL:
> https://www.ietf.org/archive/id/draft-frank-dns64-spf-extension-03.txt
> >Diff:
> https://www.ietf.org/rfcdiff?url2=draft-frank-dns64-spf-extension-03
> >
> >Abstract:

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Feb 2022 14:37:23 -0500

> I am against this proposal.  Mr Levine did a fine summary I concur with.

Same. Also hatless.

---

From: Klaus Frank <[email-masked]>
Date: Mon, 14 Feb 2022 19:50:30 +0000

Hi,

yes there was discussion on the mailing list already. It wasn't however 
that clear on what side should implement it. Also DNS64 already does the 
IP rewrite. Therefore it's just reasonable and logical that it should be 
the part that has to consider other RFCs that put IP addresses into 
other DNS records...

Also the size limit isn't an issue. As that size is just a 
recommendation and it includes *ALL* TXT records together. Therefore 
e.g. google.com already exceeds it. And the same behavior would be 
necessary here. So nothing special needed here. e.g. the DNS64 resolver 
sets the Truncated Message bit in it's response and the client is 
retrying the query via TCP and gets it's answer that way.

Also as people pointed out. SPF is a clearly formulated standard that 
could easily be found within the data of the TXT record. It's not about 
guessing. It's a clear search and replace/insert. No guessing involved.

And to the 15 years argument. SPF hasn't been widely used the whole 
time. It wasn't really necessary before 2016. It just increased in 
recent years by demand of some big players. Also the IPv6 adoption was 
never as high as it's currently (in 2016 it was below 15% globally 
according to statistics from google). And therefore the reliance on this 
and this kind of issue will only increase and not decrease until IPv4 is 
completely gone. It'd be also better to allow people to go single stack 
IPv6 then forcing them to stay dual stack which would just lead to 
people pushing out the adoption of IPv6 as they'd still have to care 
about IPv4 and IPv4 related issues anyway.

I think this I-D is an important step towards allowing people to go 
IPv6-only and not needing to dual stack their hosts. And regarding just 
updating the SPF resolver itself, it would be very messy to demand the 
SPF resolver to do it. Also as DNS64 already leads to the assumptions 
that it "fixes DNS to act as if everything is IPv6 capable" it's just 
reasonable to also have it update the SPF records within DNS and maybe 
even allow other rewrites of the same kind. Currently there is a "MUST 
NOT rewrite any other records" within that RFC that prevents such 
solutions. One may hate DNS64 for injecting IPv6 addresses into the 
answers to the queries but it's clear that it should be the component 
that gets updated to accommodate other standard track RFCs for 
compatibility. As it's the one that aims to fix these kinds of issues 
already.

I really want you to consider the implications of putting the burden 
onto the SPF implementation here. Esp. the kind of confusion it'll cause 
when admins try to debug such a setup later and don't see the rewritten 
IPs within the SPF records. It's a reasonable assumption for that to get 
rewritten as well. Please seriously consider this. And if you after that 
still prefer that the SPF record shouldn't be updated to align with that 
assumption I'm open to replace this I-D with another one that updates 
the SPF RFC to include the lookup of the NAT64 prefix. But until now I 
just have the feeling that some people are just against DNS64 itself and 
therefore try to avoid the discussion.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Feb 2022 10:47:23 +1100

> On 15 Feb 2022, at 06:50, Klaus Frank <[email-masked]> wrote:
> 
> Hi,
> 
> yes there was discussion on the mailing list already. It wasn't however that clear on what side should implement it. Also DNS64 already does the IP rewrite. Therefore it's just reasonable and logical that it should be the part that has to consider other RFCs that put IP addresses into other DNS records...
> 
> Also the size limit isn't an issue. As that size is just a recommendation and it includes *ALL* TXT records together. Therefore e.g. google.com already exceeds it. And the same behavior would be necessary here. So nothing special needed here. e.g. the DNS64 resolver sets the Truncated Message bit in it's response and the client is retrying the query via TCP and gets it's answer that way.
> 
> Also as people pointed out. SPF is a clearly formulated standard that could easily be found within the data of the TXT record. It's not about guessing. It's a clear search and replace/insert. No guessing involved.
> 
> And to the 15 years argument. SPF hasn't been widely used the whole time. It wasn't really necessary before 2016. It just increased in recent years by demand of some big players. Also the IPv6 adoption was never as high as it's currently (in 2016 it was below 15% globally according to statistics from google). And therefore the reliance on this and this kind of issue will only increase and not decrease until IPv4 is completely gone. It'd be also better to allow people to go single stack IPv6 then forcing them to stay dual stack which would just lead to people pushing out the adoption of IPv6 as they'd still have to care about IPv4 and IPv4 related issues anyway.
> 
> I think this I-D is an important step towards allowing people to go IPv6-only and not needing to dual stack their hosts. And regarding just updating the SPF resolver itself, it would be very messy to demand the SPF resolver to do it. Also as DNS64 already leads to the assumptions that it "fixes DNS to act as if everything is IPv6 capable" it's just reasonable to also have it update the SPF records within DNS and maybe even allow other rewrites of the same kind. Currently there is a "MUST NOT rewrite any other records" within that RFC that prevents such solutions. One may hate DNS64 for injecting IPv6 addresses into the answers to the queries but it's clear that it should be the component that gets updated to accommodate other standard track RFCs for compatibility. As it's the one that aims to fix these kinds of issues already.
> 
> I really want you to consider the implications of putting the burden onto the SPF implementation here. Esp. the kind of confusion it'll cause when admins try to debug such a setup later and don't see the rewritten IPs within the SPF records. It's a reasonable assumption for that to get rewritten as well. Please seriously consider this. And if you after that still prefer that the SPF record shouldn't be updated to align with that assumption I'm open to replace this I-D with another one that updates the SPF RFC to include the lookup of the NAT64 prefix. But until now I just have the feeling that some people are just against DNS64 itself and therefore try to avoid the discussion.

You literally can’t achieve what you want to in the resolver.  The a: and mx: mechansims will not work for IPv4
connections from dual stack clients as the DNS64 synthesis of AAAA records does not trigger if there are AAAA
records present. The SPF libraries will see connections from AAAA address that are not matched by the records
AAAA records returned by the resolver.

The whole concept is dead in the water from what I can see.

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

---

From: Richard Clayton <[email-masked]>
Date: Tue, 15 Feb 2022 01:42:01 +0000

In message <[email-masked]>, Klaus Frank
<[email-masked]> writes

>time. It wasn't really necessary before 2016.

the first statement is untrue, the second should say "It has never been
necessary at all."

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Feb 2022 13:03:27 +1100

> On 15 Feb 2022, at 10:47, Mark Andrews <[email-masked]> wrote:
> 
>> 

If you want to continue to use DNS64 then you need the MTA or the SPF library to reverse the NAT64 encoding.

If you want to use a MTA and SPF library that is not DNS64 aware you will need to some sort of encapsulation
(DS-Lite, MAP-E, or any other 4in6 mechanism) or perform reverse translation (464XLAT, MAP-t) to present IPv4
connection to the MTA.

DNS64 was designed for IPv6 clients to connect to IPv4 servers iff there where not AAAA records present for
the name.  It was NOT designed to handle address literals.  It is the wrong tool for this purpose.  Since you
will need to setup specific forwarding for inbound connections to work you shouldn’t be limited to just NAT64
inbound.

Mark

---

From: Klaus Frank <[email-masked]>
Date: Tue, 15 Feb 2022 08:06:14 +0000

>> The whole concept is dead in the water from what I can see.
You're making a good point here. When writing this I-D I had the (maybe 
incorrect) assumption that when the sender is dual-stack that it will 
never send via its IPv4 address towards another dual-stack MTA but would 
always use its IPv6. I'll have to look into that.
> If you want to continue to use DNS64 then you need the MTA or the SPF library to reverse the NAT64 encoding.
If the above actually applies I'll replace the I-D with one that does 
this within the SPF validator as then it would indeed be the better 
solution. Do you by change know what WG would be best for that? It isn't 
DNSOP is it?
> will need to setup specific forwarding for inbound connections to work you shouldn’t be limited to just NAT64

I kinda disagree on that, as otherwise DNS64 also wouldn't handle 
PTR-RRs. So at least at some level such a usage was also considered. 
Also just a note, no specific forwarding (do you mean non standardized 
with that?) is needed. Just a stateless NAT46 (from public IPv4 to IPv6) 
rule is needed that assigns a Public IPv4 to the IPv6 of the MTA. And on 
the outbound connections NAT64 will then utilize stateless transitions 
for that specific source IP and everything that doesn't have a stateless 
transition assigned will go through a statefull NAT64. The IPv4 
addresses in this case would be provided by an IPv4aaS provider and not 
the cloud provider itself. This way the cloud provider network would be 
IPv6-only and IPv4 would be available where needed.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Feb 2022 08:46:22 -0500

Although the RFC does require support for PTR records, I would not assume
that DNS64 implementations all do this. It depends on whether the
implementation was done from the RFC or not, and whether the implementer
cares about this use case. I say this knowing the code of two
implementations personally, one of which does PTR synthesis, one of which
does not. I might fix the second one at some point, but despite the MUST in
the RFC, I'm not feeling any urgency about it. :]

On Tue, Feb 15, 2022 at 3:06 AM Klaus Frank <[email-masked]> wrote:

> >>> yes there was discussion on the mailing list already. It wasn't
> however that clear on what side should implement it. Also DNS64 already
> does the IP rewrite. Therefore it's just reasonable and logical that it
> should be the part that has to consider other RFCs that put IP addresses
> into other DNS records...
> >>>
> recommendation and it includes *ALL* TXT records together. Therefore e.g.
> google.com already exceeds it. And the same behavior would be necessary
> here. So nothing special needed here. e.g. the DNS64 resolver sets the
> Truncated Message bit in it's response and the client is retrying the query
> via TCP and gets it's answer that way.
> >>>
> time. It wasn't really necessary before 2016. It just increased in recent
> years by demand of some big players. Also the IPv6 adoption was never as
> high as it's currently (in 2016 it was below 15% globally according to
> statistics from google). And therefore the reliance on this and this kind
> of issue will only increase and not decrease until IPv4 is completely gone.
> It'd be also better to allow people to go single stack IPv6 then forcing
> them to stay dual stack which would just lead to people pushing out the
> adoption of IPv6 as they'd still have to care about IPv4 and IPv4 related
> issues anyway.
> >>>
> updating the SPF resolver itself, it would be very messy to demand the SPF
> resolver to do it. Also as DNS64 already leads to the assumptions that it
> "fixes DNS to act as if everything is IPv6 capable" it's just reasonable to
> also have it update the SPF records within DNS and maybe even allow other
> rewrites of the same kind. Currently there is a "MUST NOT rewrite any other
> records" within that RFC that prevents such solutions. One may hate DNS64
> for injecting IPv6 addresses into the answers to the queries but it's clear
> that it should be the component that gets updated to accommodate other
> standard track RFCs for compatibility. As it's the one that aims to fix
> these kinds of issues already.
> >>>
> when admins try to debug such a setup later and don't see the rewritten IPs
> within the SPF records. It's a reasonable assumption for that to get
> assumption I'm open to replace this I-D with another one that updates the
> SPF RFC to include the lookup of the NAT64 prefix. But until now I just
> have the feeling that some people are just against DNS64 itself and
> >> You literally can’t achieve what you want to in the resolver.  The a:
> and mx: mechansims will not work for IPv4
> >> connections from dual stack clients as the DNS64 synthesis of AAAA
> records does not trigger if there are AAAA
> >> records present. The SPF libraries will see connections from AAAA
> address that are not matched by the records
> > (DS-Lite, MAP-E, or any other 4in6 mechanism) or perform reverse
> translation (464XLAT, MAP-t) to present IPv4
> > connection to the MTA.
> >>>>> Status:
> https://datatracker.ietf.org/doc/draft-frank-dns64-spf-extension/
> >>>>> Html:
> >>>>>

---

From: "John Levine" <[email-masked]>
Date: 15 Feb 2022 11:46:43 -0500

>solution. Do you by change know what WG would be best for that? It isn't 

No it isn't.  You don't need a new I-D, you just need to make the obvious fix to your SPF library.

R's,
John