Re: [spfbis] RFC6147 and RFC7208 interoperability issues

[Klaus Frank <[e-mail]>]

On 2022-02-08 00:22, [e-mail] 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.
>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spfbis
>
> _______________________________________________
> spfbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spfbis