Hi Marius,
I maintain BIND and some similar stuff. More or less, there is already
implementation quite similar to what you have described. Already in
Fedora: stubby [1]. It has central list of several resolvers and uses
them in round-robin fashion. Does not make specific order.
However, the most close solution to what is required in coordination
with DHCP is IMO dnssec-trigger. It has very complicated design
unfortunately.
Regards,
Petr
1. https://github.com/getdnsapi/stubby
On 11/5/19 3:07 PM, Marius Schwarz wrote:
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
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik@xxxxxxxxxx PGP: 65C6C973
_______________________________________________
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
