Moin, reading the discussion, i seriously believe that this is a viable compromise and the closest we may ever get to consensus on this point.
Generally, I also follow your argument. If anyone has strong opinions to the contrary, please speak up (and ideally attach text or send PRs ;-))! With best regards, Tobias On Thu, 2025-08-14 at 08:21 -0700, Tommy Jensen wrote: > > On 8/13/25 14:36, Philipp S. Tiesel wrote: > > > > Hi, > > > > > > > > > > > > On 13. Aug 2025, at 00:25, Mark Andrews <[email protected]> wrote: > > > > > > > > > > > > > On 11 Aug 2025, at 20:06, Tobias Fiebig <[email protected]> > > > > wrote: > > > > > > > > Moin, > > > > > > > > On Mon, 2025-08-11 at 19:55 +1000, Mark Andrews wrote: > > > > > > > > > Which only “works” with trivial configurations. > > > > > > > > > > What happens if 2.0.0/24 is reachable out interface A and > > > > > interface B > > > > > is IPv6 only with a PREF64? > > > > > > > > > > > > > Then I'd say that it is covered by the point being made > > > > <bcp14>SHOULD</bcp14> and not <bcp14>MUST</bcp14>. > > > > > > > > > > SHOULD is a cop out. What we are designing SHOULD work > > > everywhere WITHOUT > > > manual intervention. > > > > > > > > > > > > > > I agree SHOULD (making this behavior the default unless some > exception applies) is inappropriate. I think the presented arguments > justify making this an option for resolvers who are aware of their > XLAT situation, but it should be a MAY meaning the default is to > trust the OS stack. > > > > > > > > > > > > > > Translating IP addresses in a DNS server is unnecessary work. It > > > is also > > > a security flaw as you are potentially redirecting DNS queries > > > to places > > > other than where they are intended to go according to the > > > routing table. > > > > > > > > > > > > > > If there are no IPv4 routes, there are no security issues. If > > there are (but no default route) > > > > maybe disabling address synthesis and setting up CLAT is easier, > > but for wich use-cases? > > > > - Recursors on Laptops with split-VPN? > > > > - My chaotic VyOS VPN router at home? > > > > > > This assumes the admin of the DNS resolver is always the same as the > admin of the system. I suggest this isn't true and telling the RFC > readers that the default behavior is to handle address synthesis > instead of trusting their available OS stack seems a heavy ask unless > they want to take that responsibility on (which I agree many will or > even should for perf reasons presented). > > > > > > > > > > > > > > > > > > The ways to configure one's own network are endless. What if > > > > there are > > > > two interfaces each with their own PREF64? What if the second > > > > Interface > > > > only offers reachability for RFC1918? What if the operator has > > > > been > > > > squatting non-RFC1918 space and the 2.0.0.0/24 reachable via > > > > Interface > > > > B is _not_ the one they want to use for DNS resolution? > > > > > > > > > > All the more reason to NOT do this. It’s not something that can > > > be done > > > safely. > > > > > > > > > > > > > > > > It is perfectly safe if you have no IPv4 connectivity and much less > > error-prone than integrating CLAT. > > > > The only drawback of doing address synthesis instead of CLAT is > > that DNS server vendors get additional bug reports for broken > > network setups that should not have enabled address synthesis in > > the first place. > > > > > > > > Again, this assumes the resolver admin has the option of configuring > the OS stack. If they do, they MAY optimize this way, but requiring > them to seems like a leap. > > > > > > > > > > > > > > > > > > I think that all of that is sufficiently covered by > > > > <bcp14>SHOULD</bcp14>. > > > > > > > > However, to make this more clear, we could add text along the > > > > lines of: > > > > > > > > "Specific operational scenarios may differ. As such, it is > > > > <bcp14>RECOMMENDED</bcp14> that implementations offer > > > > configuration > > > > options that allow an operator fine-grained control of > > > > prefixes to > > > > exclude from PREF64 based address synthesis." > > > > > > > > The general point, though, was brought forward to me by > > > > multiple > > > > operators, who are struggling with the current situation, and > > > > would > > > > appreciate the currently sketched solution. > > > > > > > > > > > > > > > > > > Agreed! It should be documented here, just optional and not the > default. > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] Pronouns: he/him/his _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
