Am 05.11.19 um 14:21 schrieb Florian Weimer: > >> ahm.. in which way, does the use of encryption, make a sourcelist for >> dns names to ask, obsolete? > Names or servers? "names of domainnameservers" >> nscd i.e. uses resolv.conf as source for the round robin server list. > With encryption, the server address will always be 127.0.0.1 (or > potentially in the future, a UNIX domain socket) because pretty much all > the current DNS client software does not support encryption. Running a > small local cache has other benefits as well, such as caching server > reachability information. > running a local DNS-Cache does not make so much sense as you may think. besides the obvious reasons like short daytime usage with poweroff at the end, you will run into the same kind of problems, the windows local dnscache had: It's even harder to debug customers problems, as more caches are involved. Countless days i had to let users flush their local dns cache, to ensure they don't connect to something outdated. DNS is so vital to all services, that you want to have something easy to maintain and debug, unlike NetworkManager, which enslaves all users to the default dns names, that came via dhcp. Last time i checked, it does not support round robin to increase privacy. NSCD does, and if NM lets it, it's working good. (had it running) If someone wants to improve privacy, some rules apply: a) you don't ask the same server for all your questions ( Round Robin with thousands of dnscaches world wide) b) you build a chain of trust ( DNSSEC ) c) the entire chain encrypts the traffic It would be ok, to have a local resolver handle this for all apps and it mimics an unencrypted ns on 127.0.0.1:53 . But the main problem with a+b+c is, it takes a sh*tload of overhead to a real simple thing AND as with browsers, has absolutely no value, because the browser will tell anyone between himself and the target, what he is connecting to. (see other posting). Most people won't even gain privacy protection out of it, as outbound dns is blocked except for the ISPs dns, the cable/dsl box they use will just send them two dns servers, not thousands to choose from and in the end, the browser will give them away anyway. >From my POV, which supports the DoT as it's a good idea, "why protecting something, that the last device sabotages anyway?" Ok, there are more than webpages, but most used services like mail pop imap, open one connection to a known targetport, not hard to guess what it is and where it is. BTW, those clients do 1 dns resolve per day, they won't profit from a local cache ;) And even if the browser would not give the dn away in SNI or Host: , it does not make things better, as you can simply ask the internet, which websites are hosted on a specific ip, and you get a long list of names. Tracking a users connections makes it always possible to build profiles, maybe not as precise as with dns data, but good enough. My conclusion: DoT and DoH, if not done via a browser, and not done via one single server, are acceptable and a valid goal for a change inside Fedora, but they won't help in privacy protection. What is needed to reach this special goal, takes more than Fedora or Red Hat can provide. I personally favor DoT as it would make use of the millions of dns server available on the net. DoH is too centralized to implement for now. best regards, Marius _______________________________________________ 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
