Moin, > SHOULD is a cop out. Given that this is already an implemented feature in Unbound, I'd argue that a <bcp14>MUST NOT</bcp14> might not be ideal here.
> What we are designing SHOULD work everywhere WITHOUT > manual intervention. I would have to manually intervene a lot more by setting up CLATD on my DNS recursor instead of just dropping two lines of configuration into the config. > Translating IP addresses in a DNS server is unnecessary work. I would argue that "Get A, move bits, open v6 socket, make query" is a lot less work than "Get A, open v4 socket, kernel takes packet does CLAT, IPv6 packet goes out, send query", especially given the state of CLAT on servers, and especially-especially given that CLAT regularly involves more state on host OSes due to the 'magic' needed to redirect packets to the CLAT. > 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. I'd say that this is a bit far fetched. Also, on Linux, CLAT is usually userspace; So you would already have to have exceptions w.r.t. what should or should not be going through CLAT and what not. > > 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. But that was essentially you use-case? Or did I miss sth. there? With best regards, Tobias -- 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]
