Subject: [BEHAVE] 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: 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.

> 
> Sincerely,
> Klaus Frank
> 
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

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: Keith Moore <[email-masked]>
Date: Sun, 6 Feb 2022 17:18:20 -0500

On 2/6/22 13:09, Klaus Frank wrote:

> 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 
> 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:
> additional "ip6" entries. The original "ip4" should not be removed 
> from the response.

PLEASE do not try to make DNS reflect any more NAT alterations to 
reality.  That was ALWAYS a Bad Idea.   If you're going to operate 
application servers behind any kind of NAT, what you need to do is 
arrange for those application servers to somehow get a view of the 
external/global addresses that they're communicating with, even if the 
source IP addresses that they see aren't the real ones.  (If NATs had 
been done "right" there would be an API for this, supported by all 
NATs.   But that ship sailed decades ago.)

More generally, NAT is inherently unfixable, and trying to fix it can 
only result in infinitely growing complexity and brokenness. It's the 
usual problem with telling lies: every lie you tell needs N additional 
lies to cover up the earlier lies and so on recursively.

(also, relying on SPF records is ill-advised, as they're too likely to 
be out-of-sync with reality even without NATs in the picture. )

Keith

---

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

Hi,

I can understand you. I also don't like NAT. And I would also have 
favored different migration paths from IPv4 to IPv6. But NAT64+DNS64 is 
the one we got. I'm sure there have been discussions earlier. I didn't 
want to resume or repeat those discussions. I'm certain there are valid 
reasons for why we have the current migration paths and that the pros 
and cons of different strategies have been covered adequately.

Nonetheless DNS64 is incomplete without also addressing the SPF record.

On 2022-02-06 23:18, Keith Moore wrote:
>> 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.
>>
>> 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.
>
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Feb 2022 19:41:14 -0500

On 2/6/22 19:38, Klaus Frank wrote:

> favored different migration paths from IPv4 to IPv6. But NAT64+DNS64 
> is the one we got. I'm sure there have been discussions earlier. I 
> didn't want to resume or repeat those discussions. I'm certain there 
> are valid reasons for why we have the current migration paths and that 
> the pros and cons of different strategies have been covered adequately.
>
Disagree.  DNS64 is inherently incomplete and cannot be fixed.  I will 
strongly object to any effort to further pollute DNS in the name of 
making NAT appear to work.

Keith

---

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

This is neither helpful nor constructive.

But if you really want to talk about spilled milk, why don't we talk 
about RFC3338 then? If that one is a bit polished it could completely 
eliminate the need for NAT64. But it was dropped in the process and 
never got past Experimental. I'd have some ideas on how to make it fly, 
but I don't see value in following up an RFC that was dropped 20 years 
ago and diverge from a bad but industry favored solution (NAT64) that 
compared to RFC3338 has seen adoption and is also already used in the 
wild...

On 2022-02-07 01:41, Keith Moore wrote:
>> are valid reasons for why we have the current migration paths and 
>> that the pros and cons of different strategies have been covered 
>> adequately.
>>

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Feb 2022 19:51:58 -0500

> This is neither helpful nor constructive. 

Agreed.  Please don't put words in my mouth or try to recast my 
technical arguments as personal ones.

I'm not arguing about spilt milk; I'm arguing to not make an already bad 
situation even worse than it currently is.

Keith

---

From: Dan Wing <[email-masked]>
Date: Sun, 6 Feb 2022 16:58:18 -0800

The philosophy in RFC3338 became 464XLAT, https://datatracker.ietf.org/doc/html/rfc6877

As for the DNS64 issue, could the application become NAT64-aware and do the SPF rewriting itself?  See https://datatracker.ietf.org/doc/html/rfc7050 which discusses how that can work on the local application.

A problem with rewriting SPF records within DNS64 is that other IPv4 addresses may well appear in TXT records, throwing a loop to applications which won't know if the DNS64 has done rewriting or if the application needs to do rewriting.  A long-standing problem with NAT "support" for applications since the days of FTP PASV.

I will also +1 Keith's comment that SPF is a borked standard, even if the world had no NATs.  DKIM and DMARC are superior.

-d

> On Feb 6, 2022, at 4:47 PM, Klaus Frank <[email-masked]> wrote:
> 
> But if you really want to talk about spilled milk, why don't we talk about RFC3338 then? If that one is a bit polished it could completely eliminate the need for NAT64. But it was dropped in the process and never got past Experimental. I'd have some ideas on how to make it fly, but I don't see value in following up an RFC that was dropped 20 years ago and diverge from a bad but industry favored solution (NAT64) that compared to RFC3338 has seen adoption and is also already used in the wild...
> 
>>> I can understand you. I also don't like NAT. And I would also have favored different migration paths from IPv4 to IPv6. But NAT64+DNS64 is the one we got. I'm sure there have been discussions earlier. I didn't want to resume or repeat those discussions. I'm certain there are valid reasons for why we have the current migration paths and that the pros and cons of different strategies have been covered adequately.
>>> 
>> Disagree.  DNS64 is inherently incomplete and cannot be fixed.  I will strongly object to any effort to further pollute DNS in the name of making NAT appear to work.
>> 
>> Keith
>> 
>>

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Feb 2022 20:52:52 -0500

> A problem with rewriting SPF records within DNS64 is that other IPv4 addresses may well appear in TXT records, throwing a loop to applications which won't know if the DNS64 has done rewriting or if…

+1

In general the problem with NATs is that they try to hide what they're 
doing from applications.   But they are never completely successful at 
that, and they cannot be.    And it's often difficult for the 
application to work-around the damage caused by the NAT.  In hindsight, 
it would have been far better for NATs to always be explicitly visible 
to applications; then at least the applications and NATs wouldn't be 
trying to second-guess one another.

But that's water under the bridge.   At this point the best thing that 
can be done is to transition to IPv6 only (except for some legacy 
hardware on local networks), and eradicate NATs as soon as possible.

Keith

---

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

> The philosophy in RFC3338 became 464XLAT, https://datatracker.ietf.org/doc/html/rfc6877
Right, deploying a CLAT as 464XLAT has would also be a possibility. But 
then the node would be dualstack again and not IPv6 only. That would 
also add administrative overhead compared to NAT64+DNS64 which can be 
deployed on the provider side only.
> As for the DNS64 issue, could the application become NAT64-aware and do the SPF rewriting itself?  See https://datatracker.ietf.org/doc/html/rfc7050 which discusses how that can work on the local a…

I also sent this request to the spfbis mailinglists. And there is also 
currently a discussion on this topic and this has been mentioned before. 
The Tl;Dr of it is the argument on one side that as DNS64 already 
rewrites the DNS and is intended to provide a IPv6 only few of the 
dualstack DNS. Therefore it would also be fair for anyone relying on it 
to assume that it rewrites entries like the SPF record (which counter 
intuitively is currently prohibited by the RFC). And on the other side 
adding a reference to RFC7050 and RFC8880 to the SPF one and patch the 
library because the it would require that the DNS64 server parses 
through all TXT records which can contain arbitrary data in combination 
with the SPF record. It was also mentioned that this could require a new 
informational RFC to be written containing implementation 
recommendations and an evaluation of what other problems mail server 
admins could have with ipv6 only networks.

> I will also +1 Keith's comment that SPF is a borked standard, even if the world had no NATs.  DKIM and DMARC are superior.
We've reached common ground on the dismissal of NAT and SPF as failed 
standards. But neither of our opinions will change that both are broadly 
used, industry favored and therefore we'll having to be dealt with them. 
And I rather have NAT64+DNS64 than dualstack with NAT44 (or sometimes 
NAT444). It's already bad enough that the k8s people want to advocate 
for NAT66 because of a false sense of security. But that's a topic for 
another day...

---

From: Christian Huitema <[email-masked]>
Date: Sun, 6 Feb 2022 18:13:12 -0800

On 2/6/2022 5:52 PM, Keith Moore wrote:
>> A problem with rewriting SPF records within DNS64 is that other IPv4 
>> addresses may well appear in TXT records, throwing a loop to 
>> applications which won't know if the DNS64 has done rewriting or if 
>> the application needs to do rewriting.  A long-standing problem with 
>> NAT "support" for applications since the days of FTP PASV.
>
> +1
>
> application to work-around the damage caused by the NAT.  In 
> hindsight, it would have been far better for NATs to always be 
> explicitly visible to applications; then at least the applications and 
> NATs wouldn't be trying to second-guess one another.
>

DNS64 is a kludge. It looked like a good idea at the time, but there are 
many corner cases. For example, it is well known to not be compatible 
with specifications like DNSSEC. DNS64 also breaks completely is the 
local host uses an encrypted DNS connection (e.g. DoH) to a secure DNS 
resolver. Klaus raises yet another issue: the local SMTP server will see 
incoming connections from an IPv6 address that bears no relation to what 
is in the SPF record of the remote source. This is pretty much the same 
problem as DNSSEC, and the solution is pretty much what is defined in 
Section 6.2. of RFC 6147: "the validator must know how to perform the 
DNS64 function itself". That means the SMTP server should:

1) Know the local NAT64 prefix

2) Recognize that the incoming connection is from the local NAT64 prefix,

3) Perform the reverse translation to retrieve the original IPv4 address,

4) Acquire the original version of the SPF record, either through the 
DNS64 server or through a secure server,

5) Check that the original IPv4 address matches.

Of course, doing that require special code in the SMTP server to handle 
NAT64. But that's pretty much the only solution.

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Feb 2022 21:17:52 -0500

On 2/6/22 21:04, Klaus Frank wrote:

>> The philosophy in RFC3338 became 464XLAT, 
>> https://datatracker.ietf.org/doc/html/rfc6877
> Right, deploying a CLAT as 464XLAT has would also be a possibility. 
> But then the node would be dualstack again and not IPv6 only. That 
> would also add administrative overhead compared to NAT64+DNS64 which 
> can be deployed on the provider side only.
>> As for the DNS64 issue, could the application become NAT64-aware and 
>> do the SPF rewriting itself? See 
>> https://datatracker.ietf.org/doc/html/rfc7050 which discusses how 
>> that can work on the local application.
>
> currently a discussion on this topic and this has been mentioned 
> before. The Tl;Dr of it is the argument on one side that as DNS64 
> already rewrites the DNS and is intended to provide a IPv6 only few of 
> the dualstack DNS. Therefore it would also be fair for anyone relying 
> on it to assume that it rewrites entries like the SPF record (which 
> counter intuitively is currently prohibited by the RFC). And on the 
> other side adding a reference to RFC7050 and RFC8880 to the SPF one 
> and patch the library because the it would require that the DNS64 
> server parses through all TXT records which can contain arbitrary data 
> in combination with the SPF record. It was also mentioned that this 
> could require a new informational RFC to be written containing 
> implementation recommendations and an evaluation of what other 
> problems mail server admins could have with ipv6 only networks.

One problem is, the NAT64 cannot notice every occurrence of an IPv4 
address in every protocol that might reach a host on the "inside" and 
correctly know whether it should translate the address.  It's simply 
impossible for a variety of reasons - the NAT can't track every 
protocol, and it doesn't have cleartext access to all of the traffic 
flowing through it.   Even something as relatively simple as trying to 
translate FTP PORT commands didn't work well.

Another problem is, what you are proposing is an incompatible change, 
which would then require SMTP servers or other spam appliances to adapt 
to the specific NAT64 model and version in use to know whether they 
should respect an SPF record.

The net is far better off if individual SMTP servers or spam filtering 
appliances can be configurable to translate the SPF records themselves, 
and NOT expect NAT64s to do it.   NAT is bad enough without changing how 
it works every time a new protocol is found that needs special handling.

>> I will also +1 Keith's comment that SPF is a borked standard, even if 
>> the world had no NATs.  DKIM and DMARC are superior.
> standards. But neither of our opinions will change that both are 
> broadly used, industry favored and therefore we'll having to be dealt 
> with them. 

Yes, NATs need to be dealt with.  And the way to deal with them is to 
adopt IPv6 wholesale and deprecate NATs, with extreme prejudice, as soon 
as possible.   That won't stop people from using them anyway, but it 
might discourage people from expecting NATs to forever be patched to 
accommodate every new application that they break.

And what is IETF's purpose if not to communicate to the industry how the 
Internet will evolve?   Insisting that IETF must do whatever the 
industry does gets it exactly backwards.   The industry will always 
paint itself into corners without some adult supervision, because that's 
what maximizes short-term profit.

Keith

p.s. I was just thinking of something I heard in 1980, from a friend who 
worked at Xerox PARC: "The problem with smart intermediaries..." (what 
we'd now call middleboxes) "is that they have to be smarter than their 
endpoints."   And that's why it's always been obvious to me not only 
that NATs were a Bad Idea, but also why.

---

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

You left out the other half of Section 6.2 where it says:

    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.

Which is allowing the DNS64 server to rewrite the SPF record...

On 2022-02-07 03:13, Christian Huitema wrote:
>> In general the problem with NATs is that they try to hide what 
>> they're doing from applications.   But they are never completely 
>> successful at that, and they cannot be.    And it's often difficult 
>> for the application to work-around the damage caused by the NAT.  In 
>> explicitly visible to applications; then at least the applications 
>> and NATs wouldn't be trying to second-guess one another.
>>
>> But that's water under the bridge.   At this point the best thing 
>> that can be done is to transition to IPv6 only (except for some 
>> legacy hardware on local networks), and eradicate NATs as soon as 
>> possible.
>
>
> DNS64 is a kludge. It looked like a good idea at the time, but there 
> are many corner cases. For example, it is well known to not be 
> compatible with specifications like DNSSEC. DNS64 also breaks 
> completely is the local host uses an encrypted DNS connection (e.g. 
> DoH) to a secure DNS resolver. Klaus raises yet another issue: the 
> local SMTP server will see incoming connections from an IPv6 address 
> that bears no relation to what is in the SPF record of the remote 
> source. This is pretty much the same problem as DNSSEC, and the 
> solution is pretty much what is defined in Section 6.2. of RFC 6147: 
> "the validator must know how to perform the DNS64 function itself". 
> That means the SMTP server should:
>
> Of course, doing that require special code in the SMTP server to 
> handle NAT64. But that's pretty much the only solution.
>
> -- Christian Huitema
>

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Feb 2022 21:23:47 -0500

> handle NAT64. But that's pretty much the only solution. 

Fortunately about the only consumers of SPF records are SMTP servers and 
spam filters.   And assuming that SPF is still in significant use (sigh) 
the developers of those products will be motivated to add support for 
SPF rewriting in the presence of NAT64.   It seems much better to put 
that optional/configurable fix in SMTP servers and spam filters than to 
burden every NAT64 with it.   Especially since the current trend seems 
to site SMTP servers for inbound mail "in the cloud" or at least in a 
rack somewhere completely outside the enterprise network, or even more 
likely, to outsource the inbound mail service entirely to somewhere that 
probably still has native IPv4 access should it be needed.    (And I 
suspect that trend will last longer than IPv4 does or NAT64 is needed.)

Keith

---

From: Christian Huitema <[email-masked]>
Date: Sun, 6 Feb 2022 18:30:32 -0800

> Which is allowing the DNS64 server to rewrite the SPF record... 

Yes, but doing that requires updating the code on the DNS64 server, 
which may or may not be under the same management as the SMTP server. 
The DNS64 update would  also will still break if the SMTP server is 
configured to access a secure DNS server using encrypted DNS -- DoH, DoT 
or DoQ. Turns out that "use encrypted DNS" is one of the recommendations 
pushed for network security, because it prevents DNS spoofing and DNS 
monitoring attacks. Overall, it is probably easier and more robust to 
deploy a change in the SMTP servers.

-- Christian Huitema

---

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

The DNS64 server could be this secure DNS. Also for providers (esp. 
cloud providers) that want to deploy provider level NAT64 support and 
provide a DNS64 server to allow customers to build ipv6 only networks 
(with additional IPv4aaS) would also benefit from this. Also the noted 
"smtp server and DNS may not be under the same management" is also one 
of the reasons why it should be within DNS64. It is fair to assume that 
when providing a DNS64 service that all parties would assume full 
rewrite of the DNS to support the NAT64. But with SPF being the only 
standard that writes IPv4 addresses into the DNS that is currently *NOT* 
rewritten and by the RFC also stating that "*All other RRs MUST be 
returned unchanged*" it also prevents anyone that want to follow the RFC 
from rewriting the SPF themselves.

On 2022-02-07 03:30, Christian Huitema wrote:
> configured to access a secure DNS server using encrypted DNS -- DoH, 
> DoT or DoQ. Turns out that "use encrypted DNS" is one of the 
> recommendations pushed for network security, because it prevents DNS 
> spoofing and DNS monitoring attacks. Overall, it is probably easier 
> and more robust to deploy a change in the SMTP servers.
>
> -- Christian Huitema
>

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Feb 2022 21:55:55 -0500

On 2/6/22 21:48, Klaus Frank wrote:

> Also the noted "smtp server and DNS may not be under the same 
> management" is also one of the reasons why it should be within DNS64. 

Disagree.  One of the general problem with DNS, BTW, is that the people 
who operate the DNS servers and the people who operate the applications 
that require correct DNS configuration are often not the same people, 
and often don't even work with the same company. So DNS already gets 
out-of-sync with reality too often as it is.

If a NAT takes it upon itself to alter DNS records in flight, there's 
even more potential for the DNS to get out-of-sync with reality, and 
three different parties that have to potentially be reconciled to fix 
the problem.

Of course this is a big reason that applications are increasingly using 
DoH or DoT to query a trusted server whenever possible - to minimize the 
potential for some third party to have screwed things up.

Keith

---

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

🙄This is just anti DNS64 all together... Can we assume for the sake of 
this discussion that one actually wants to use the DNS64 resolver?

On 2022-02-07 03:55, Keith Moore wrote:
> Disagree.  One of the general problem with DNS, BTW, is that the 
> people who operate the DNS servers and the people who operate the 
> applications that require correct DNS configuration are often not the 
> same people, and often don't even work with the same company. So DNS 
> already gets out-of-sync with reality too often as it is.
>
> Of course this is a big reason that applications are increasingly 
> using DoH or DoT to query a trusted server whenever possible - to 
> minimize the potential for some third party to have screwed things up.
>
> Keith
>
>

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Feb 2022 22:04:43 -0500

On 2/6/22 22:01, Klaus Frank wrote:

> 🙄This is just anti DNS64 all together... Can we assume for the sake 
> of this discussion that one actually wants to use the DNS64 resolver? 

Again, trying to misstate my argument.  I wish you would stop.

DNS64 exists, for better or worse.  I'm just arguing to keep it stable 
and not make it worse.  Let it die in peace.

Keith

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 7 Feb 2022 07:34:52 +0100

El 7/2/22 a las 3:48, Klaus Frank escribió:
> The DNS64 server could be this secure DNS.

This would consistent with the deployment scenario presented in section 
7.1 of RFC6147.

Regards, marcelo

> Also for providers (esp. cloud providers) that want to deploy provider 
> level NAT64 support and provide a DNS64 server to allow customers to 
> build ipv6 only networks (with additional IPv4aaS) would also benefit 
> from this. Also the noted "smtp server and DNS may not be under the 
> same management" is also one of the reasons why it should be within 
> DNS64. It is fair to assume that when providing a DNS64 service that 
> all parties would assume full rewrite of the DNS to support the NAT64. 
> But with SPF being the only standard that writes IPv4 addresses into 
> the DNS that is currently *NOT* rewritten and by the RFC also stating 
> that "*All other RRs MUST be returned unchanged*" it also prevents 
> anyone that want to follow the RFC from rewriting the SPF themselves.
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 7 Feb 2022 07:40:25 +0100

below...

> NATs.   But that ship sailed decades ago.)

My guess is that NAT was done wrong because the IETF decided against 
standardizing NATS in due time because it was a kludge that should not 
be done, maybe?

NATs are reality (I hope we all agree with that). I guess it is more 
productive to try to provide guidance about how to make them as harmfull 
as possible rather that ignore them, provide no guidance and end up with 
all possible version of NATs, including the worst possible ones.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 7 Feb 2022 07:41:31 +0100

> Nonetheless DNS64 is incomplete without also addressing the SPF record.

I guess one operative question is whether this issue can be dealt with 
an errata or should require an update in the spec.

Regards, marcelo

>> external/global addresses that they're communicating with, even if 
>> the source IP addresses that they see aren't the real ones.  (If NATs 
>> had been done "right" there would be an API for this, supported by 
>> all NATs.   But that ship sailed decades ago.)
>>
>> usual problem with telling lies: every lie you tell needs N 
>> additional lies to cover up the earlier lies and so on recursively.
>>
>> (also, relying on SPF records is ill-advised, as they're too likely 
>> to be out-of-sync with reality even without NATs in the picture. )
>>
>> Keith
>>
>>

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2022 08:11:02 -0500

Sent from my iPhone

> On Feb 7, 2022, at 1:40 AM, marcelo bagnulo braun <[email-masked]> wrote:
> 
> My guess is that NAT was done wrong because the IETF decided against standardizing NATS in due time because it was a kludge that should not be done, maybe?

No I don’t think so.  I don’t think anyone ever figured out how to do NATs even close to “right”.  I tried to do so for many years, and never managed to solve some of the serious problems.  And of course by that time “wrong” NATs were so widely deployed that there was no hope of fixing them anyway.

Bottom line: NATs are inherently incompatible with the internet architecture and with any network architecture that offers near-complete interconnection between hosts.  And also inherently incompatible with DNS. 

The only reason that NATs have been able to survive is that they more-or-less worked with the web and email.  But they crippled many other applications.  Meanwhile email has since (to my great disappointment) been crippled in other ways, and the web is a security and privacy disaster, and it turns out that people need a wider variety of applications than the web and email anyway.  

> 
> NATs are reality (I hope we all agree with that). I guess it is more productive to try to provide guidance about how to make them as harmfull as possible rather that ignore them, provide no guidance and end up with all possible version of NATs, including the worst possible ones.

Saying that something is reality is no justification for keeping it.  I suppose it would be more precise to say that NATs have mindshare - lots of people think that NATs are just how the internet works.  But the problems with NATs and also with IPv4 are more widely understood than ever.  It’s time to abandon both and set an EOL date for the public IPv4 internet. 

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2022 08:12:32 -0500

Sent from my iPhone

> On Feb 7, 2022, at 1:42 AM, marcelo bagnulo braun <[email-masked]> wrote:
> 
> I guess one operative question is whether this issue can be dealt with an errata or should require an update in the spec.

Neither.  That SPF and TXT records are not altered is a feature, not a bug.

---

From: Klaus Frank <[email-masked]>
Date: Mon, 7 Feb 2022 13:21:05 +0000

How should that be a feature? It's clearly a bug...

---

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

Oh, this is undoubtedly true. I even see this in discussions with peers. 
They know perfectly how routing works. But then something in their mind 
breaks when they cannot deploy a NAT at every network border... (This is 
sadly not a joke, even though it sounds like one). For them routing is 
what you do within the company and if you want to leave the company or 
want to pass through a firewall you'll need to NAT it to a public IP...

And just that you know, I'd also vote for deprecating NAT entirely, but 
that wouldn't change anything. But this is all off topic again.

On 2022-02-07 14:11, Keith Moore wrote:
>   I suppose it would be more precise to say that NATs have mindshare - lots of people think that NATs are just how the internet works.  But the problems with NATs and also with IPv4 are more widely understood than ever.  It’s time to abandon both and set an EOL date for the public IPv4 internet.

---

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

I think an errata that either changes the "MUST not change" into a 
"SHOULD not change" is enough. As that would provide enough freedom to 
add a feature to update the SPF record without violating the RFC. And 
additionally add a note to that errata that explicitly lists SPF as one 
case where another record may need to be changed.

On 2022-02-07 07:41, marcelo bagnulo braun wrote:
>>>> 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 
>>> the source IP addresses that they see aren't the real ones.  (If 
>>> NATs had been done "right" there would be an API for this, supported 
>>> by all NATs.   But that ship sailed decades ago.)
>>>
>>> More generally, NAT is inherently unfixable, and trying to fix it 
>>> can only result in infinitely growing complexity and brokenness. 
>>> It's the usual problem with telling lies: every lie you tell needs N

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2022 08:39:45 -0500

Sent from my iPhone

> On Feb 7, 2022, at 8:31 AM, Klaus Frank <[email-masked]> wrote:
> 
> I think an errata that either changes the "MUST not change" into a "SHOULD not change" is enough.

No.  The current text is not an error.  SHOULD NOT change is worse than MUST NOT.

If any “erratum” is appropriate, it should say “the existing text is correct as written.”

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2022 08:41:20 -0500

Sent from my iPhone

> On Feb 7, 2022, at 8:21 AM, Klaus Frank <[email-masked]> wrote:
> 

No, NATs are the bug.  That DNS is designed to report consistent results everywhere is a feature.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 7 Feb 2022 15:40:33 +0100

I think I liked better the one you suggested earlier.

I guess the procedure is that you can submit the errata and the it will 
be considered.

El 7/2/22 a las 14:30, Klaus Frank escribió:
> additionally add a note to that errata that explicitly lists SPF as 
> one case where another record may need to be changed.
>
>> I guess one operative question is whether this issue can be dealt 
>> with an errata or should require an update in the spec.
>>
>> Regards, marcelo
>>
>>
>>
>>>>> 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.
>>>>
>>>> NATs had been done "right" there would be an API for this, 
>>>> supported by all NATs.   But that ship sailed decades ago.)
>>>>
>>>> It's the usual problem with telling lies: every lie you tell needs 
>>>> N additional lies to cover up the earlier lies and so on recursively.
>>>>

---

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

Dear colleagues,

I am one of the primary offenders behind DNS64.  I work for the Internet Society, but I'm not speaking for them or anyone else.

On Sun, Feb 06, 2022 at 06:13:12PM -0800, Christian Huitema wrote:
>
>DNS64 is a kludge. It looked like a good idea at the time

No, it didn't look like a good idea at the time, at least not to me.  It looked like a _good enough_ idea at the time, for a narrow set of purposes that was supposed to get past some transition difficulties.  I think we tried to be pretty clear that there were a number of pretty serious limitations (see RFC 6147, section 6).  SPF, and anything else that tries to overload the TXT record with some sort of structured data, looks like another example of issues that just wasn't enumerated in that section 6.

>handle NAT64. But that's pretty much the only solution.

I agree that, at the very least, this is a case where the SPF handler needs to be NAT64/DNS64 aware.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

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

[ObDisclaimer: again, speaking just for myself]

>an errata or should require an update in the spec.

There is no error in the text of the RFC: it works as intended.  If people want to change DNS64 to parse TXT records and start fooling with the RDATA in there according to some heuristics, then that is a protocol change and not something that can be handled via errata.

The data types that DNS64 changes are well-defined types with well-defined semantics for the RDATA.  TXT records, by contrast, can contain whatever somebody wants, and there is no reaason to suppose that SPF is the only case where an IPv4 address might be in there.  The fact that SPF overloaded TXT to try to put structured data in it means that SPF needs to understand something about the data structure it is dealing with, so it's the SPF handler that needs to be made DNS64-aware just as a validating resolver behind DNS64 needs to be DNS64 aware.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Feb 2022 07:56:39 -0800

> On Feb 7, 2022, at 5:11 AM, Keith Moore <[email-masked]> wrote:
> 
> Sent from my iPhone
> 
> Neither.  That SPF and TXT records are not altered is a feature, not a bug

Marcelo,

Errata is for errors, not for changing the specifications. The current text absolutely reflects the decisions of the WG at the time. To change the decision would require a new version. In fact, it would also require a debate, because there are two solutions.

One potential solution is to say that the text is right, that NAT64 should only work with A and AAAA records, and that applications using other records that embed IP addresses should be cognizant of NAT64 and apply their own logic.

That's not what Klaus hoped for, but there are several arguments for that approach, especially in the case of records with security implications like SPF. Arguably, applications relying on such records should acquire them in secure ways, which precludes alterations in the middle.

There are also deployment arguments for the end to end approach. New records can be created at any time. The applications using them know that, and are expected to have code to handle them. NAT64 don't. They ship in devices like home routers that are notoriously slow to upgrade. Even if we told them to upgrade, they would only do that slowly, and applications that need it immediately will still need to add the NAT64 code.

So, no, this is not material for an errata. Maybe just additional guidance about deployment and knowledge in applications. Or, failing that, a revised RFC.

-- Christian Huitema

---

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

> That's not what Klaus hoped for, but there are several arguments for that approach, especially in the case of records with security implications like SPF. Arguably, applications relying on such rec…
I was hoping for clarification and an alignment between both working 
groups (and maybe an official recommendation i.e. Informational RFC) and 
to find a solution for the future. So that this problem doesn't stay 
unresolved.
> There are also deployment arguments for the end to end approach. New records can be created at any time. The applications using them know that, and are expected to have code to handle them. NAT64 d…

I want to disagree partially with you on this one. You always say NAT64 
as a combination of DNS64 and NAT64. Truth is, that these are two 
distinct things that are offered from two different origins. Even though 
a NAT64 may be on slow updating home routers (though unlikely, a CLAT 
would be more likely here). The DNS64 isn't. The home routers only have 
plain forwarding. They forward to the DNS infrastructure of the ISP. 
Therefore changing DNS64 (not NAT64) would indeed be feasible as it is 
within a way better maintained and updated environment. And also the 
NAT64 gateways would residue in the ISP infrastructure and not within 
the home router itself. The home router would then just forward IPv6 
only traffic towards the ISP... (see figure 2, 3 and 4 
https://tools.ietf.org/id/draft-ietf-v6ops-nat64-deployment-03.html)

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2022 12:01:53 -0500

On 2/7/22 11:38, Klaus Frank wrote:

> groups (and maybe an official recommendation i.e. Informational RFC) 
> and to find a solution for the future. So that this problem doesn't 
> stay unresolved. 

There is no possible solution to the NAT problem, except to not use 
NATs.   The problems will never be resolved because Internet 
applications are not static.

Keith

---

From: David Conrad <[email-masked]>
Date: Mon, 7 Feb 2022 09:18:32 -0800

Keith,

On Feb 7, 2022, at 9:01 AM, Keith Moore <[email-masked]> wrote:
>> I was hoping for clarification and an alignment between both working groups (and maybe an official recommendation i.e. Informational RFC) and to find a solution for the future. So that this problem doesn't stay unresolved.
> 
> There is no possible solution to the NAT problem, except to not use NATs.   The problems will never be resolved because Internet applications are not static.

You are aware of what the BEHAVE working group's charter was, right?

As far as I can tell, Klaus has identified a specific issue in which existing IETF specifications are deficient in order to facilitate interoperability in a specific protocol when NAT64 is in use.

Reiterating yet again how you think NAT is a bad idea does not appear to be constructive or helpful in any way.

The need to deal with NAT (in its myriad forms) is simply reality and will remain so for the foreseeable future.

Regards,
-drc

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2022 12:25:01 -0500

> You are aware of what the BEHAVE working group's charter was, right?
yes.   Perhaps a noble attempt that failed, perhaps an errand for 
fools.  At the time BEHAVE was chartered I thought there might be a way 
to make NATs saner by making applications explicitly aware of them and 
letting applications explicitly control NAT bindings.   In hindsight I 
think it was far too late to fix NATs by then, but maybe it never was 
possible anyway.
> As far as I can tell, Klaus has identified a specific issue in which existing IETF specifications are deficient in order to facilitate interoperability in a specific protocol when NAT64 is in use.

To the extent that the specifications are deficient, it's because the 
approach was inherently deficient.

> Reiterating yet again how you think NAT is a bad idea does not appear to be constructive or helpful in any way.
Not buying it.    The problem with that attitude is that it makes it 
always okay to promote and encourage bad ideas, and to perpetually keep 
patching up the harm that they cause... but it's never okay to 
discourage them.
> The need to deal with NAT (in its myriad forms) is simply reality and will remain so for the foreseeable future.

Saying "X is reality" is a lot like saying "it is clear that..." or any 
other assertion that lacks support.   It's transparently vacuous.

NATs are reality like COVID is reality.  That's not a justification for 
encouraging more spread of COVID.

Keith

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Feb 2022 09:43:52 -0800

> On Feb 7, 2022, at 9:24 AM, Keith Moore <[email-masked]> wrote:
> 
>> ...
> To the extent that the specifications are deficient, it's because the approach was inherently deficient.

I think the approach in RFC6147 is a reasonable compromise for deploying 6to4: handle the common case for unmodified hosts; recognize that this is a kludge; steer to end-to-end solutions for all complex cases.

We are not going to undeploy NAT64, let alone NAT. But we can certainly provide guidance for implementing end to end solutions for all complex cases. Given deployment of DoH, this will be needed soon.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Feb 2022 09:57:44 -0800

> I think the approach in RFC6147 is a reasonable compromise for deploying 6to4: handle the common case for unmodified hosts; recognize that this is a kludge; steer to end-to-end solutions for all co…
Think what you want about my internal brain processes, but I actually 
meant to write NAT64, not 6to4.
> We are not going to undeploy NAT64, let alone NAT. But we can certainly provide guidance for implementing end to end solutions for all complex cases. Given deployment of DoH, this will be needed so…

By the way, I wrote these emails before reading Andrew Sullivan's 
response. I agree with Andrew.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Feb 2022 10:03:16 -0800

On 2/6/2022 10:34 PM, marcelo bagnulo braun wrote:
> This would consistent with the deployment scenario presented in 
> section 7.1 of RFC6147. 

Maybe. But the situation has changed since April 2011. ISPs cannot any 
more assume that all hosts will be using the resolver embedded in the 
NAT64 gateway -- some hosts, or some applications, may very well use 
some alternate encrypted DNS service, e.g., using DoH and connect to 
Quad9, Cloudflare or Google. The cases describe in section 6 of RFC6147 
are going to be more and more frequent. We should make them work, and we 
should tell application developers about that.

-- Christian Huitema

---

From: David Conrad <[email-masked]>
Date: Mon, 7 Feb 2022 10:06:46 -0800

Keith,

On Feb 7, 2022, at 9:25 AM, Keith Moore <[email-masked]> wrote:
> Not buying it.    The problem with that attitude is that it makes it always okay to promote and encourage bad ideas, and to perpetually keep patching up the harm that they cause... but it's never okay to discourage them.

I suppose I don’t find continually putting my fingers in my ears and chanting “NAT is bad” any time the topic comes up particularly productive. YMMV.

> Saying "X is reality" is a lot like saying "it is clear that..." or any other assertion that lacks support.   It's transparently vacuous.

Are you actually suggesting the vast majority of Internet traffic does not transit a NAT?

> NATs are reality like COVID is reality.  That's not a justification for encouraging more spread of COVID.

It’s not about encouraging spread. That ship sailed long, long ago. It is about accepting reality and coming up with solutions, as ad hoc as may be required, to reduce the pain that that reality entails.

Regards,
-drc

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2022 13:10:04 -0500

> I suppose I don’t find continually putting my fingers in my ears and chanting “NAT is bad” any time the topic comes up particularly productive. YMMV.
I suppose I don't find constantly trying to find solutions to every new 
problem that NATs cause particularly productive either, which is why I 
occasionally remind people that that's counterproductive.

> It’s not about encouraging spread. That ship sailed long, long ago. It is about accepting reality and coming up with solutions, as ad hoc as may be required, to reduce the pain that that reality en…

If NATs weren't reality, there would be no need to get rid of them.   
But ultimately that is the only solution.

Keith

---

From: David Conrad <[email-masked]>
Date: Mon, 7 Feb 2022 10:37:28 -0800

Dan,

On Feb 6, 2022, at 4:58 PM, Dan Wing <[email-masked]> wrote:
> A problem with rewriting SPF records within DNS64 is that other IPv4 addresses may well appear in TXT records, throwing a loop to applications which won't know if the DNS64 has done rewriting or if the application needs to do rewriting.

Yes, IPv4 addresses (or what may look like IPv4 addresses) can exist in TXT records arbitrarily, however, IIRC, SPF TXT records are fairly tightly constrained to start with “v=spf1 …” and the content of interest here must be prefixed with “ipv4: “.  Given this, I’d imagine it’d be pretty straight forward for DNS64 to find the relevant IPv4 addresses to do whatever transforms are necessary, leaving other IPv4 addresses embedded in TXT RRs as Someone Else’s Problem (if encountered).

That is, instead of boiling the ocean, perhaps point solutions will suffice in an effort to address an identified operational issue?

Regards,
-drc

---

From: Klaus Frank <[email-masked]>
Date: Mon, 7 Feb 2022 18:38:08 +0000

Cloudflare and google both have also DNS64 revolvers exactly for that 
reason...

On 2022-02-07 19:03, Christian Huitema wrote:
> Quad9, Cloudflare or Google. The cases describe in section 6 of 
> RFC6147 are going to be more and

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 07 Feb 2022 19:49:02 +0100

And those resolvers will not work if instead of the WKP a NSP is being used.

https://datatracker.ietf.org/doc/rfc8683/

Regards,
Jordi
@jordipalet

El 7/2/22 19:39, "Behave en nombre de Klaus Frank" <[email-masked] en nombre de [email-masked]> escribió:

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

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

Instead of reminding people on here about how you disapprove of NATs 
your time may be better spent going after the k8s community (and others) 
and talking them out of wanting to further adoption and encourage the 
use of NAT66. We cannot change the past. But we've a change to steer the 
future and avoid repeating mistakes...

On 2022-02-07 19:10, Keith Moore wrote:
>> I suppose I don’t find continually putting my fingers in my ears and 
>> chanting “NAT is bad” any time the topic comes up particularly 
>> productive. YMMV.
> I suppose I don't find constantly trying to find solutions to every 
> new problem that NATs cause particularly productive either, which is 
> why I occasionally remind people that that's counterproductive.
>
>> It’s not about encouraging spread. That ship sailed long, long ago. 
>> It is about accepting reality and coming up with solutions, as ad hoc 
>> as may be required, to reduce the pain that that reality entails.
>

---

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

True, but I'm not aware that anyone would favor using NSP instead of WKP 
anywhere except in transit. And within transit we don't need any DNS64...

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2022 14:31:04 -0500

> Yes, IPv4 addresses (or what may look like IPv4 addresses) can exist in TXT records arbitrarily, however, IIRC, SPF TXT records are fairly tightly constrained to start with “v=spf1 …” and the conte…

No, that just makes the problem worse.  At present, the responsibility 
to deal with SPF records when operating behind a NAT is clearly with the 
consumer of the SPF records.   If the DNS64 engine is allowed to try to 
address that problem instead, then the location of that responsibility 
becomes unclear, and it's likely to change and break things without 
anybody noticing. Consistent behavior is Good; trying to constantly 
change how the network works to solve problems that are unfixable is 
Bad.  It adds complexity with no hope of ever reducing it.

Especially when, in practice, SPF records are likely to be wrong and to 
result in failure of legitimate mail to be delivered, without any 
indication to anyone who can fix it.   So trying to fix the SPF+NAT 
problem is doubly counterproductive.

Want to fix the NAT instead?  Arrange for there to ALWAYS be some 
signaling available to every app behind the NAT as to what the address 
binding is.   Don't make the app try to second-guess the NAT and don't 
have the NAT try to second-guess the app.   That way lies madness, as 
we've seen for 25+ years.

Keith

---

From: Dan Wing <[email-masked]>
Date: Mon, 7 Feb 2022 11:37:34 -0800

Klaus, David,

I just grabbed an email in this thread to propose a different idea:

Could the SPF problem dissipate if SPF records only contained DNS names and deprecate IP addresses?  Consider we had (and still have) the same issue with IPv4 addresses in URLs (https://datatracker.ietf.org/doc/html/rfc6586#section-6.1, e.g., http://1.2.3.4) which break with DNS64/NAT64 because 1.2.3.4 is not a valid IPv6 address.  The solution there was (and still is) push those deployments to use DNS names rather than IP addresses.  Of course nobody wants to spend their career chasing down websites using IPv4 address literals, which is what begat 464XLAT.

I don't have a list of top NNN mail servers, but I see both address literals (e.g., comcast.com, microsoft.com) and domain names (e.g., gmail.com which does SPF redirect to _spf.google.com which has only domain names).

-d

---

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

Google and O365 have a lot of IPs in their records. Currently the 
standard is to specify the subnets instead of dns names (for whatever 
reason). If you now further perform TXT-RR lookups of these includes 
you'll get new SPF records that contain lists of subnets e.g.:

google.com ("v=spf1 include:_spf.google.com ~all") => _spf.google.com 
("v=spf1 include:_netblocks.google.com include:_netblocks2.google.com 
include:_netblocks3.google.com ~all") => _netblocks.google.com ("v=spf1 
ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 
ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 
ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 
ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"), _netblocks2.google.com 
("v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 
ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 
ip6:2c0f:fb50:4000::/36 ~all") and _netblocks3.google.com ("v=spf1 
ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 
ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 
ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 
ip4:130.211.0.0/22 ~all")

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2022 14:51:12 -0500

On 2/7/22 14:37, Dan Wing wrote:

> Could the SPF problem dissipate if SPF records only contained DNS names and deprecate IP addresses?

I suspect this just would just make SPF records even less reliable than 
they already are, because the DNS name adds an extra layer of 
indirection that also has a high probability of being wrong.

Also, it doesn't rid the burden of applications operating behind the NAT 
to be aware of the NAT.   For better or worse, applications have a lot 
of incentive to use DoH or DoT because local resolvers are sometimes 
under-provisioned or unreliable, network providers sometimes spy on DNS 
traffic, etc.  Using DoH or DoT can result in more reliable, consistent 
operation with less delay due to DNS lookup time.   So if the 
application is going to benefit from SPF records having DNS names in 
them, it has to know to use the DNS64 server to lookup those DNS names 
and get the (possibly fake) IPv6 source addresses back.

The general problem that DNS is often out of sync with reality (at least 
in part because DNS isn't federated in the same way that reality is) is 
hard to fix.

Keith

---

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

On 2022-02-07 20:51, Keith Moore wrote:
> I suspect this just would just make SPF records even less reliable 
> than they already are, because the DNS name adds an extra layer of 

Not really. Using DNS is already part of the SPF standard (section 5.7) 
via "v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all":

    The <target-name> might expand to
    "1.2.0.192.someuser._spf.example.com".  This makes fine-grained
    decisions possible at the level of the user and client IP address.

> Also, it doesn't rid the burden of applications operating behind the 
> NAT to be aware of the NAT.   For better or worse, applications have a 
> lot of incentive to use DoH or DoT because local resolvers are 
> sometimes under-provisioned or unreliable, network providers sometimes 
> spy on DNS traffic, etc.  Using DoH or DoT can result in more 
> reliable, consistent operation with less delay due to DNS lookup 
> time.   So if the application is going to benefit from SPF records 
> having DNS names in them, it has to know to use the DNS64 server to 
> lookup those DNS names and get the (possibly fake) IPv6 source 
> addresses back.
>
> The general problem that DNS is often out of sync with reality (at 
> least in part because DNS isn't federated in the same way that reality 
> is) is hard to fix.
What exactly do you mean Split-DNS? Which is another pitfall why using 
DoH and DoT is problematic and (from admin perspective) not desirable. 
And when they're used to use the same DNS infrastructure you consider 
"out of sync" via a DoH or DoT resolver...

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2022 15:26:46 -0500

On 2/7/22 15:00, Klaus Frank wrote:

> Not really. Using DNS is already part of the SPF standard (section 
> 5.7) via "v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all":
>

I'm aware of that, but common practice among mail operators seems to be 
to use IP addresses.  I'm not sure what their reasons for that are - 
they might simply want to make lookups more efficient - but it's a 
truism that every extra layer of indirection is another opportunity for 
configuration error.   (Unless perhaps all such DNS records are 
automatically updated from a network configuration database, but I don't 
think that practice is nearly universal yet.)

>> sometimes under-provisioned or unreliable, network providers 
>> sometimes spy on DNS traffic, etc.  Using DoH or DoT can result in 
>> more reliable, consistent operation with less delay due to DNS lookup 
>> least in part because DNS isn't federated in the same way that 
>> reality is) is hard to fix.

Split DNS is indeed a problem.  DNS was simply not designed to work that 
way.   It's Mostly Harmless IMO if the only thing that Split DNS is used 
for is to hide records of internal hosts that aren't supposed to be 
externally reachable anyway.   If the connection attempt will never 
succeed anyway, DNS Name Lookup Failure is not (much) worse than 
Connection Timed Out.   But when DNS presents different successful query 
results depending on who is asking, that's a Bad Idea.   It's not 
reasonable for a DNS server to assume that the connection attempt would 
be made from the same source IP address, or even network, that the query 
is coming from.   The very fact that DNS explicitly supports and 
encourages caching should make that clear.   DNS was never expected to 
reflect network topology.

But "DNS is out of sync with reality" is a more general problem than 
that.  It's simply that the people who maintain DNS and the people who 
maintain the applications and the hosts on which those applications run, 
are often different people, in different departments or even different 
companies.   Sometimes the problem is even worse.  I once worked for a 
company that hired a marketing firm to revamp its web site.  That 
marketing firm, or its web designers, not only updated the HTML/JS/etc 
code for the web site but also apparently arranged for new DNS hosting 
and told the network admin to change their NS records to point to the 
new DNS hosts.  And corporate marketing ordered the local IT people to 
Make It So.   That broke every other network-based app that the company 
had, because both the hired marketing firm and corporate marketing 
didn't even have any idea that there might be other uses for a company's 
domain name than to reach their web site or to find the inbound SMTP 
server.   This might seem like an unusual example, but in my experience 
this kind of problem has been quite common.

I'm aware that there's a tussle between local network admins and 
application vendors over whether to use DoT/DoH.  I firmly side with the 
application vendors, because unreliable DNS (even from major ISPs) is 
far too common.   Applications need a predictable and reasonably 
reliable environment to operate in.   From the point of view of 
application vendors, local DNS resolvers behave very inconsistently and 
with widely varying degrees of reliability, and there are lots of 
longstanding security issues with port 53.  Realistically, many 
applications have to have some support for lookup of local names anyway, 
so they still need to consult local DNS resolvers for some things.  But 
if the application knows that a particular server it's using is on the 
public Internet, using DoH/DoT exclusively to find that server, or using 
the local resolver only as a last resort, makes a lot of sense.

Keith

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Feb 2022 12:38:10 -0800

> As far as I can tell, Klaus has identified a specific issue in which existing IETF specifications are deficient in order to facilitate interoperability in a specific protocol when NAT64 is in use.

Yes.

We have an unresolved tension between recommending end-to-end solutions 
and recommending more processing in DNS64, which means the IETF will 
probably need to charter some work if we want to publish a consensus 
document. But the current discussion yielded both ideas and data.

According to Klaus, practical deployments of NAT64 in ISP use WKP, not 
NSP. That's interesting. I trust Klaus on that one, and it makes sense: 
ISP want to avoid breakage, and if using WKP is less likely to cause 
breakage than using NSP, they will use that. That also means that the 
job of the application writer becomes simpler: it is much easier to have 
a special case for WKP than to invent a way to learn the NSP. This could 
lead to an interesting feedback loop, in which more applications working 
with WKP means even less incentives for ISP to use NSP. This kind of 
loop is common and powerful. And maybe that's something that we can 
document.

-- Christian Huitema

---

From: Klaus Frank <[email-masked]>
Date: Mon, 7 Feb 2022 21:14:16 +0000

On 2022-02-07 21:38, Christian Huitema wrote:
>> As far as I can tell, Klaus has identified a specific issue in which 
>> existing IETF specifications are deficient in order to facilitate 
>> interoperability in a specific protocol when NAT64 is in use.
>
> Yes.
>
> We have an unresolved tension between recommending end-to-end 
> solutions and recommending more processing in DNS64, which means the 
> IETF will probably need to charter some work if we want to publish a 
> consensus document. But the current discussion yielded both ideas and 
> data.
>
> NSP. That's interesting. I trust Klaus on that one, and it makes 
> sense: ISP want to avoid breakage, and if using WKP is less likely to 
> cause breakage than using NSP, they will use that. That also means 
> that the job of the application writer becomes simpler: it is much 
> easier to have a special case for WKP than to invent a way to learn 
> the NSP. This could lead to an interesting feedback loop, in which 
> more applications working with WKP means even less incentives for ISP 
> to use NSP. This kind of loop is common and powerful. And maybe that's 
> something that we can document.

 From what I've seen ISPs use both (and while I worked at a cloud 
provider we provided dualstack + WKP to allow customers to build IPv6 
only infra).
WKP in access i.e. customer facing (where DNS64 is necessary) and
NSP in backends for routing and peering/transit (where no DNS is needed) 
but also only if WKP is not an option for whatever reason.

---

From: Dan Wing <[email-masked]>
Date: Mon, 7 Feb 2022 14:49:47 -0800

Thanks.  Clearly I didn't dig deep enough into Google's configuration.

Has anyone swept the top-NNN mail operators to pull their SPF records.  Knowing how pervasive a problem could help charter work to build a consensus solution.

-d

> On Feb 7, 2022, at 11:47 AM, Klaus Frank <[email-masked]> wrote:
> 
> Google and O365 have a lot of IPs in their records. Currently the standard is to specify the subnets instead of dns names (for whatever reason). If you now further perform TXT-RR lookups of these includes you'll get new SPF records that contain lists of subnets e.g.:
> 
> google.com ("v=spf1 include:_spf.google.com ~all") => _spf.google.com ("v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all") => _netblocks.google.com ("v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"), _netblocks2.google.com ("v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all") and _netblocks3.google.com ("v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all")
> 
>

---

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

Hi,

>Yes, IPv4 addresses (or what may look like IPv4 addresses) can exist in TXT records arbitrarily, however, IIRC, SPF TXT records are fairly tightly constrained to start with “v=spf1 …” and the conten…

I think I pointed this out on the other list, but there's a difference in kind between the two cases.

For A and PTR records, a DNS64 knows that it has work to do because the datatype tells you so.  Part of the problem in SPF's case is that it uses TXT, which can contain any arbitrary text.  So, this means that _at the very least_ the DNS64 needs to parse some part of the RDATA before it can decide whether it needs to act.  It's a different model, and there is no reason to suppose that the code path that relies on strongly-typed data will work well for data that is effectively untyped.

Moreover, I think it is really weird to suggest that DNS64 is going to start picking and choosing when it's going to fiddle with the IP literals in the RDATA it is dealing with.  If DNS64 is supposed to fix up IPv4 literals in TXT records when SPF is working, it will be entirely natural for people to generalize that to "DNS64 alters IPv4 literals in TXT records" rather than "DNS64 alters IPv4 literals in TXT records where the RDATA starts "v-spf1…."  Then there will be a new surprise when it works for SPF but not for some other case where an IP literal is in a TXT record (which might not, of course, even be aa standard).

When we made DNS64, the DNSSEC handling depended on the idea that, if you're planning to do validation yourself, you'd need to do DNS64 yourself too; and if you couldn't, it would break.  I think this is sort of an analagous case: if you need to handle IP literals inside DNS data that is not designed to carry such literals, then you're going to need to be aware of how to handle such literals.  That argues for making the SPF processor DNS64 aware for cases when it's going to be used behind DNS64.  DNS64 was always kinda brittle; this is just another example of it.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 7 Feb 2022 18:30:02 -0500

On 2/7/22 18:24, Andrew Sullivan wrote:
> For A and PTR records, a DNS64 knows that it has work to do because 
> the datatype tells you so.  Part of the problem in SPF's case is that 
> it uses TXT, which can contain any arbitrary text. So, this means that 
> _at the very least_ the DNS64 needs to parse some part of the RDATA 
> before it can decide whether it needs to act.  It's a different model, 
> and there is no reason to suppose that the code path that relies on 
> strongly-typed data will work well for data that is effectively untyped.
>
> Moreover, I think it is really weird to suggest that DNS64 is going to 
> start picking and choosing when it's going to fiddle with the IP 
> literals in the RDATA it is dealing with.  If DNS64 is supposed to fix 
> up IPv4 literals in TXT records when SPF is working, it will be 
> entirely natural for people to generalize that to "DNS64 alters IPv4 
> literals in TXT records" rather than "DNS64 alters IPv4 literals in 
> TXT records where the RDATA starts "v-spf1…."  Then there will be a 
> new surprise when it works for SPF but not for some other case where 
> an IP literal is in a TXT record (which might not, of course, even be 
> aa standard).
>
> When we made DNS64, the DNSSEC handling depended on the idea that, if 
> you're planning to do validation yourself, you'd need to do DNS64 
> yourself too; and if you couldn't, it would break.  I think this is 
> sort of an analagous case: if you need to handle IP literals inside 
> DNS data that is not designed to carry such literals, then you're 
> going to need to be aware of how to handle such literals.  That argues 
> for making the SPF processor DNS64 aware for cases when it's going to 
> be used behind DNS64.  DNS64 was always kinda brittle; this is just 
> another example of it. 

+1

---

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

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

---

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 10 Feb 2022 08:07:41 +0100

El 7/2/22 a las 19:03, Christian Huitema escribió:
> RFC6147 are going to be more and more frequent. We should make them 
> work, and we should tell application developers about that.
>
DNS64 doesnt have to be collocated withthe NAT64 box.

The scenario 7.1 still holds in case the user is using an external 
reoslver, such as cloudflare. The thing is that the external resolver 
must then implement the DNS64.

This works fine as long as the WKP is used.

Regards, marcelo

---

From: Christian Huitema <[email-masked]>
Date: Wed, 9 Feb 2022 23:27:16 -0800

On 2/9/2022 11:07 PM, marcelo bagnulo braun wrote:

>> Maybe. But the situation has changed since April 2011. ISPs cannot 
>> any more assume that all hosts will be using the resolver embedded in 
>> the NAT64 gateway -- some hosts, or some applications, may very well 
>> use some alternate encrypted DNS service, e.g., using DoH and connect 
>> to Quad9, Cloudflare or Google. The cases describe in section 6 of 

How does the external resolver know when it should implement DNS64 and 
when it shouldn't?

> This works fine as long as the WKP is used. 

Lot's of stuff will work better if the WKP is used...

-- Christian Huitema

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 10 Feb 2022 08:38:07 +0100

El 10/2/22 a las 8:27, Christian Huitema escribió:
>>> any more assume that all hosts will be using the resolver embedded 
>>> in the NAT64 gateway -- some hosts, or some applications, may very 
>>> well use some alternate encrypted DNS service, e.g., using DoH and 
>>> connect to Quad9, Cloudflare or Google. The cases describe in 
>>> section 6 of RFC6147 are going to be more and more frequent. We 
>>> should make them work, and we should tell application developers 
>>> about that.
>>>

I would assume that the external resolver provider makes public which 
resolver instances implement DNS64 and which do not and the clients 
select accordingly?

I guess another alternative would be for the resolver to do dns64 for 
cusotmers connecting through IPv6 and obtain replies that return only A 
RR, but this sounds like a bad idea to me....

---

From: <[email-masked]>
Date: Thu, 10 Feb 2022 09:20:04 +0000

Hi Marcelo, all, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Behave <[email-masked]> De la part de marcelo bagnulo
> braun
> Envoyé : jeudi 10 février 2022 08:08
> À : Christian Huitema <[email-masked]>; [email-masked]
> Objet : Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues
> 

[Med] Fully agree. The deployments I'm aware of (including ours) relies upon this model. RFC6889 insisted on this separation.

> must then implement the DNS64.

[Med] The use of an external resolver does not break things if the host supports CLAT (and issues both A and AAAA queries) or if the external resolver is ... a DNS64. Please note that current available public DNS64 use distinct IP addresses vs. "normal" public resolver IP addresses. See for example, https://developers.google.com/speed/public-dns/docs/dns64#addresses  

Note also that in networks where NAT64/DNS64 are deployed, distinct DNS configuration is usually provided to IPv6-only vs dual-stock hosts.  

> This works fine as long as the WKP is used.

[Med] Agree, but there might be some issues that are already discussed in RFC8683. It is mainly about the delay to get connected vs IPv4-only host. 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Klaus Frank <[email-masked]>
Date: Thu, 10 Feb 2022 09:45:55 +0000

On 2022-02-10 08:38, marcelo bagnulo braun wrote:
>>> reoslver, such as cloudflare. The thing is that the external 
>>> resolver must then implement the DNS64.
>>
>> How does the external resolver know when it should implement DNS64 
>> and when it shouldn't?
>>
>
Exactly, just look for yourself:

Cloudflare:
* https://developers.cloudflare.com/1.1.1.1/ipv6-networks
* https://developers.cloudflare.com/1.1.1.1/setup-1.1.1.1/linux

Google:
* https://developers.google.com/speed/public-dns/docs/dns64
* https://developers.google.com/speed/public-dns/docs/using

> cusotmers connecting through IPv6 and obtain replies that return only 
> A RR, but this sounds like a bad idea to me....
>
>

---

From: Keith Moore <[email-masked]>
Date: Thu, 10 Feb 2022 09:07:48 -0500

> resolver instances implement DNS64 and which do not and the clients 
That sounds like a disaster, because the information about which 
resolver instances implement which hacks, inevitably gets separated from 
the resolver interface info.
> A RR, but this sounds like a bad idea to me.... 

It sounds like a Bad Idea to me also.

(How long until we realize that trying to make DNS reflect a NATted 
world - trying to make DNS servers tell lies that are consistent with 
the lies that NATs tell - is inherently a Bad Idea?)

Keith

---

From: Christian Huitema <[email-masked]>
Date: Thu, 10 Feb 2022 07:35:48 -0800

> A RR, but this sounds like a bad idea to me....

I agree that having the cloud server try to guess whether the client 
needs DNS64 or not is a recipe for trouble. This means the client will 
have to connect to something like "dns64.example.net" instead of the 
regular "dns.example.net". But then, that requires the client to 
actively change the DNS resolver parameters because it "knows" that it 
is behind a DNS64 gateway. And when we say client here, it may be some 
application, not just the DNS resolver in the operating system. Compared 
to that, changing the SPF code is rather simple: if the SPF code 
complain that the source IP is not in the authorized MTA address list, 
check whether the offending address starts with WKP, and if yes check 
whether the IPv4 address embedded behind the WKP prefix is in the 
authorized list.

-- Christian Huitema

---

From: Klaus Frank <[email-masked]>
Date: Thu, 10 Feb 2022 16:41:44 +0000

On 2022-02-10 16:35, Christian Huitema wrote:
> application, not just the DNS resolver in the operating system. 
> Compared to that, changing the SPF code is rather simple: if the SPF 
> code complain that the source IP is not in the authorized MTA address 
> list, check whether the offending address starts with WKP, and if yes 
> check whether the IPv4 address embedded behind the WKP prefix is in 
> the authorized list.
And how would you push that change down the line via e.g. DHCP, mDNS or 
similar? That's what you can do with DNS64 servers but not with "NAT64 
wareness in code"