On 11/6/19 7:11 AM, Tomasz Torcz wrote:
On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel wrote:
Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
I don't agree with centralisation. You should run your own DoH
endpoint,
using Google's, Cloudflare's or Quad9's servers is a shortcut.
DoH has zero integration and manageability. “It’s not centralized” (but
you have to set manually DoH settings in all apps *or* rely on a
centralized Google DoH whitelist) is an utter joke.
Setting in all apps? Excuse me? You run your stub DoH resolver
on ::1 and put ::1 in resolv.conf. Done, you've got DoH set
system-wide, which I believe this thread is about.
And you run resolving endpoint on your trusted server, or on some
micro-vm in Azure or somewhere else, or even on Fedora's Communishift.
Google does not even enter the picture.
(cutting the rest as it's irrelevant)
I agree with one sidenote. It is not required to use DoH for that, DoT
is enough already. And it cannot contain privacy leaking headers,
because there are just none in the protocol.
I think dnssec-trigger might be and example. It checks dnssec in current
resolvers obtained by DHCP. If it does not support it, it uses its own.
If they are blocked, it uses proxy. Does not know anything about
encryption, but it might work if tuned a bit.
Problem is, it has already terrible design. It should be driven by
network manager or something similar. Anyway, I think any encryption
belongs to the system, not applications. But first, we need some
system-wide tool prepared for that. Besides dnssec-trigger, there is
getdns-stubby package. It does not allow simple use of DHCP specified
resolvers, but it is the best solution for encrypted DNS at the moment.
Regards,
Petr
--
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
