> On 15 Feb 2022, at 06:50, Klaus Frank <klaus.fr...@posteo.de> wrote: > > Hi, > > yes there was discussion on the mailing list already. It wasn't however that > clear on what side should implement it. Also DNS64 already does the IP > rewrite. Therefore it's just reasonable and logical that it should be the > part that has to consider other RFCs that put IP addresses into other DNS > records... > > Also the size limit isn't an issue. As that size is just a recommendation and > it includes *ALL* TXT records together. Therefore e.g. google.com already > exceeds it. And the same behavior would be necessary here. So nothing special > needed here. e.g. the DNS64 resolver sets the Truncated Message bit in it's > response and the client is retrying the query via TCP and gets it's answer > that way. > > Also as people pointed out. SPF is a clearly formulated standard that could > easily be found within the data of the TXT record. It's not about guessing. > It's a clear search and replace/insert. No guessing involved. > > And to the 15 years argument. SPF hasn't been widely used the whole time. It > wasn't really necessary before 2016. It just increased in recent years by > demand of some big players. Also the IPv6 adoption was never as high as it's > currently (in 2016 it was below 15% globally according to statistics from > google). And therefore the reliance on this and this kind of issue will only > increase and not decrease until IPv4 is completely gone. It'd be also better > to allow people to go single stack IPv6 then forcing them to stay dual stack > which would just lead to people pushing out the adoption of IPv6 as they'd > still have to care about IPv4 and IPv4 related issues anyway. > > I think this I-D is an important step towards allowing people to go IPv6-only > and not needing to dual stack their hosts. And regarding just updating the > SPF resolver itself, it would be very messy to demand the SPF resolver to do > it. Also as DNS64 already leads to the assumptions that it "fixes DNS to act > as if everything is IPv6 capable" it's just reasonable to also have it update > the SPF records within DNS and maybe even allow other rewrites of the same > kind. Currently there is a "MUST NOT rewrite any other records" within that > RFC that prevents such solutions. One may hate DNS64 for injecting IPv6 > addresses into the answers to the queries but it's clear that it should be > the component that gets updated to accommodate other standard track RFCs for > compatibility. As it's the one that aims to fix these kinds of issues already. > > I really want you to consider the implications of putting the burden onto the > SPF implementation here. Esp. the kind of confusion it'll cause when admins > try to debug such a setup later and don't see the rewritten IPs within the > SPF records. It's a reasonable assumption for that to get rewritten as well. > Please seriously consider this. And if you after that still prefer that the > SPF record shouldn't be updated to align with that assumption I'm open to > replace this I-D with another one that updates the SPF RFC to include the > lookup of the NAT64 prefix. But until now I just have the feeling that some > people are just against DNS64 itself and therefore try to avoid the > discussion.
You literally can’t achieve what you want to in the resolver. The a: and mx: mechansims will not work for IPv4 connections from dual stack clients as the DNS64 synthesis of AAAA records does not trigger if there are AAAA records present. The SPF libraries will see connections from AAAA address that are not matched by the records AAAA records returned by the resolver. The whole concept is dead in the water from what I can see. > On 2022-02-14 19:30, John Levine wrote: >> It appears that Klaus Frank <klaus.fr...@posteo.de> said: >>> I wrote an I-D for updating DNS64 to better work for MTA operators. ... >> I strongly oppose this ill-considered proposal. For one thing, it is very >> rare for people to try to run mail servers behind DNS64. SPF is fifteen >> years old, and this is the first time anyone has brought up this issue. >> >> For another, trying to guess which TXT records are SPF records and >> rewriting them on the fly is unreliable and dangerous. The rewritten >> record would always be larger than the original. If the rewritten >> string exceeds the size limit of a text string or txt record, then >> what? >> >> But most importantly, there is a simple and reliable way to deal with >> this issue. When an SPF library recognizes a NAT64 address, which it >> can easily do with the method in RFC 8880, it turns the address back >> into the equivalent IPv4 address and uses that in the SPF validation. >> This will always produce the correct result, and needs no change to >> existing standards. Having worked on a few SPF libraries, I can say >> these changes would not be hard for anyone with a modest familiarity >> with the code. >> >> We've explained this several times already, dunno why we have to do so again. >> >> R's, >> John >> >> >> >>> Name: draft-frank-dns64-spf-extension >>> Revision: 03 >>> Title: An Extension to DNS64 for Sender Policy Framework SPF >>> Awareness >>> Document date: 2022-02-14 >>> Group: Individual Submission >>> Pages: 6 >>> URL: https://www.ietf.org/archive/id/draft-frank-dns64-spf-extension-03.txt >>> Status: https://datatracker.ietf.org/doc/draft-frank-dns64-spf-extension/ >>> Html: >>> https://www.ietf.org/archive/id/draft-frank-dns64-spf-extension-03.html >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-frank-dns64-spf-extension >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-frank-dns64-spf-extension-03 >>> >>> Abstract: >>> This document describes interoperability issues and resolutions >>> between DNS64 and SPF records for mail transfer agents. This >>> document also aims to simplify the IPv6 migration for mail transfer >>> agent operators. >>> >>> This document updates [RFC6147] and [RFC7208]. >>> >>> >>> -=-=-=-=-=- >>> [Attachment type=application/pkcs7-signature, name=smime.p7s] >>> -=-=-=-=-=- >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
