Subject: [spfbis] RFC6147 and RFC7208 interoperability issues

From: Klaus Frank <[email-masked]>
Date: Sun, 6 Feb 2022 18:09:13 +0000

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

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 06 Feb 2022 13:25:11 -0500

> additional "ip6" entries. The original "ip4" should not be removed from

What's preventing the SPF record publisher from solving this problem by adding 
the ip6: mechanisms themselves?  Perhaps I don't understand the issue you are 
raising.  Would you please clarify what it is you're asking be done that an 
administrator can't do on their own?

Scott K

---

From: Klaus Frank <[email-masked]>
Date: Sun, 6 Feb 2022 18:31:06 +0000

Hi,

the DNS64 record is a syntetic dns record that is created by the 
resolver to fill in a missing AAAA-RR for responses to make the IPv4 
internet reachable from IPv6 only networks. Basically the issue is that 
the recipient admin would have to make a change on the sending domains 
side depending on the recipients infrastructure.

Sincerely,
Klaus Frank

On 2022-02-06 19:25, Scott Kitterman wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 6 Feb 2022 13:35:40 -0500

> Le 6 févr. 2022 à 13:09, Klaus Frank <[email-masked]> a écrit :
> 
> 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.

I agree there is a problem. However, I can think of “interesting” problems to solve, like: what if the ip4 contains a prefix, like 192.168.1.0/25. How would you translate this into IPv6 prefix by the DNS-64?

Marc.

---

From: Klaus Frank <[email-masked]>
Date: Sun, 6 Feb 2022 18:39:28 +0000

> I agree there is a problem. However, I can think of “interesting” problems to solve, like: what if the ip4 contains a prefix, like 192.168.1.0/25. How would you translate this into IPv6 prefix by t…
Literally, your address of 192.168.1.0 would be e.g. ::ffff:c0a8:0100 
and the prefix would just be 25+96

---

From: [email-masked]
Date: Sun, 06 Feb 2022 10:55:02 -0800

This is like NAT where entirety of DNS is re-written to make internet 
appear to be IPV6 only. So yes, SPF records would be an issue then.

There is more than one way to solve it. The proposal to re-write SPF is 
probably the most correct way within context of NAT64-DNS64. The other 
option would be to update SPF specifying that validating servers on IPv6 
only network can use IPv4 spf records for validation if the ip address 
of connecting mail server is a mapped IPv4->IPv6. That is far less 
elegant though.

BTW, I bet SPF is not going to be the only protocol with these types of 
issues. How about SIEVE? Have you checked how well NAT64 inter-operates 
with that?

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 06 Feb 2022 13:58:54 -0500

> side depending on the recipients infrastructure.

Thanks.  So this would apply to any DNS record that contains an IP address 
(IPv4) and RFC 6147 addresses A?  This would affect PTR lookups too, right (not 
the SPF PTR mechanism, but when a receiving mail sever does a PTR lookup on 
the connect address to see if it matches the EHLO name)?

Scott K

> > What's preventing the SPF record publisher from solving this problem by
> > adding the ip6: mechanisms themselves?  Perhaps I don't understand the
> > issue you are raising.  Would you please clarify what it is you're asking
> > be done that an administrator can't do on their own?
> > 
> > Scott K
> > 
> >

---

From: Klaus Frank <[email-masked]>
Date: Sun, 6 Feb 2022 19:08:05 +0000

Yes, exactly. Every DNS entry that doesn't have an AAAA-RR will get one 
by DNS64 generated using the configured NAT64 prefix and the A-RR.
This also covers the PTR-RRs.

 From RFC6147 5.3.1:

    If a DNS64 server receives a PTR query for a record in the IP6.ARPA
    domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the
    address portion of the QNAME according to the encoding scheme
    outlined in Section 2.5 of [RFC3596], and examine the resulting
    address to see whether its prefix matches any of the locally
    configured Pref64::/n or the default Well-Known Prefix.  There are
    two alternatives for a DNS64 server to respond to such PTR queries.
    A DNS64 server MUST provide one of these, and SHOULD NOT provide both
    at the same time unless different IP6.ARPA zones require answers of
    different sorts:

    1.  The first option is for the DNS64 server to respond
        authoritatively for its prefixes.  If the address prefix matches
        any Pref64::/n used in the site, either a NSP or the Well-Known
        Prefix (i.e., 64:ff9b::/96), then the DNS64 server MAY answer the
        query using locally appropriate RDATA.  The DNS64 server MAY use
        the same RDATA for all answers.  Note that the requirement is to
        match any Pref64::/n used at the site, and not merely the locally
        configured Pref64::/n.  This is because end clients could ask for
        a PTR record matching an address received through a different
        (site-provided) DNS64, and if this strategy is in effect, those
        queries should never be sent to the global DNS.  The advantage of
        this strategy is that it makes plain to the querying client that
        the prefix is one operated by the (DNS64) site, and that the
        answers the client is getting are generated by DNS64.  The
        disadvantage is that any useful reverse-tree information that
        might be in the global DNS is unavailable to the clients querying
        the DNS64.

    2.  The second option is for the DNS64 name server to synthesize a
        CNAME mapping the IP6.ARPA namespace to the corresponding
        IN-ADDR.ARPA name.  In this case, the DNS64 name server SHOULD
        ensure that there is RDATA at the PTR of the corresponding
        IN-ADDR.ARPA name, and that there is not an existing CNAME at
        that name.  This is in order to avoid synthesizing a CNAME that
        makes a CNAME chain longer or that does not actually point to
        anything.  The rest of the response would be the normal DNS
        processing.  The CNAME can be signed on the fly if need be.  The
        advantage of this approach is that any useful information in the
        reverse tree is available to the querying client.  The
        disadvantages are that it adds additional load to the DNS64
        (because CNAMEs have to be synthesized for each PTR query that
        matches the Pref64::/n), and that it may require signing on
        the fly.

    If the address prefix does not match any Pref64::/n, then the DNS64
    server MUST process the query as though it were any other query;
    i.e., a recursive name server MUST attempt to resolve the query as
    though it were any other (non-A/AAAA) query, and an authoritative
    server MUST respond authoritatively or with a referral, as
    appropriate.

---

From: Klaus Frank <[email-masked]>
Date: Sun, 6 Feb 2022 19:13:10 +0000

I'm not aware that SIEVE would use the source ip address. Also when 
looking over the main RFCs for it I couldn't find anything that 
specifies ip validation. ATM only the EHLO (which uses the PTR-RR) and 
the SPF validation rely on IP to DNS mapping.

On 2022-02-06 19:55, [email-masked] wrote:
> There is more than one way to solve it. The proposal to re-write SPF 
> is probably the most correct way within context of NAT64-DNS64. The 
> other option would be to update SPF specifying that validating servers 
> on IPv6 only network can use IPv4 spf records for validation if the ip 
> address of connecting mail server is a mapped IPv4->IPv6. That is far 
> less elegant though.
>
> BTW, I bet SPF is not going to be the only protocol with these types 
> of issues. How about SIEVE? Have you checked how well NAT64 
> inter-operates with that?
>

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 06 Feb 2022 14:57:08 -0500

It looks like situations like this one were contemplated by the RFC 6147 
authors:

> 6.  Deployment Notes
> 
>    While DNS64 is intended to be part of a strategy for aiding IPv6
>    deployment in an internetworking environment with some IPv4-only and
>    IPv6-only networks, it is important to realize that it is
>    incompatible with some things that may be deployed in an IPv4-only or
>    dual-stack context.

On the SPF side of the discussion, I think it would, at least in theory, be 
feasible to interpret an ip4: mechanism as <prefix> + <address> if the 
connection is IPv6, but I don't see how a receiving SPF processor could know 
what the prefix is.  As I read RFC 6147 Section 5.2, it could be anything.

I think your original suggestion that an SPF record be modified by the DNS64 
server to add ip6: mechanisms with <prefix> + <address> is a reasonable path 
forward, but I think it's really an RFC 6147 discussion, not so much RFC 7208.  
It is not, however, without risks.  RFC 7208 Section 3.4 gives advice on SPF 
record size.  Your proposed approach would increase the record size, which, in 
theory, could be problematic.  It might be that anything running on an IPv6 
only network is modern enough that this isn't actually a problem.  I don't 
know.

Scott K

On Sunday, February 6, 2022 2:08:05 PM EST Klaus Frank wrote:
> > (IPv4) and RFC 6147 addresses A?  This would affect PTR lookups too, right
> > (not the SPF PTR mechanism, but when a receiving mail sever does a PTR
> > lookup on the connect address to see if it matches the EHLO name)?

---

From: [email-masked]
Date: Sun, 06 Feb 2022 12:10:51 -0800

In regards to SIEVE take a look at examples in 
http://www.delegate.org/ietf/rfc-html/rfc6134.shtml

There are a lot of various types of ip address validation going on that 
is not documented by IETF or any other authority but is in practice done 
using various unix utilities. Most of these is just to separate local 
and external networks but there are real ip address blocks of large 
sties - both at the router/network and at the local host level. Some 
companies limit what sites their employees can visit and there are many 
ways it is done.

And of course for email ip address block lists still exists and in use 
as well. In some cases DNS is used, in others ip lists are received as 
files and synced.

NAT64 is bound to run into all sorts of issues like this when it begins 
to be more widely used. And I do think this is positive step towards 
IPv6 world. Its just going to take quite some time to work all these 
issues out.

On 2022-02-06 11:13, Klaus Frank wrote:

> option would be to update SPF specifying that validating servers on 
> IPv6 only network can use IPv4 spf records for validation if the ip 
> On Sunday, February 6, 2022 1:09:13 PM EST Klaus Frank wrote: Hi,
> 
> adding

---

From: Klaus Frank <[email-masked]>
Date: Sun, 6 Feb 2022 20:14:55 +0000

> what the prefix is.  As I read RFC 6147 Section 5.2, it could be anything.

It could be queried by a AAAA-RR lookup of ipv4only.arpa (RFC7050).

e.g. with the DNS64 server 2606:4700:4700::64 it returns:

  * 64:ff9b::c000:aa
  * 64:ff9b::c000:ab

but without DNS64 using 2606:4700:4700::1111 it doesn't return any AAAA-RR.

The domain ipv4only.arpa is defined to only have A-RRs (192.0.0.171 and 
192.0.0.170).

But you're right. I also think that an addition to RFC6147 would be the 
best and cleanest implementation (as also [email-masked] noted in 
his reply).

> only network is modern enough that this isn't actually a problem.  I don't
Right, the SPF record size is limited. I completely forgot about that. 
But reading that part of the RFC, I don't think that that's a problem, 
as it's very common to put validation tokens into TXT. And the RFC also 
says that the size limit would include them as well. Also the issue 
would solely lie on the side of the party that also implements DNS64, so 
adjusting a firewall to allow ENDS0 or DNS-over-TCP should be in scope 
for them.

---

From: Klaus Frank <[email-masked]>
Date: Sun, 6 Feb 2022 20:21:40 +0000

But if I see that correctly that's a list that the admin of the 
recipient side has under his control and could update, right? Therefore 
the same entity that deploys DNS64 would just have to make sure to also 
update the list of IPs within their SIEVE configuration, right?

If so a possible migration would be to duplicate these sections with the 
corresponding NAT64 addresses and after NAT64+DNS64 is deployed for the 
mail infrastructure to decommission the ipv4 only ones.

This doesn't look like a hard/RFC limitation (like the SPF record thing) 
to me. Or am I missing something?

On 2022-02-06 21:10, [email-masked] wrote:
> There are a lot of various types of ip address validation going on 
> that is not documented by IETF or any other authority but is in 
> practice done using various unix utilities. Most of these is just to 
> separate local and external networks but there are real ip address 
> blocks of large sties - both at the router/network and at the local 
> host level. Some companies limit what sites their employees can visit 
> and there are many ways it is done.
>
> NAT64 is bound to run into all sorts of issues like this when it 
> begins to be more widely used. And I do think this is positive step 
> towards IPv6 world. Its just going to take quite some time to work all 
> these issues out.
>
>> specifies ip validation. ATM only the EHLO (which uses the PTR-RR) 
>> and the SPF validation rely on IP to DNS mapping.
>>
>>> This is like NAT where entirety of DNS is re-written to make 
>>> internet appear to be IPV6 only. So yes, SPF records would be an 
>>> issue then.
>>>
>>> other option would be to update SPF specifying that validating 
>>> servers on IPv6 only network can use IPv4 spf records for validation 
>>> if the ip address of connecting mail server is a mapped IPv4->IPv6. 
>>> That is far less elegant though.
>>>

---

From: [email-masked]
Date: Sun, 06 Feb 2022 12:44:36 -0800

These are closer to implementation, yes. But how SIEVE is used is that a 
mail server operator can be on one network and they have users on other 
networks that use this protocol to tell the operator what their mail 
filtering preferences are. So mail server operator (if they were behind 
NAT64) would have to do this re-writing or re-interpretation of SIEVE 
rules. This may require knowledge of how IPv4 is mapped to IPv6 for 
them. And it is not much different than trying to re-interpret SPF 
records when on IPv6 only network.

One of the ways of solving issues like this is special IPv4 in-addr like 
dns map and lookup which would allow hosts behind NAT64 to find what 
IPv4->IPv6 translation for their site is when they have an IPv4 address 
from some filtering system or protocol and they need to locally 
re-interpret it. This is not as elegant as DNS64 rewriting but I think 
its going to be needed in the end anyway for various cases (maybe as 
interim solution).

On 2022-02-06 12:21, Klaus Frank wrote:

> If so a possible migration would be to duplicate these sections with 
> the corresponding NAT64 addresses and after NAT64+DNS64 is deployed for 
> the mail infrastructure to decommission the ipv4 only ones.
> 
> This doesn't look like a hard/RFC limitation (like the SPF record 
> thing) to me. Or am I missing something?
> 
> is not documented by IETF or any other authority but is in practice 
> done using various unix utilities. Most of these is just to separate 
> local and external networks but there are real ip address blocks of 
> large sties - both at the router/network and at the local host level. 
> Some companies limit what sites their employees can visit and there are 
> many ways it is done.
>

---

From: Klaus Frank <[email-masked]>
Date: Sun, 6 Feb 2022 20:57:54 +0000

On 2022-02-06 21:44, [email-masked] wrote:
>
>
> These are closer to implementation, yes. But how SIEVE is used is that 
> a mail server operator can be on one network and they have users on 
> other networks that use this protocol to tell the operator what their 
> mail filtering preferences are. So mail server operator (if they were 
> behind NAT64) would have to do this re-writing or re-interpretation of 
> SIEVE rules. This may require knowledge of how IPv4 is mapped to IPv6 
> for them. And it is not much different than trying to re-interpret SPF 
 From my perspective SPF should be covered as it's also DNS and when 
doing DNS64 it's reasonable for the admin to assume that it's consistent 
and complete. Therefore translating the SPF would be something that 
anyone using DNS64 would take as given.

SIEVE on the other hand isn't part of DNS. I'd consider it more like a 
firewall. Another system that does filtering utilizing DNS but not being 
part of DNS. And for those systems there is RFC7050 
https://datatracker.ietf.org/doc/html/rfc7050#section-3.4 or the admin 
manually updating the IPs in the configuration.

But for SPF on the other hand we're basically serving incorrect 
information from an admins perspective. As DNS64+NAT64 should make the 
IPv4 internet a part of the ipv6 only internet, but then it doesn't 
serve ipv6 IPs within the SPF...

> One of the ways of solving issues like this is special IPv4 in-addr 
> like dns map and lookup which would allow hosts behind NAT64 to find 
> what IPv4->IPv6 translation for their site is when they have an IPv4 
> address from some filtering system or protocol and they need to 
> locally re-interpret it. This is not as elegant as DNS64 rewriting but 
> I think its going to be needed in the end anyway for various cases 
> (maybe as interim solution).
>
>> recipient side has under his control and could update, right? 
>> Therefore the same entity that deploys DNS64 would just have to make 
>> sure to also update the list of IPs within their SIEVE configuration, 
>> right?
>>
>> the corresponding NAT64 addresses and after NAT64+DNS64 is deployed 
>> for the mail infrastructure to decommission the ipv4 only ones.
>>
>>> host level. Some companies limit what sites their employees can 
>>> visit and there are many ways it is done.
>>>
>>> And of course for email ip address block lists still exists and in 
>>> use as well. In some cases DNS is used, in others ip lists are 
>>> received as files and synced.
>>>
>>> towards IPv6 world. Its just going to take quite some time to work 
>>> all these issues out.
>>>
>>>>> There is more than one way to solve it. The proposal to re-write 
>>>>> SPF is probably the most correct way within context of 
>>>>> NAT64-DNS64. The other option would be to update SPF specifying 
>>>>> that validating servers on IPv6 only network can use IPv4 spf 
>>>>> records for validation if the ip address of connecting mail server 
>>>>> is a mapped IPv4->IPv6. That is far less elegant though.
>>>>>
>>>>> BTW, I bet SPF is not going to be the only protocol with these 
>>>>> types of issues. How about SIEVE? Have you checked how well NAT64

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2022 17:16:18 -0500

>what the prefix is.  As I read RFC 6147 Section 5.2, it could be anything.

See RFCs 7050 and 8880 for how you find the prefix(es).

That seems like a more reasonable way to go, patch the SPF library so it
can use the NAT's Pref64 to fudge the interpretation of ip4 and ptr.

It looks like you could automate the entire thing -- when the library starts
up, do an AAAA query on ipv4only.arpa, and if you get plausible answers,
you know you're behind NAT64 and reinterpret ip4 and ptr terms appropriately.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 6 Feb 2022 17:47:15 -0500

Hi,

I'm one of the primary offenders behind DNS64.  I work for the Internet Society but I am not speaking for them (or anyone eles) right now.

>forward, but I think it's really an RFC 6147 discussion, not so much RFC 7208.

The problem with this is that it's importing the DNS64 intimate knowledge of this protocol for TXT records, which means in effect that DNS64 needs to start parsing arbitrary data in TXT records.  (There is a reason DNS weenies always got upset about ignoring the strong typing in DNS, and this is an example of it.)

DNS64, to be honest, was always sort of a hack that was intended to make transition to v6 easier.  It really basically depended on the strong data typing of A, AAAA, and PTR records in order to give it clear places to insert itself.  "Look at every TXT record," doesn't really support that plan.  I never thought we were designing it for long life or high degrees of robustness, and I think it is likely to be extremely difficult to operate a modern mail server on v6-only infrastructure and be able to talk to v4-only mail servers.  In any case, I guess it would be _possible_ to teach a DNS64 server to parse and edit TXT records on the fly, but the idea that this is going to be limited to SPF is, I suspect, a false hope.  For that reason, my reaction is that it wouldn't be a great idea to do.  I nevertheless sympathize with the desire, even though I am made nervous about the implications.

>only network is modern enough that this isn't actually a problem.  I don't

I'd be especially worried about RRset size, because a lot of stuff in contemporary operations is jammed into TXT records (all those application keys, for instance).  I can imagine cases where the change could move the response size across the response size boundary, forcing truncation and TCP fallback.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Klaus Frank <[email-masked]>
Date: Sun, 6 Feb 2022 23:34:49 +0000

Either way one of both RFCs needs an addendum to address this.

I personally think that because the SPF record is part of DNS it should 
be updated by DNS64 as well. But if RFC7208 gets an addendum that 
mandates the SPF library to consider the NAT64 (RFC7050 and RFC8880) 
prefix when doing validation would also work for me.

---

From: Klaus Frank <[email-masked]>
Date: Mon, 7 Feb 2022 00:09:11 +0000

On 2022-02-06 23:47, Andrew Sullivan wrote:
> It really basically depended on the strong data typing of A, AAAA, and 
> PTR records in order to give it clear places to insert itself.  "Look 
> at every TXT record," doesn't really support that plan. 

But it wouldn't be "every TXT record". If it doesn't start with "v=spf1" 
it can be passed as is and does not require parsing. And even then it's 
also a defined structure and not "arbitrary".

On 2022-02-06 23:47, Andrew Sullivan wrote:
> I never thought we were designing it for long life or high degrees of 
> robustness, and I think it is likely to be extremely difficult to 
> operate a modern mail server on v6-only infrastructure and be able to 
> talk to v4-only mail servers.

Actually the only limitation for that is the SPF record not being 
updated by DNS64... And for outgoing it's not an issue at all. A 
stateless NAT64 mapping is enough...

A combination of stateless and statefull NAT64 is enough to cover all 
the ugly IPv4 stuff. Also because IPv4 was already highly NAT44ed 
anyway. There is no difference between a mail server behind a NAT44 and 
one behind a NAT64 as long as the correct public facing IP is used in 
the configuration of one owns SPF record...

But tbh, in some situations it would be very helpful if I could just 
swap the calls for generating IPv4 packets by one that generates IPv6 
packets instead. I thought about writing something that works via 
LD_PRELOAD similarly to torsocks or IP2Unix, but it went way over my 
head to make it anything close to performant and reliable...

On 2022-02-06 23:47, Andrew Sullivan wrote:
> but the idea that this is going to be limited to SPF is, I suspect, a 
> false hope.  For that reason, my reaction is that it wouldn't be a 
> great idea to do.
What do you have in mind? What else would be there? From my point of few 
the only thing missing for a complete DNS64 rewrite is the SPF record. 
As nothing else contains IP addresses but only dns names. I've looked at 
the other record types. Did I miss something?

---

From: [email-masked]
Date: Sun, 06 Feb 2022 16:42:07 -0800

Yeah, I wasn't thrilled with the idea of SPF using TXT record way back 
when. It opened it for quite a few others who followed. Putting ip 
addresses there though is not something that is done for any other 
protocol or software I can immediately think of.

I'm curious, how does DNS64 inter-operates with DNSSEC? Would that not 
break it and make DNSSEC folks very uncomfortable about what others 
could decide to do?

I think it could be helpful to collect various protocol operational and 
similar issues for those running mail servers (and other servers) behind 
NAT64 and write informational RFC which would be soft of experimental 
best practice. I'd expect that some server software would have to add 
special features to be used in this setup.

On 2022-02-06 14:47, Andrew Sullivan wrote:

> Hi,
> 
> I'm one of the primary offenders behind DNS64.  I work for the Internet 
> Society but I am not speaking for them (or anyone eles) right now.
> 
> The problem with this is that it's importing the DNS64 intimate 
> knowledge of this protocol for TXT records, which means in effect that 
> DNS64 needs to start parsing arbitrary data in TXT records.  (There is 
> a reason DNS weenies always got upset about ignoring the strong typing 
> in DNS, and this is an example of it.)
> 
> DNS64, to be honest, was always sort of a hack that was intended to 
> make transition to v6 easier.  It really basically depended on the 
> strong data typing of A, AAAA, and PTR records in order to give it 
> clear places to insert itself.  "Look at every TXT record," doesn't 
> really support that plan.  I never thought we were designing it for 
> long life or high degrees of robustness, and I think it is likely to be 
> extremely difficult to operate a modern mail server on v6-only 
> infrastructure and be able to talk to v4-only mail servers.  In any 
> case, I guess it would be _possible_ to teach a DNS64 server to parse 
> and edit TXT records on the fly, but the idea that this is going to be 
> limited to SPF is, I suspect, a false hope.  For that reason, my 
> reaction is that it wouldn't be a great idea to do.  I nevertheless 
> sympathize with the desire, even though I am made nervous about the 
> implications.
> 
> I'd be especially worried about RRset size, because a lot of stuff in 
> contemporary operations is jammed into TXT records (all those 
> application keys, for instance).  I can imagine cases where the change 
> could move the response size across the response size boundary, forcing 
> truncation and TCP fallback.
> 
> Best regards,
> 
> A

---

From: Klaus Frank <[email-masked]>
Date: Mon, 7 Feb 2022 01:07:51 +0000

> break it and make DNSSEC folks very uncomfortable about what others 
Basically by offloading it towards the DNS64 server.

https://datatracker.ietf.org/doc/html/rfc6147#section-6.2

6.2.  DNSSEC Validators and DNS64

    An existing DNSSEC validator (i.e., one that is unaware of DNS64)
    might reject all the data that comes from DNS64 as having been
    tampered with (even if it did not set CD when querying). *If it is**
**   necessary to have validation behind the DNS64, then the validator**
**   must know how to perform the DNS64 function itself*. Alternatively,
    the validating host may establish a trusted connection with a DNS64,
    and allow the DNS64 recursive resolver to do all validation on its
    behalf.

> I think it could be helpful to collect various protocol operational 
> and similar issues for those running mail servers (and other servers) 
> behind NAT64 and write informational RFC which would be soft of 
> experimental best practice. I'd expect that some server software would 
> have to add special features to be used in this setup.
>
"special features" is exactly what I wanted to avoid. Also I don't know 
if it's strictly necessary to have a dedicated RFC for how to do the 
migration. Besides this issue with the SPF record it's basically the 
same as for any other server application. Use stateless NAT64 (aka. 
IPv4aaS) to have a dedicated public IPv4. Put that IPv4 (prefix) into 
the SPF record as usual. And for now disable the SPF validation for 
inbound mails. The only really noteworthy thing is with filtering stuff 
like SIEVE that these need to be updated to include their mapped IPv6 
addresses or similar. Everything else just works because of NAT64 and 
DNS64...

---

From: Mark Andrews <[email-masked]>
Date: Mon, 7 Feb 2022 12:45:57 +1100

Despite what you quote here, DNS64 is incompatible with DNSSEC because it hijacked the CD bit for a different purpose.  For a DNSSEC validator to work through another nameserver it needs to be able to send both CD=0 and CD=1
requests WITHOUT the records being modified.  The DNS64 working group was told this at the time but refused to listen.  

CD=1 to handle bad time / bad trust anchors in the upstream nameservers.
CD=0 to handle spoofed / expired responses being sent to the upstream nameservers.

in BOTH cases the client validates the responses.  If the validation fails the first way, it should attempt the
request again with the CD bit in the other state.  If the second query fails then you have an actual DNSSEC failure.

Below was just wishful thinking upon behalf of the DNS64 working group.  They wanted a signal that meant the client is performing validation and refused to accept “if DO=1 then you have to assume the client is validating."

   3.  A security-aware and non-validating DNS64 receives a query with
       the DO bit set and the CD bit clear.  Such a resolver is not
       validating responses, likely due to local policy (see [RFC4035],
       Section 4.2).  For that reason, this case amounts to the same as
       the previous case, and no validation happens.

Making CD into a modify the response signal was/is incompatible with how DNSSEC uses CD.

Mark

> On 7 Feb 2022, at 12:07, Klaus Frank <[email-masked]> wrote:
> 
> 
>> Yeah, I wasn't thrilled with the idea of SPF using TXT record way back when. It opened it for quite a few others who followed. Putting ip addresses there though is not something that is done for any other protocol or software I can immediately think of.
>> 
>> I'm curious, how does DNS64 inter-operates with DNSSEC? Would that not break it and make DNSSEC folks very uncomfortable about what others could decide to do?
>> 
>> I think it could be helpful to collect various protocol operational and similar issues for those running mail servers (and other servers) behind NAT64 and write informational RFC which would be soft of experimental best practice. I'd expect that some server software would have to add special features to be used in this setup.
>> 
> "special features" is exactly what I wanted to avoid. Also I don't know if it's strictly necessary to have a dedicated RFC for how to do the migration. Besides this issue with the SPF record it's basically the same as for any other server application. Use stateless NAT64 (aka. IPv4aaS) to have a dedicated public IPv4. Put that IPv4 (prefix) into the SPF record as usual. And for now disable the SPF validation for inbound mails. The only really noteworthy thing is with filtering stuff like SIEVE that these need to be updated to include their mapped IPv6 addresses or similar. Everything else just works because of NAT64 and DNS64...
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2022 21:04:53 -0500

It appears that Klaus Frank  <[email-masked]> said:
>-=-=-=-=-=-

Unless you can find other people attempting to do SPF validation from
behind DNS64, it seems like a very low priority.

SPF has been in wide use since RFC 4408 was published fifteen years ago,
and I don't ever recall anyone else raising this issue before.

If you want to try writing the patches for whatever SPF library you use,
I expect the maintainers would be happy to look at them, but since they
don't use DNS64 or NAT64 it'd be hard for them to test or validate them.

R's,
John

---

From: Ángel <[email-masked]>
Date: Mon, 07 Feb 2022 03:21:40 +0100

On 2022-02-06 at 18:39 +0000, Klaus Frank wrote:
> >> 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.
> > I agree there is a problem. However, I can think of “interesting”
> problems to solve, like: what if the ip4 contains a prefix, like
> 192.168.1.0/25. How would you translate this into IPv6 prefix by the
> DNS-64?
> Literally, your address of 192.168.1.0 would be e.g.
> ::ffff:c0a8:0100 and the prefix would just be 25+96

Ok, what about a component of "exists:%{ir}.list.dnswl.org" ?

A rewriting DNS64 dns server would need to keep track of spf queries,
learn that *.list.dnswl.org is special with a %{ir} pattern, and
rewrite queries matching that pattern with their ipv6 prefix into the
ipv4 one. Maybe they could rewrite into a pattern
like exists:%{ir}.list.dnswl.org.spfirexists.theirdomain.com which
tells it how it should be mapped, but it gets ugly really quick.

Having the SPF validator know about their IPv6 prefix -or, simply,
translate the IPv6 back into IPv4 before passing the address to the SPF
module- looks like a cleaner approach.

Best regards

---

From: Klaus Frank <[email-masked]>
Date: Mon, 7 Feb 2022 02:30:06 +0000

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.

But now when reading the RFC7208 Section 5.7 again. We would need to 
extend that section to also validate the AAAA record. Currently it even 
states the limitation:

    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.

So the issue here is missing IPv6 support. Nothing no other special 
handling is required by the DNS64 server and it also doesn't need to be 
parsed. But the SPF library would need to also check the AAAA-RR, which 
considering future proving it should be doing anyway...

The DNS64 would only have to rewrite ip4 into ip6.

On 2022-02-07 03:21, Ángel wrote:
> learn that *.list.dnswl.org is special with a %{ir} pattern

---

From: Klaus Frank <[email-masked]>
Date: Mon, 7 Feb 2022 02:54:22 +0000

Oh dear, it's even worse than I thought. Is there an errata or update 
rfc for that?

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 07 Feb 2022 09:28:16 -0500

On Sunday, February 6, 2022 5:16:18 PM EST John Levine wrote:
> >connection is IPv6, but I don't see how a receiving SPF processor could
> >know what the prefix is.  As I read RFC 6147 Section 5.2, it could be
> >anything.

Thanks.

Reading RFC 7050, it looks like ipv4only.arpa can return more than one name.  
That would seem to be a complication if I'm reading it correctly.

As a practical matter, it probably doesn't matter, but RFC 7050 doesn't update 
RFC 6147, so in theory other prefix determination methods could be used.

I guess the ::ffff:0:0/96 (IPv4-mapped Address) prefix should be considered 
similarly.

Is there enough here that it would be worth an Applicability Statement?

Scott K

---

From: Klaus Frank <[email-masked]>
Date: Mon, 7 Feb 2022 15:19:12 +0000

> I guess the ::ffff:0:0/96 (IPv4-mapped Address) prefix should be considered
Oh yes, for sure good that you remind me of this one. We had one 
mailserver application (proprietary) that once we changed the binding 
from "0.0.0.0:25" to "[::]:25" on a linux system got everything as 
::ffff:0:0/96 and SPF validation also failed. But I'm not sure if that 
was an implementation simplification on their end or a OS dependent 
behavior of when binding a socket... The workaround we got was to "just 
deploy another VM for IPv6 and put them behind the same public DNS name. 
One for IPv4 and another one for the IPv6"

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Feb 2022 10:22:07 -0500

On Mon, Feb 07, 2022 at 12:09:11AM +0000, Klaus Frank wrote:
>But it wouldn't be "every TXT record". If it doesn't start with 
>"v=spf1" it can be passed as is and does not require parsing. And even 
>then it's also a defined structure and not "arbitrary".

That is only true if you assume that the only case that counts is SPF.  But of course, that probably _isn't_ true.  Moreover, you still have to look at every TXT record and examine the RDATA.  That's not true for the other kinds of records: if you're a DNS64 you know that the A records are something you're going to have to process and you can have a high confidence that you'll probably need to process PTR records too.  What you are proposing is that the DNS64 needs to grab every TXT too, then look at the RDATA and _decide_ whether to process it, which is way more complicated.

>updated by DNS64.

Sounds like a pretty severe limitation to me!

>What do you have in mind? What else would be there?

Anything could be in a TXT record, and once we start setting the precedent that the DNS64 should do rewrites of arbitrary text to capture certain relevant IPv4 addresses and make them IPv6 addresses with the appropriate prefix, there's no reason one has to stop at SPF.  The whole argument for using TXT records for SPF was that it was easy and you get to put what you want in a TXT.  But since "you get to put what you want", you have to live with the fact that there's not structured data in there from the point of view of the DNS.  Just because some other protocol wants to overload TXT and put structure into it does not mean that the DNS ought to be handling that RDATA programmatically.  TXT is arbitrary text data.

>As nothing else contains IP addresses but only dns names. I've 
>looked at the other record types. Did I miss something?

There's nothing that says that SPF is the only use of TXT here, so I don't see how you looking at your sample is proof of anything.  If DNS64 is supposed to start munging TXT records then it needs to do so in some predictable way.  If instead you want a neat hack of the sort John Levine suggested in order to generate the records on the fly, I certainly see the utility.  But I don't think standardizing that as part of DNS64 is a good idea.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Feb 2022 10:24:20 -0500

On Sun, Feb 06, 2022 at 04:42:07PM -0800, [email-masked] wrote:

>I'm curious, how does DNS64 inter-operates with DNSSEC?

Awkwardly.  There is a long discussion of it in the RFC.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 7 Feb 2022 10:47:13 -0500

>Is there enough here that it would be worth an Applicability Statement?

On the one hand, I think the implementation would be quite easy.  When the SPF
library receives an external IPv6 address to check, it does the ipv4only
lookup and if the prefix on the address is one of the mapped ones, it
rewrites the IPv6 address to the corresponding IPv4 address and passes it
along to the rest of the SPF code.

On the other hand, since this is the first time in fifteen years that anyone
has run into this, I don't think it's worth fixing.  If you want to put a
mail server behind DNS64, you're on your own.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 07 Feb 2022 11:21:15 -0500

On Monday, February 7, 2022 10:47:13 AM EST John Levine wrote:
> >Reading RFC 7050, it looks like ipv4only.arpa can return more than one
> >name. That would seem to be a complication if I'm reading it correctly.
> >
> >As a practical matter, it probably doesn't matter, but RFC 7050 doesn't
> >update RFC 6147, so in theory other prefix determination methods could be
> >used.
> >
> On the one hand, I think the implementation would be quite easy.  When the
> SPF library receives an external IPv6 address to check, it does the
> ipv4only lookup and if the prefix on the address is one of the mapped ones,
> it rewrites the IPv6 address to the corresponding IPv4 address and passes
> it along to the rest of the SPF code.
> 

> incompatible with some things that may be deployed in an IPv4-only or

OTOH, how long has DNS64 been deployed (I don't know)?  Will it see increased 
deployment in the future, so this is the leading edge of the issue?

Personally, I don't have an interest in DNS64, but I think it's not 
unreasonable for the IETF to document how to navigate the intersection of two 
standards track documents.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 7 Feb 2022 12:31:28 -0500

>deployment in the future, so this is the leading edge of the issue?

I think DNS64 and NAT64 fall into the category of "nice try". The idea
was that your devices could all be IPv6 only and the complexity would
all be in the NAT and the DNS translator.

But we now know that DNS64 breaks DNSSEC, it breaks SPF, and as Andrew
has pointed out, it likely breaks other stuff too. NAT64 and DNS64 are
probably OK for mobile networks where everything is a client and P2P
servers are discouraged.

But in reality, all devices are dual stacked, and networks use NAT44
to connect to the IPv4 outside world. I have a bunch of servers at
AWS. They all have real IPv6 addrsses and local 10/8 addresses. The
ones that need to be visible from outside have static real IPv4
addresses routed through the NAT (rumor says at least two levels of
NAT.) The others can get a temporary address from the AWS pool while
they are active. What my hosts see is a /16 of 10/8 where I can
activate /24 subnets in different geographic regions.

It works fine. There is no messing with the DNS, DNSSEC works, the
remote IPv4 addresses my servers see are the real ones so if they were
doing SPF, it would work too.

For a long time the IETF desperately tried to pretend that NAT44 was
useless or stupid or didn't exist, and there were a few attempts to
do something that wasn't NAT44.  I think this is one of them.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Feb 2022 12:52:06 -0500

Hi,

(Still working for someone and not speaking for them.)

On Mon, Feb 07, 2022 at 12:31:28PM -0500, John Levine wrote:

>But we now know that DNS64 breaks DNSSEC

To be clear, we _always_ knew this (see RFC 6147 section 5.5).  Mark Andrews felt very strongly that the way it worked was wrong, I am aware.

> it breaks SPF

I don't actually think that is true.  I think SPF is a case where, if you're going to use an application that depends on IPv4 literals behind a NAT64, you're going to need a NAT64-aware application.  That shouldn't be too surprising in my opinion.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 7 Feb 2022 13:29:46 -0500

It appears that Andrew Sullivan  <[email-masked]> said:
>To be clear, we _always_ knew this ...
>
>> it breaks SPF
>
>I don't actually think that is true.  I think SPF is a case where, if you're going to use an application that depends on IPv4 literals behind a NAT64, you're going o need a NAT64-aware application.  That shouldn't be too surprising in my opinion.

It seems to me they're really the same. If the application knows it's
behind DNS64 and it sees an AAAA record with a translated address, the
application can translate it back and see if it's valid, e.g., ask for
signed DNS A records and see if the addresses match.

Of course, if you can expect the endpoint to know that much about
what's going on, you might as well skip the DNS hackery ahd do the
address translation in the endpoint's socket routines. I probably
should stop now lest someone think that was a serious suggestion.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Feb 2022 13:38:41 -0500

>should stop now lest someone think that was a serious suggestion.

There's effectively a mode for that in RFC 6147: it's called DNS64 in
stub-resolver mode, and it's really the only way to get validation on
the endpoint working.  I spent a fair amount of time thinking about
that sort of thing, and it's what convinces me you can't really build
the scaffolding correctly in DNS64 to handle embedded v4 literals in
TXT records.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stuart D Gathman <[email-masked]>
Date: Mon, 7 Feb 2022 14:12:14 -0500 (EST)

> should stop now lest someone think that was a serious suggestion.

Serious suggestion: forget about an IP protocol from the last century,
and use IP6.  If absolutely necessary to receive email from IP4,
use an SMTP gateway listening on IP4 to forward the mail to IP6.  IP info
is captured in headers (either Received or Received-SPF from the trusted
gateway).

---

From: Ángel <[email-masked]>
Date: Mon, 07 Feb 2022 23:40:56 +0100

On 2022-02-07 at 02:30 +0000, Klaus Frank wrote:
> 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.

---

From: [email-masked]
Date: Mon, 07 Feb 2022 15:22:13 -0800

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?

> (perhaps lost if translated into IPv6) but the main problem is querying

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

---

From: [email-masked]
Date: Mon, 07 Feb 2022 15:30:40 -0800

SPF macro tricks: 

Links:
------

---

From: Klaus Frank <[email-masked]>
Date: Mon, 7 Feb 2022 23:31:55 +0000

> 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.
> would have to use a library that can discovery what NAT64 prefix is 
> and translate everything.
>
>     The <domain-spec> is expanded as perSection 7  <https://datatracker.ietf.org/doc/html/rfc7208#section-7>.  The resulting domain
> 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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 07 Feb 2022 18:35:47 -0500

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 [email-masked] 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....
> 
> BTW, what's going on with exists and A vs AAAA? The SPF 7208 RFC says:
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 8 Feb 2022 10:57:32 +1100

> On 8 Feb 2022, at 02:19, Klaus Frank <[email-masked]> wrote:
> 
> Oh yes, for sure good that you remind me of this one. We had one mailserver application (proprietary) that once we changed the binding from "0.0.0.0:25" to "[::]:25" on a linux system got everything as ::ffff:0:0/96 and SPF validation also failed. But I'm not sure if that was an implementation simplification on their end or a OS dependent behavior of when binding a socket... The workaround we got was to "just deploy another VM for IPv6 and put them behind the same public DNS name. One for IPv4 and another one for the IPv6"

One could have just set IPV6_V6ONLY=1 at the system level (sysctl net.ipv6.bindv6only=1) or prior to bind(2)
on the individual sockets if you don’t want mapped connections.  IPV6_V6ONLY is described in RFC 2535, Basic
Socket Interface Extensions for IPv6 (February 2003) and is in also in POSIX as of 2008.  Alternatively SPF
libraries could just learn about mapped connections and apply IPv4 rules against them.

---

From: Klaus Frank <[email-masked]>
Date: Tue, 8 Feb 2022 00:09:12 +0000

> libraries could just learn about mapped connections and apply IPv4 rules against them.

Thanks for the hint. I know that that existed, but didn't know how to 
configure it or what exactly causes it.

Also I just re-read the SPF record RFC, and it indeed should already 
cover IPv4-mapped IPv6. So strictly speaking that's a violation of the 
RFC and therefore an implementation bug...

    When any mechanism fetches host addresses to compare with <ip>, when
    <ip> is an IPv4, "A" records are fetched; when <ip> is an IPv6
    address, "AAAA" records are fetched.  SPF implementations on IPv6
    servers *need to handle both "AAAA" and "A" records, for clients on**
**   IPv4-mapped IPv6 addresses *[RFC4291].  IPv4 <ip> addresses are only
    listed in an SPF record using the "ip4" mechanism.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 8 Feb 2022 11:28:22 +1100

> On 8 Feb 2022, at 11:09, Klaus Frank <[email-masked]> wrote:
> 
> 
> Thanks for the hint. I know that that existed, but didn't know how to configure it or what exactly causes it.
> 
> Also I just re-read the SPF record RFC, and it indeed should already cover IPv4-mapped IPv6. So strictly speaking that's a violation of the RFC and therefore an implementation bug...
> 

The SPF libraries (or the MTAs) could also use RFC 8781, Discovering PREF64
in Router Advertisements.  Failing that, as has already been mentioned they
could use ipv6only.arpa to get the mapping.

---

From: [email-masked]
Date: Mon, 07 Feb 2022 16:36:31 -0800

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

> 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.

>> The <domain-spec> is expanded as perSection 7  
>> <https://datatracker.ietf.org/doc/html/rfc7208#section-7>.  The 
>> resulting domain
> Here is a DNS64 resolver from cloudflare if you want to try it 
> yourself: 2606:4700:4700::64
> 
> On 2022-02-07 at 02:30 +0000, Klaus Frank wrote: Why? Such a query 
> would resolve in the mailserver would make the DNS

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 8 Feb 2022 15:44:11 +0100

On Tue 08/Feb/2022 01:36:31 +0100 William wrote:
>> On 2022-02-08 00:22, [email-masked] <mailto:[email-masked]> wrote:
>>>
>>> SPF macro tricks: 
>> 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.
> address.

Right.

> I wonder if there even are people doing ip6 exist macros...

Macros like the one Ángel cited, exists:%{ir}.list.dnswl.org, 
explicitly require to lookup a white list.  RFC 7208 suggest receivers 
do so implicitly, in order to account for forwarding, but not all 
receivers comply.  A white list lookup is required if the record 
terminates with -all.  With IPv6, it is even more required, IMHO.

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Wed, 9 Feb 2022 12:36:38 -0500

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 <[email-masked]> wrote:
> 
> Hi,
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Feb 2022 14:27:14 +1100

> On 10 Feb 2022, at 04:36, Hector Santos <hsantos=[email-masked]> wrote:
> 
> RFC3597

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Feb 2022 15:06:51 +1100

Unfortunately some resolver developers failed to read / understand
RFC 1034.  RFC 3597 provided a standard textual representation, which
allowed nameservers to load and publish records that they didn’t know
about.  Handling of arbitrary records by resolvers was expected from
the very beginning.  New record types where expected from the very
beginning.

RFC 1034

   3. General lookup function

      This function retrieves arbitrary information from the DNS,
      and has no counterpart in previous systems.  The caller
      supplies a QNAME, QTYPE, and QCLASS, and wants all of the
      matching RRs.  This function will often use the DNS format
      for all RR data instead of the local host's, and returns all
      RR content (e.g., TTL) instead of a processed form with local
      quoting conventions.

When the resolver performs the indicated function, it usually has one of
the following results to pass back to the client:

   - One or more RRs giving the requested data.

     In this case the resolver returns the answer in the
     appropriate format.

   - A name error (NE).

     This happens when the referenced name does not exist.  For
     example, a user may have mistyped a host name.

   - A data not found error.

     This happens when the referenced name exists, but data of the
     appropriate type does not.  For example, a host address
     function applied to a mailbox name would return this error
     since the name exists, but no address RR is present.

RFC 1035

The domain system is a mixture of functions and data types which are an
official protocol and functions and data types which are still
experimental.  Since the domain system is intentionally extensible, new
data types and experimental behavior should always be expected in parts
of the system beyond the official protocol.  The official protocol parts
include standard queries, responses and the Internet class RR data
formats (e.g., host addresses).  Since the previous RFC set, several
definitions have changed, so some previous definitions are obsolete.

Mark

> https://datatracker.ietf.org/doc/html/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
> 
> 
> Hope any of this helps
> 
> —
> HLS
> 
> 
>