Re: [spfbis] RFC6147 and RFC7208 interoperability issues

SPF macro tricks: 
https://www.jamieweb.net/blog/using-spf-macros-to-solve-the-operational-challenges-of-spf/
I wonder how many people actually use SPF macros....

But yeah, trying to translate these is the kind of hell that should be 
reserved for full SPF library and not something DNS64 server should 
probably attempt. Looks like those who want SPF to work behind NAT64 
would have to use a library that can discovery what NAT64 prefix is and 
translate everything.

BTW, what's going on with exists and A vs AAAA? The SPF 7206 RFC says:

exists           = "exists"   ":" domain-spec

    The <domain-spec> is expanded as per Section 7 [1].  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."

How is this meant to work for those in IPv6 only world? And what will 
happen when a SPF resolver behind DNS64 tries to resolve this? Is DNS64 
just adding AAAA while preserving the A as well for an application that 
needs it?

  On 2022-02-07 14:40, Ángel wrote:

> On 2022-02-07 at 02:30 +0000, Klaus Frank wrote:
> 
>> Why? Such a query would resolve in the mailserver would make the DNS
>> lookup. The DNS64 server than would synthetically add an AAAA-RR to
>> the response.
> 
> The issue is not that the response contains an A record but that the
> queried domain embeds the remote IP.
> 
> The A result is usually a 127.0.0.x address, with some "magic" meaning
> (perhaps lost if translated into IPv6) but the main problem is querying
> the right label.
> 
> _______________________________________________
> spfbis mailing list
> spfbis@ietf.org
> https://www.ietf.org/mailman/listinfo/spfbis

Links:
------
[1] https://datatracker.ietf.org/doc/html/rfc7208#section-7