Mark, I'm not sure we're communicating. It sounds like you're saying that NAT64 modifies the payload in transit? I don't think that's the case. If it doesn't, then a full service resolver will be able to validate the responses it gets. It can then translate them. Since it is the consumer of the translated data, by definition the translated data can be treated valid, unless it somehow doesn't trust itself.
If your concern is that a NAT64 translator upstream of that full-service resolver would translate answers, I'm not sure how that would happen. Are you saying that some upstream full-service resolver would do translation even in the presence of a request for validated responses? Why is this full-service resolver talking to a cache and not the authoritative server? Why is this cache broken? On Thu, Jul 6, 2023 at 12:48 AM Mark Andrews <[email protected]> wrote: > > > > On 6 Jul 2023, at 12:32, Ted Lemon <[email protected]> wrote: > > > > It’s not a problem to validate before translating if you’re a full > service resolver. > > Ted you are missing the point. It is impossible to *reliably* run a > validating client > behind a DNS64 server. DNS64 uses CD in a manner that is *incompatible* > with DNSSEC. > Sure as long as the DNS64 server *always* gets good answers you can “get > away with it” > but once you don’t things break. > > In DNSSEC > CD=1 is for when the recursive validating resolver has bad time / trust > anchors > CD=0 is ensures the cache returns answers that can validate as secure (the > server is > supposed to try multiple sources as it is required to “treat as never > having arrived” > responses that don’t validate) > > “Always send CD=1” is stupid advice. I tried to prevent it being > published in the > first place. > > If the DNS64 server happens to lock onto a bad source of data or is losing > the race > with spoofed responses the client will never get anything that validates > as secure as: > CD=1 the bad data is passed through or returned from the cache. > CD=0 the DNS64 server produces responses that don’t validate. > > Anything that further promotes the use of a BROKEN protocol should not be > published. > > Mark > > > Op wo 5 jul 2023 om 21:10 schreef Mark Andrews <[email protected]> > > I’ll repeat that it is a bad idea to make this an RFC. I’m saying this > despite adding > > this to named. > > > > It is perpetuating DNS64 which does not work with DNSSEC. It sends the > wrong signal > > that DNS64 is a good protocol to deploy when we know that it breaks lots > of things. > > > > The better solution would be to improve the automatic installation of > 464XLAT (RFC6877) > > support in nodes. There is already a RA PREF64 option (RFC8781) to > signal that NAT64 is > > available on the network and that works for all applications on the > node, not just the > > nameserver. > > > > Similarly for DS-Lite. > > > > Linux has https://github.com/toreanderson/clatd > > FreeBSD has 464XLAT support built in since FreeBSD 11.3 > > > > While CLAT is not everywhere there yet it is definitely on the way. > > https://blog.apnic.net/2022/11/21/deploying-ipv6-mostly-access-networks/ > > > > I really don’t know why we are just not saying if you want to run a > DNS64 server behind > > a IPv6 only link install CLAT support if it is not already available. > > > > > > > On 6 Jul 2023, at 01:12, Tim Wicinski <[email protected]> wrote: > > > > > > Momoka > > > > > > Thanks for making DNSOP aware of this. We encourage anyone with > comments on the document adoption to reach out. > > > > > > Everything I've heard and read on this work (wearing no hats) is that > this is good work and should be adopted. > > > > > > thanks > > > tim > > > > > > > > > > > > On Tue, Jul 4, 2023 at 5:15 AM Momoka Yamamoto <[email protected]> > wrote: > > > Dear dnsop wg > > > cc:v6ops wg > > > > > > My name is Momoka, the author of the > draft-momoka-v6ops-ipv6-only-resolver. This draft, which has already been > introduced to the V6OPS Working Group, aims to address a pertinent > operational issue: facilitating the transport of query packets from an > IPv6-only iterative resolver to an IPv4-only authoritative DNS server. > > > > > > In light of some suggestions in V6OPS and considering the overlapping > interests, I am introducing this draft to the DNSOP Working Group. Its core > proposition lies in the mechanics of transporting query packets rather than > the alteration of the DNS protocol behavior, but the operational context > undoubtedly makes this draft relevant to both groups. > > > > > > Here are links to the draft and the ongoing discussions in V6OPS: > > > > > > 1. Draft: > https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/ > > > 2. V6OPS Thread: > https://mailarchive.ietf.org/arch/msg/v6ops/uNrPNbeUtA_D0xzqLfq5dNQ85OY/ > > > > > > > > > Currently, there is an adoption call in V6OPS for this draft set to > end on July 10, 2023. Your opinion, input, and suggestions will be highly > valued as we explore and progress this topic. I look forward to fruitful > and enlightening discussions. > > > > > > Best regards, > > > > > > Momoka Yamamoto > > > [email protected] > > > _______________________________________________ > > > DNSOP mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > > > v6ops mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: [email protected] > > > > _______________________________________________ > > v6ops mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/v6ops > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
