Although the RFC does require support for PTR records, I would not assume that DNS64 implementations all do this. It depends on whether the implementation was done from the RFC or not, and whether the implementer cares about this use case. I say this knowing the code of two implementations personally, one of which does PTR synthesis, one of which does not. I might fix the second one at some point, but despite the MUST in the RFC, I'm not feeling any urgency about it. :]
On Tue, Feb 15, 2022 at 3:06 AM Klaus Frank <klaus.fr...@posteo.de> wrote: > On 2022-02-15 03:03, Mark Andrews wrote: > >> On 15 Feb 2022, at 10:47, Mark Andrews <ma...@isc.org> wrote: > >>> 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. > You're making a good point here. When writing this I-D I had the (maybe > incorrect) assumption that when the sender is dual-stack that it will > never send via its IPv4 address towards another dual-stack MTA but would > always use its IPv6. I'll have to look into that. > > If you want to continue to use DNS64 then you need the MTA or the SPF > library to reverse the NAT64 encoding. > If the above actually applies I'll replace the I-D with one that does > this within the SPF validator as then it would indeed be the better > solution. Do you by change know what WG would be best for that? It isn't > DNSOP is it? > > If you want to use a MTA and SPF library that is not DNS64 aware you > will need to some sort of encapsulation > > (DS-Lite, MAP-E, or any other 4in6 mechanism) or perform reverse > translation (464XLAT, MAP-t) to present IPv4 > > connection to the MTA. > > DNS64 was designed for IPv6 clients to connect to IPv4 servers iff there > where not AAAA records present for > > the name. It was NOT designed to handle address literals. It is the > wrong tool for this purpose. Since you > > will need to setup specific forwarding for inbound connections to work > you shouldn’t be limited to just NAT64 > > inbound. > > I kinda disagree on that, as otherwise DNS64 also wouldn't handle > PTR-RRs. So at least at some level such a usage was also considered. > Also just a note, no specific forwarding (do you mean non standardized > with that?) is needed. Just a stateless NAT46 (from public IPv4 to IPv6) > rule is needed that assigns a Public IPv4 to the IPv6 of the MTA. And on > the outbound connections NAT64 will then utilize stateless transitions > for that specific source IP and everything that doesn't have a stateless > transition assigned will go through a statefull NAT64. The IPv4 > addresses in this case would be provided by an IPv4aaS provider and not > the cloud provider itself. This way the cloud provider network would be > IPv6-only and IPv4 would be available where needed. > > > Mark > > > >>> 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 > _______________________________________________ > 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
