Re: [BEHAVE] [spfbis] RFC6147 and RFC7208 interoperability issues

[Hector Santos <[e-mail]>]

You could do a independent draft tech note to show technical details, perhaps implementation details for SPF/DNS resolvers learning about IP6 related issues and coding requirements.  

In general, when dealing with unknown Resource Records (RR), the DNS server and client SHOULD be supporting RFC 3597:

https://datatracker.ietf.org/doc/html/rfc3597 <https://datatracker.ietf.org/doc/html/rfc3597>

A small dig into RFC6147, I don’t see a reference to RFC3597.  Maybe RFC6147 should be updated as well?

See this 2012 thread I had with Microsoft when I was updating our Wildcat! SAP package  for SPF RR support in its Wildcat! DNS client and local cache resolving API logic. We are not at IP6 but it sounds DNS64/NAT64 should review its level of support for RFC3597.

https://social.technet.microsoft.com/Forums/Lync/en-US/5841e884-db22-42a1-8530-615a375662cc/dns-server-support-for-new-or-unamed-rr-type-records <https://social.technet.microsoft.com/Forums/Lync/en-US/5841e884-db22-42a1-8530-615a375662cc/dns-server-support-for-new-or-unamed-rr-type-records>


Hope any of this helps

—
HLS



> On Feb 6, 2022, at 1:09 PM, Klaus Frank <[e-mail]> wrote:
> 
> Hi,
> 
> 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.
> 
> Would it be possible to create an extension to RFC6147 that mandates SPF record rewrites as well? Otherwise Mail servers behind NAT64+DNS64 in IPv6 only environments won't be able to work as expected.
> 
> Like:
> If the DNS64 server receives a SPF-record (within either the TXT-RR or the SPF-RR [RFC4408]) containing the "ip4" mechanism it MUST rewrites the ipv4 address according to the same rules as A-records are and synthesizes a new SPF record within the response that contains additional "ip6" entries. The original "ip4" should not be removed from the response.
> 
> Sincerely,
> Klaus Frank