This article provides a guide for installing a local DNS resolver that enforces DNS-over-TLS to a randomly selected publicly available upstream server. The setup described respects DNS response consistency by enforcing DNSSEC if it is supported by the DNS zone, encrypts DNS traffic, and uses DNS servers from different providers. The second section of this article addresses the question of privacy.

Guide to installing DNS-over-TLS on Local DNS Resolver

The local DNS resolver described here is implemented within the caching DNS resolver Knot Resolver. To use it, a prepared list of publicly available DNS servers that support DNS-over-TLS is required.1 We use anycast DNS servers to reduce network latency in our setup. We do not use IPv6 because this protocol is not widely delivered. When it is not available or poorly configured, the resolution will fail.

The initial version of this article contained a λ-function that was used for queries that were not found in the cache. The current version of Knot-Resolver2 has a policy.slice that is used in the same manner.

-- DNS-over-TLS to Random Upstream
modules = { 'policy' }

policy.add(policy.slice(
    policy.slice_randomize_psl(os.time()),
    -- FlokiNET
    policy.TLS_FORWARD({
        {'37.156.68.20', hostname='resolv.flokinet.net'}
    }),
    -- Freifunk München e.V.
    policy.TLS_FORWARD({
        {'5.1.66.255', hostname='dot.ffmuc.net'}
    }),
    -- Cloudflare
    policy.TLS_FORWARD({
        {'1.1.1.1', hostname='one.one.one.one'},
        {'1.0.0.1', hostname='one.one.one.one'}
    }),
    -- dns.sb
    policy.TLS_FORWARD({
        {'185.222.222.222', hostname='dns.sb'},
        {'185.184.222.222', hostname='dns.sb'}
    }),
    -- UncensoredDNS
    policy.TLS_FORWARD({
        {'91.239.100.100', hostname='anycast.uncensoreddns.org'}
    })
))

Enabling the described scenario is possible by adding the above code to Knot Resolver’s kresd.conf.

Privacy Concerns

The design of DNS requests which uses centralized or public DNS server instead of provider’s one which is closed to the end user was widley critized a special in the case when the applicaion such of browser makes DNS-over-HTTPS request instead of the system:

Have we now provided the private surveillance framework with a whole new trove of personal data to mine by ruthlessly exploiting the DNS in a manner that is entirely out of sight? Once the browsers and even the apps direct their name queries through encrypted channels to resolvers operated by the same browser and app providers, then have we dealt a body blow to any efforts to safeguard personal privacy on the Internet?

  • Geoff Huston.3

But if we sum it up, pre-DoH, the following parties have access to the names of most of the sites you visit:

  1. Your own network provider
  2. Your own government, police, intelligence services (through court orders)
  3. Anyone capable of snooping your local network
  4. Certificate authority providers (through OCSP)
  5. Large scale tracking & advertising companies (Google, Facebook)

DNS over HTTPS in browsers is currently exclusively offered by/through American companies. So after switching to DoH, we have to add the following to our list:

  1. Cloudflare / your DoH provider
  2. The US Government, NSA, FBI etc.
  • Bert Hubert.4

The technique used in the described scenario enables the shift of surveillance from the local provider to a public server that has knowledge of both the IP address sending the request and the request itself. Queries are distributed with a continuous uniform distribution that depends on the used PRNG. This scenario makes the sharing of metadata leaks among manually selected operators of DNS-over-TLS servers with uniform distribution by using a random number generator.

To improve this scenario, one could use the Tor network to access public DNS. However, it should be noted that the majority of tested public servers ban Tor’s exit nodes. Instead, some providers have introduced DNS-over-Tor, where their DNS server is available via .onion address.5


  1. It is important to note that some public DNS-over-TLS providers may apply rate-limiting, which can make their service incompatible with our scenario. For example, Google Public DNS, January 2024. ↩︎

  2. The function policy.slice was introduced in version 4.2.0, August 2019 ↩︎

  3. The above quote is from the blod post More DOH where he summarized question of the post DNS Privacy at IETF 104, April 2019 ↩︎

  4. Centralised DoH is bad for Privacy, in 2019 and beyond, October 2019 ↩︎

  5. A notable example of such a service is the Cloudflare hidden resolver, June 2018 ↩︎