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

[Klaus Frank <[e-mail]>]

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.

On 2022-02-14 19:30, John Levine wrote:
> It appears that Klaus Frank  <[e-mail]> 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
>
>
>
>> 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].
>>
>>
>> -=-=-=-=-=-
>> [Attachment type=application/pkcs7-signature, name=smime.p7s]
>> -=-=-=-=-=-
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop