« Previous 1 2 3
Solving the security problems of encrypted DNS
Double-Edged Sword
Conclusions
The question is, what is likely to be more meaningful for the users' privacy. The employer or provider being able to see the DNS queries, or one of the large Internet corporations seeing and most likely evaluating them? Should the DNS service be concentrated on a few large companies? How do you deal with internal DNS servers?
The combination of DoH, DoT, and DNSCrypt with ESNI and TLS 1.3 will change the use of the Internet. With these protocol combinations, Internet providers or organizations will no longer be able to block websites because the required information is no longer available. Considerable technical challenges still remain to be solved.
I recommend the following for universities and research institutions:
- Block port 53/UDP+TCP for all computers except DNS servers. This action should have been implemented a long time ago to prevent the use of external DNS servers.
- Block port 853/TCP to prevent DoT.
- Respond to requests for the canary domain use-application-dns.net [17] with NXDOMAIN .
- Use group policies to prevent DoH being enabled on managed machines.
- Set the value of
BuiltInDnsClientEnabled
toFalse
in Chrome or Edge on all managed computers.
Some privacy measures that are useful for users at home and on public networks can be counterproductive for universities, colleges, research institutions, public authorities, and businesses. Especially on guest networks, malware needs to be contained, because the IP addresses used there belong to the institution. Blocking command and control systems or servers from which malicious software retroactively installs functions is a standard security measure and one often implemented by manipulating DNS.
The use of DoH at universities and in research institutions would be acceptable if the browser were to use it automatically with the DNS server(s) configured in the operating system. However, the group policies restrictions only apply to managed systems in the institution, not to BYOD devices.
Infos
- DNSSEC: https://www.DNSSEC.net
- DNSViz: https://dnsviz.net
- Pi-hole: https://pi-hole.net
- DNSCrypt: https://dnscrypt.info
- RFC 7858: https://tools.ietf.org/html/rfc7858
- GL-iNet: https://blog.gl-inet.com/dns-over-tls-built-in-enforced-1.1.1.1-and-the-gl.inet-gl-ar750s/
- RFC 8484: https://tools.ietf.org/html/rfc8484
- DNSCurve: http://www.dnscurve.org
- DoH in Chrome: https://judge.sh/how-to-enable-dns-over-https-on-chrome-right-now
- DoH: https://www.chromium.org/developers/dns-over-https
- Chrome DoH test: https://www.ghacks.net/2019/09/11/google-plans-to-test-dns-over-https-in-chrome-78/
- Chrome policy management: https://support.google.com/chrome/a/answer/9037717
- Disabling DoH: https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
- How encrypted SNI works: https://blog.cloudflare.com/encrypted-sni
- RPZ zone files to block DNS over HTTPS: https://github.com/bambenek/block-doh
- ETS isn't TLS: https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-use-it
- Canary domain: https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet?&mobile=1
« Previous 1 2 3
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
Support Our Work
ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.