On Mon, Nov 16, 2020 at 07:45:54AM -0500, Stephen John Smoogen wrote: > On Sun, 15 Nov 2020 at 19:26, Chris Adams <linux@xxxxxxxxxxx> wrote: > > > Once upon a time, Stephen John Smoogen <smooge@xxxxxxxxx> said: > > > Because a lot of networks use routing tricks to send traffic to > > particular > > > DNS server IP addresses. They may round robin, traffic route, or other > > > methods to send you to different DNS servers with the same ip address. > > Even > > > if they are all the same 'model' device, they have different features > > > turned on or are at different revisions.. so whatever you have cached is > > > wrong. > > > > I'm pretty sure that's considered "their problem"... anycast servers are > > expected to behave the same (or similar enough) in terms of features > > supported. Real DNS recursive servers like Unbound and BIND keep info > > about particular servers by IP. > > > > However, using info that's being tracked as a reason to not to use > > multiple servers is a rather weak argument... keeping track of info for > > additional servers should not be difficult. Currently resolved switches servers when it doesn't "like" the current server (timeout, or not working as expected, etc). I think it'd be fairly easy to implement a mode where the switch also happens on the basis of time or the number of packets handled. In that mode, it should remember what capabilities the given server had and just seamlessly restart later on. OTOH, with two or three servers, the "privacy gains" are so tiny. It's completely routine to resolve the same names over and over, so each server has a large chance of capturing enough queries of interest. And also often even one query is enough to determine a lot about what the user is doing. Overall, I think that the caching that is currently happening with resolved does more for privacy, just by reducing the number of requests, than the server rotation without cache. So... I expect that this will be implemented, if somebody provides a patch or if enough people express interest. I expect upstream to treat it as low priority though. (FWIW, a patch to do randomization of results delivered to applications, even if the same cached upstream answer is being reused, has been recently merged. This promotes random selection of a specific address on the application side when a name resolves to more than one. The justification was that it's simple to implement, and even if the effect is weak, it *may* be useful in some scenarios.) > Good point. However at what point to improving these features becomes where > systemd "bloat. Systemd came up with an "ok" low level solution and then > people keep nitpicking that it could do a better job and track more > things.. and eventually you have systemd rewritten in eLISP and a native > emacs mode. [Change to more appropriate languages for the 21st century.. > rewritten in javascript and a native Node-VSCode mode.] So far we have resisted the urge do to plugins and extensions. Let's say that elips or js support is unlikely ;] Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
