Re: [spfbis] RFC6147 and RFC7208 interoperability issues

On 2022-02-07 15:31, Klaus Frank wrote:

> On 2022-02-08 00:22, william@leibzon.org wrote:
> 
>> 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....
> We don't have to. This is all done by the SPF library and we just need 
> to care about the DNS requests it'll perform because of this. The new 
> dns queries are also SPF records. And also start with "v=spf1 ", so no 
> problems as long as we'd rewrite all ip4's within it and that's the 
> same as we'd already do anyway. Therefore no change to macros needed.

The macros don't need to be changed if the library knows real IPv4 
address. Otherwise there would be an issue with:

%{ir}.%{v}._spf.%{d2}
       3.2.0.192.in-addr._spf.example.com

which when an ip address of connecting server is IPv6 is translated as:

%{ir}.%{v}._spf.%{d2}

1.0.b.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6._spf.example.com

I wonder if there even are people doing ip6 exist macros... More likely 
people forgot about this if they are ip4, ip6 dual stack.

>> 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 perSection 7  
>> <https://datatracker.ietf.org/doc/html/rfc7208#section-7>.  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?
> IPv4 records are preserved. But yea, it was already noted in the 
> discussion that that part is a minor problematic.
> 
> Here is a DNS64 resolver from cloudflare if you want to try it 
> yourself: 2606:4700:4700::64
> 
> 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

_______________________________________________
spfbis mailing list
spfbis@ietf.org
https://www.ietf.org/mailman/listinfo/spfbis
_______________________________________________
spfbis mailing list
spfbis@ietf.org
https://www.ietf.org/mailman/listinfo/spfbis