This page lists open DNS resolvers that respect your privacy.

You can also find documentation on how to run your own DNS resolver, and even how to run an open DNS resolver. Be warned: providing an open DNS resolver is not something you can improvise!

You can freely use the following open DNS resolvers. It's probably a good idea to use one in your country, or in a nearby country.

Some of them have a DNSSEC validation, but be careful; the DNS is not transported over TLS, so the content can be modified between the resolver and your computer even if the DNSSEC validation is working.

You can also install a DNS resolver directly on your own computer, see below.

Please only add open DNS resolvers that respect the privacy of their users (so, no 8.8.8.8 please).

Instead of using somebody else's resolver, why not setup your own resolver, on your own computer? It's actually super easy.

The advantage is that you don't depend on any resolver, that could be shutdown or hijacked. Besides, your resolver can perform DNSSEC validation locally, solving the last-mile trust issue. The only disadvantage: a bit of latency the first time you resolve a name.

On Linux, just install unbound from your distribution packages. Then set your resolver to 127.0.0.1.

That's it, you are now using your own local DNS resolver!

Note: on many distributions, the default configuration for unbound only allows queries from localhost, which is exactly what we want here. If you want to provide DNS resolution to other computers, you'd have to configure some access control.

If you want to operate an open DNS resolver, then you need to be aware of DNS-based reflection attacks. That is, never provide an open DNS resolver without rate-limiting.

If you know what you are doing, here is a the bit of configuration for unbound to become an open DNS resolver:

server:
    # Open DNS resolver
    # NOTE: only do that if you setup a firewall-based rate limiting!
    interface: ::
    interface: 0.0.0.0
    access-control: ::/0 allow
    access-control: 0.0.0.0/0 allow

Currently, unbound does not support rate limiting. See below for a firewall-based rate-limiting approach.

If your DNS software cannot do rate limiting itself, you can do it with a firewall. A useful reference (in French) is at Stéphane Bortzmeyer's blog.

Here is the (advanced) IPv6 configuration for iptables, courtesy of LDN:

ip6tables -A FORWARD -d $IP/128 -p udp -m udp --dport 53 -j DNS-RATE-LIMIT
ip6tables -A FORWARD -d $IP/128 -p udp -m udp --dport 53 -m comment --comment "COMPTABILITE : * -> recursif" -j ACCEPT
ip6tables -A FORWARD -s $IP/128 -p udp -m udp --sport 53 -m comment --comment "COMPTABILITE : recursif -> *" -j ACCEPT
ip6tables -A DNS-RATE-LIMIT -m u32 --u32 "0x0>>0x16&0x3c@0x14&0xffffff00=0xff00" -m hashlimit --hashlimit-above 1/sec --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name RL-DNS --hashlimit-srcmask 56 -m comment --comment "RATE-LIMIT ANY ." -j DROP
ip6tables -A DNS-RATE-LIMIT -m u32 --u32 "0x0>>0x16&0x3c@0x14&0xffdfdfdf=0x3495343&&0x0>>0x16&0x3c@0x18&0xffdfdfdf=0x34f5247&&0x0>>0x16&0x3c@0x1c&0xffffff00=0xff00" -m hashlimit --hashlimit-above 1/sec --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name RL-DNS --hashlimit-srcmask 56 -m comment --comment "RATE-LIMIT ANY isc.org" -j DROP
ip6tables -A DNS-RATE-LIMIT -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name RL-DNS --hashlimit-srcmask 56 -m comment --comment "RATE-LIMIT ALL 10/s-20/s" -j DROP

Same for IPv4:

iptables -A FORWARD -d $IP/32 -p udp -m udp --dport 53 -j DNS-RATE-LIMIT
iptables -A FORWARD -d $IP/32 -p udp -m udp --dport 53 -m comment --comment "COMPTABILITE : * -> recursif" -j ACCEPT
iptables -A FORWARD -s $IP/32 -p udp -m udp --sport 53 -m comment --comment "COMPTABILITE : recursif -> *" -j ACCEPT
iptables -A DNS-RATE-LIMIT -m u32 --u32 "0x0>>0x16&0x3c@0x14&0xffffff00=0xff00" -m hashlimit --hashlimit-above 1/sec --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name RL-DNS --hashlimit-srcmask 24 -m comment --comment "RATE-LIMIT ANY ." -j DROP
iptables -A DNS-RATE-LIMIT -m u32 --u32 "0x0>>0x16&0x3c@0x14&0xffdfdfdf=0x3495343&&0x0>>0x16&0x3c@0x18&0xffdfdfdf=0x34f5247&&0x0>>0x16&0x3c@0x1c&0xffffff00=0xff00" -m hashlimit --hashlimit-above 1/sec --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name RL-DNS --hashlimit-srcmask 24 -m comment --comment "RATE-LIMIT ANY isc.org" -j DROP
iptables -A DNS-RATE-LIMIT -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name RL-DNS --hashlimit-srcmask 24 -m comment --comment "RATE-LIMIT ALL 10/s-20/s" -j DROP

All of our configuration, our tests and remarks are detailed there (in French, sorry): Comment mettre en place un serveur DNS récursif-cache ouvert dans de bonnes conditions. Here, we will only make a synthesis of the most important steps to set up an open recursive-cache DNS server without going into further details.

Enable DNSSEC validation, even if it will only profit your local users, because of the so-called last mile problem.

dnssec-enable yes;
dnssec-validation auto;
# dnssec-lookaside auto; # not really necessary anymore nowayadys

auto-trust-anchor-file: "/var/lib/unbound/root.key"

Have a valid “abuse” e-mail address associated with your IPv4 and IPv6 blocks in the RIPE database (or any other RIR). You can use this form: enter the IPv4 and IPv6 addresses of your recursive server, it must return an valid up-to-date email address.

Especially the outgoing traffic: thoughput and packets per second. At ARN, the monitoring setup emits an alert when the outgoing throughput goes beyond 250 kbps over 5 minutes. This limit represents 10 times the average traffic.

Prepare a safe configuration (recursive only answering on your IPv4 and IPv6 blocks) that you will be able to load/apply in case of emergency (large sustained attack).

#allow-query { 127.0.0.1; ::1; <your_IPv4_block>; <your_IPv6_block>; };
#allow-query-cache { 127.0.0.1; ::1; <your_IPv4_block>; <your_IPv6_block>; };
#allow-recursion { 127.0.0.1; ::1; <your_IPv4_block>; <your_IPv6_block>; };

server: 
[...]
    #access-control: 127.0.0.1/32 allow
    #access-control: ::1/128 allow
    #access-control: <your_IPv4_block> allow
    #access-control: <your_IPv6_block> allow

• There still is a doubt on whether Response Rate Limiting (RRL) on a recursive is effective or appropriate. This is why we don't use it.
• We clean up traffic on our two routers to avoid internally transporting useless unwanted traffic, but these filters can also be applied directly on the recursive. To do so, you need to replace the FORWARD with INPUT.

iptables -N  DNS-RATE-LIMIT

iptables -A FORWARD ! -s <your_IPv4_block> -d <IPv4_of_your_recursive_server> -p udp -m udp --dport 53 -j DNS-RATE-LIMIT

iptables -A DNS-RATE-LIMIT -m string --hex-string "|0000ff0001|" --algo bm --from 28 --to 65535 -m hashlimit \ --hashlimit-above 1/sec --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name RL-DNS-ANY-v4 --hashlimit-srcmask 24 -m comment --comment "RATE-LIMIT ANY QTYPE 1/s burst 2" -j DROP

iptables -A DNS-RATE-LIMIT -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name RL-DNS-GLOBL-v4 --hashlimit-srcmask 24 -m comment --comment "RATE-LIMIT ALL QUERIES 10/s burst 20" -j DROP

ip6tables -N  DNS-RATE-LIMIT

ip6tables -A FORWARD ! -s <your_IPv6_block> -d <IPv6_of_your_recursive_server> -p udp -m udp --dport 53 -j DNS-RATE-LIMIT

ip6tables -A DNS-RATE-LIMIT -m string --hex-string "|0000ff0001|" --algo bm --from 48 --to 65535 -m hashlimit --hashlimit-above 1/sec --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name RL-DNS-ANY-v6 --hashlimit-srcmask 56 -m comment --comment "RATE-LIMIT ANY QTYPE 1/s burst 2" -j DROP

ip6tables -A DNS-RATE-LIMIT -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name RL-DNS-GLOBL-v6 --hashlimit-srcmask 56 -m comment --comment "RATE-LIMIT ALL QUERIES 10/s burst 20" -j DROP

• Remember to use netfilter-persistent to apply those filters at boot time.

Reduce the maximal size of the answers your recursive will send over UDP. The idea being to ask the client to come back asking over TCP its question creating a large answer. If it was a real client, it will come back; otherwise it won't.
With BIND (/etc/named/named.conf.options under Debian GNU/Linux) or Unbound (/etc/unbound.conf under Debian):

max-udp-size 1460;