> 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. 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. > 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. > 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. > > With best regards, > Tobias > -- > Dr.-Ing. Tobias Fiebig > T +31 616 80 98 99 > M [email protected] > Pronouns: he/him/his -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
