Re: [spfbis] RFC6147 and RFC7208 interoperability issues

As far as I can tell, not very many people use them, but there were enough 
that the SPFbis working group concluded they were in use and could not be 
removed.

I'm working from several year old memories, but my recollection is that since 
the DNS server receiving the query has controls how to respond, it can respond 
just fine to an A query, even if via IPv6.  This should work until IPv4 is dead 
enough that people start ripping the ability to query for A records out of DNS 
servers (or the heat death of the universe, whichever comes first).

Scott K

On Monday, February 7, 2022 6:22:13 PM EST william@leibzon.org wrote:
> SPF macro tricks:
> https://www.jamieweb.net/blog/using-spf-macros-to-solve-the-operational-chal
> lenges-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 7208 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