HN Explorer

14 comments

[ 3.0 ms ] story [ 43.2 ms ] thread
m_sahaf
I've been running a local DNS to DNS-over-TLS proxy on my machine for quite awhile using CoreDNS. The entire Corefile is:

  # Capture plain DNS requests and proxy them to DNS-over-TLS

  .:53 {
      forward . 127.0.0.1:5301 127.0.0.1:5302 127.0.0.1:5303 [::1]:5301 [::1]:5302 [::1]:5303
      log . {
          class error
      }
      cache
  }

  # Quad9 DNS. Differentiator: Automatically blocks domains known to be associated with malicious activity

  .:5301 {
      forward . tls://9.9.9.9 {
          tls_servername dns.quad9.net
      }
      cache
  }

  # Cloudflare. Differentiator: Fast and uses EDNS Padding

  .:5302 {
      forward . tls://1.1.1.1 tls://1.0.0.1 {
          tls_servername tls.cloudflare-dns.com
      }
      cache
  }

  # Google. Differentiator: ... Google?

  .:5303 {
      forward . tls://8.8.8.8 tls://8.8.4.4 {
          tls_servername dns.google
      }
      cache
  }
It's really easy to throw on more resolvers as they come. The last one for Google was just added today.
_nhynes_
Here's the stubby config if anyone is interested:

  # Google
  - address_data: 8.8.8.8
    tls_auth_name: "dns.google"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: nxmRHK4Oq08HNWWYZwakeCHmiKvsDsEaBPS3blQ+nSE=
  - address_data: 8.8.4.4
    tls_auth_name: "dns.google"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: nxmRHK4Oq08HNWWYZwakeCHmiKvsDsEaBPS3blQ+nSE=
where the pinset is generated using

  openssl s_client -connect '8.8.8.8:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
source: https://blog.because-security.com/t/use-cloudflare-dns-with-...
FrederickZh
Got no idea why but it seems actually two different certificates are used? Base64 digest of the other one is

  A8J84S7EER8rZJ/IQ6MsYW7heNY939jWL7IpOLrj+VM=
And I wonder whether we should actually add the digests into stubby configs? One of the certificates expires in February and other one expires in March. Does it mean that we have to update the configs then?
crsv
What are the implications of this for those of us unfamiliar with DNS feature space?
badrabbit
Your DNS queries are encrypted using TLS. For optimum privacy,use this with eSNI(encrypted server name indicator for TLS).

Cloudlfare's 1.1.1.1 supports it as well which I highly recommend over Google.

bewo001
This is a DNS provided by Google, a company that earns money by analysing user data. If you want privacy, run your own DNS.
londons_explore
Google has specifically stated that logs from Google DNS are not retained long term, and will never be correlated from logs from other Google services.

I trust those claims.

badrabbit
Why do you trust those claims? And why can't they change their mind?
londons_explore
I trust the claims because Googles business depends so heavily on PR. If Google leaks everyone's browsing history, they as a company will cease to exist.

Notice how there are lots of people claiming 'Google collects XYZ info', but no claims of 'Google zipped up XYZ info and sold it'. Every article about Google selling user data is in reality Google using the user data for it's advertising business, but explicitly not letting the partners see the data - as well as being legally protected private data, that data is also a competitive advantage they would lose if they handed it over.

Less public facing companies on the other hand I don't trust, because they don't have much to loose on the PR front. That miscellaneous credit card processor? Yeah - they'll probably be handing your data over to every credit check/profiling agency.

[dead] Proven
So in other words

1) Google can still be subpoenaed to share your logs with the government

2) The user's queries are hidden from those who can't analyze them effectively and still open to those who analyze them better than anyone

Cloudflare and 1.1.1.1 are much more sensible choices for the provider of this service

aorth
It wasn't obvious to me immediately, but the hostname of Google's DNS-over-TLS servers is: dns.google

This is important for validating the TLS certificate that is provided by their servers on 8.8.8.8 and 8.8.4.4 (equivalent to requiring a matching hostname for TLS certificates in web browsers). I see that other commenters in this thread have correctly used this hostname in their examples for CoreDNS and Stubby.

Part of a configuration for the Unbound DNS server would look like:

  forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 8.8.8.8@853#dns.google
    forward-addr: 8.8.4.4@853#dns.google
See the configuration guide for using DNS-over-TLS on unbound on the DNS Privacy site: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Clients#D...
pedrocx486
Anyone has a good guide on setting up DNS-Over-TLS on Windows? I've only did something similar before on Debian and seems I'm quite dumb when it comes to doing this on Windows.