Public resolvers

Public Resolvers: Several large organisations have announce DNS Privacy Servers - see DNS Privacy Public Resolvers
  • Quad9 ( and Cloudflare ( offer DNS-over-TLS on port 853
  • DOH servers are also currently listed on that page

Experimental DNS Privacy Recursive Servers

DoH servers

These are currently listed on the DNS Privacy Public Resolvers page and also the list maintained on the curl wiki. For any servers below with the note 'also does DoH' check these pages or the website of the service for the DoH endpoint.

DoT servers

The following servers are experimental DNS-over-TLS servers.

Note that they are experimental offerings (mainly by individuals/small organisations) with no guarantees on the lifetime of the service, service level provided. The level of logging may also vary (see the individual websites where available) - the information here about logging has not been verified. Also note that the single SPKI pins published here for many of these servers are subject to change (e.g on Certificate renewal) and should be used with care!!
Oct 2020: The list below has been updated to retain only those servers that appear to still be actively maintained


A YAML configuration file for Stubby containing a the details of these servers is provided with Stubby and can be found here. This file enables only the subset of servers operated by the stubby/getdns developers by default, users can choose to enable any of the other servers by uncommenting the relevant section (occasionally the file lags this page).

Servers run by the Stubby developers

Hosted byIP addressesTLS PortsHostname for TLS
Base 64 encoded form of SPKI pin(s) for TLS
authentication (RFC7858)
TLSA record publishedLoggingSoftwareNotes
1) The following are currently enabled in the default Stubby config file because they are run by the stubby/getdns developers and have no known issues.
YTraffic volume onlyHAProxy + BIND 9.12See
YTraffic volume onlyNginx + BIND 9.12See

YTraffic volume onlyUnbound

Other servers with a 'no logging' policy

Hosted byIP addressesTLS PortsHostname for TLS
Base 64 encoded form of SPKI pin(s) for TLS
authentication (RFC7858)
TLSA record publishedLoggingSoftwareNotes
(also see this file for a full set of pins)
YTraffic volume only

Fondation RESTENA
(NREN for Luxemburg)

Traffic volume onlyUnboundConfigured with qname-minimisation, use-caps-for-id, aggressive-nsec,

prefetch, harden-below-nxdomain and the newest auth-zone for local root
zone caching.

853dnsovertls3.sinodun.com5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8=YTraffic volume onlyHAProxy + BIND 9.12See
853dnsovertls2.sinodun.comNAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg=YTraffic volume onlyKnot ResolverSee
853 443dns.cmrg.net3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=

NoneKnot ResolverSee Note that on port 443 this server can serve both HTTP 1.1 traffic (to securely access the nameserver credentials) on TLS connections and DNS-over-TLS on separate TLS connections due to some nifty, experimental demultiplexing of traffic, described here.Has some issues with DNSSEC responses - this is under investigation.
Lorraine Data Network80.67.188.188

Traffic volume onlystunnel 4 + BINDSee (note, logging of IP address at stunnel no longer performed).
A self-signed certificate is used, so SPKI pinning is must be used.
No loggingKnot resolver


No logging

NOTE1: Located in Japan. Also does DoH.
NOTE2: Note that port 443 REQUIRES an authentication name

UPDATED 22nd JAN 2018: note the authentication name has changed



No logging

NOTE1: Located in Frankfurt. Also does DoH.
NOTE2: Note that port 443 REQUIRES an authentication name

No loggingUnbound
Secure DNS Project by PumpleX51.38.83.141
No logging
NOTE1: Also does DoH and dnscrypt
NOTE2: Performs ad blocking
Foundation for Applied Privacy146.255.56.98

YOnly aggregated logging, no PIIunbound


NOTE: Also does DoH and has an .onion endpoint

No loggingnginx + unbound

NOTE: Also does DoH and dnscrypt
no filters, opennic root copy

No logging
No logging

Servers with minimal logging/limitations

These servers use some logging, self-signed certs or no support for Strict mode.

Hosted byIP addressesTLS PortsHostname for TLS
Base 64 encoded form of SPKI pin(s) for TLS
authentication (RFC7858)
TLSA record publishedLoggingSoftwareNotes
NIC Chile
2001:1398:1:0:200:1:123:46 pUd9cZpbm9H8ws0tB55m9BXW4TrD4GZfBAB0ppCziBg=YYes, for research purposesUnboundDetails updated 18th Sept - now uses Let's encrypt cert
  • No labels


  1. Anonymous

    Lorraine Data Network servers are also available on port 443, and they provide a certificate on the linked webpage from which you can derive the SPKI pin.

  2. Anonymous

    1. Not all entries have the same color, can the styles be reseted?
    2. Is it possible to update the example stubby.yml file with the new servers?
    3. Should we create an more experimental list at the end and put the OARC DNS Privacy Server in there because no strict privacy supported?
  3. Anonymous

    Lorraine Data Network server is not enabled in monitoring

  4. Anonymous

    Wow, great! The following links should be corrected or removed. The JSON-Variant of the config should be updated or removed.

    A configuration file for Stubby containing a subset of these servers which can all be validated can be found here.

    A JSON file with the details of the same subset of servers can be downloaded here.

  5. Anonymous

    Still one death link: "The following are currently in the default Stubby config file mainly because they have been around longest and are the most stable."

    All adressed: You can now remove the last 4 comment from me

    1. Thanks for all the suggestions! I plan to add a yml and JSON file with the full set of servers to this page too. 

      LDN server was just added to the monitoring too. 

  6. Anonymous

    All entrys for IPv4 servers, except the logging ones, for use in the yml config file (110317):

  7. Thanks - we already have a PR to add the servers to the .yml file so users can choose which ones to enable. Should be in the next release of Stubby.

  8. Anonymous

    Wow thanks for all fixes...

    Some small cosmetic bugs:

    • the order of the list on the Wiki is not the same than the yaml file
    • the UncensoredDNS server is not enabled in the yaml
  9. Anonymous

    The recently released knot-resolver 1.5.1 fixes some stability issues, please update and check if the issue still exist

    1. It doesn't fix them all unfortunately. We are working with the developers to get this fixed.

  10. Anonymous

    Getting "Server Not Found" for some domains in Firefox when using Stubby. Same domains work fine when using Google or OpenDNS servers.

    Do any of the test servers have issue trackers?

  11. It is more likely a problem with Stubby - do you have any logs from stubby? If so please open an issue here for us to help you debug:

    Please let us know what OS you are using too. 

  12. Anonymous

    No. I'll enable logging and create an issue when I have the problem again.

  13. Hi Sara,

    It appears quad9 has officially announced support for DNS over TLS.

  14. Hello -

    It appears Cloudflare has officially announced a DNS resolver service. Interestingly enough, they support both DNS-Over-TLS and DNS-Over-HTTPS. For DNS-Over-TLS they specifically state they support TLS 1.2 and 1.3.

    From some tests I have performed, it appears to be pretty quick.

    1. how to add on stubby.yaml i try something like this but fail ?



      edited: just delete the pinset and change transport from TLS to TCP and just work

      1. You should be able to use the transport TLS. I have something like this in my config:

          - address_data:
            tls_auth_name: ""

        I think their doc might need a slight bit of clarification - they mention "" but if you check the example output they use ""

        1. yes the problem is on their cloudflare doc I just replace to work with pinset and TLS transport

          1. DOES NOT WORK ON MY END


              - address_data:
                tls_auth_name: ""
                  - digest: "sha256"
                    value: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=

            STUBBY: Read config from file stubby.yml

            STUBBY: Starting DAEMON....

            Could not schedule query: The context has internal deficiencies

            STUBBY: : Conn opened : TLS - Strict Profile

            STUBBY: : Verify failed : Transport=TLS - *Failure* -  (20) "unable to get local issuer certificate"

            STUBBY: : Conn closed : Transport=TLS - *Failure*

            STUBBY: *FAILURE* no valid transports or upstreams available!

            STUBBY: : Conn closed : TLS - Resps=0, Timeouts=0, Curr_auth=Failed, Keepalive(ms)=0

            STUBBY: : Upstream : TLS - Resps=0, Timeouts=0, Best_auth=Failed

            STUBBY: : Upstream : TLS - Conns=0, Conn_fails=0, Conn_shuts=0, Backoffs=0

            1. try config david more with no pinset


                  - address_data:
                    tls_auth_name: ""

                STUBBY: *FAILURE* no valid transports or upstreams available!

                Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports

                Other TLS resolvers such as work fine.
                Also, Cloudlflare’s DoH server works, so there are no issues with connectivity per se.

                1. I dont know what your problem but my config just something like



                  and just work

                  1. Tried your settings, but it does not work on my end.

                    I put stubby.exe and stubby.yml into archive for you to examine, could you try it?

                    1. look like your config is broke

                      try to reinstall stuby

                      this my config from my raspbian I dont have ipv6 network so I leave ipv6 server resolver

                      if you want use my config that only need is just edit listen address then replace default stubby config

                      reference to edit


                      You need to be careful around whitespaces in yaml file, it's sensitive to it

                      edited wrong upload :

                      1. After trimming #commented parts and changing listen address, our configs appear to be identical, even whitespaces match. Alas, your config doesn’t work either. Hmm, perhaps Stubby’s for Raspberry works somehow differently than Stubby 0.0.2 for Windows 7 does…

                        Also, be aware that your config specifies port 5053 on a separate line which goes against the reference (I quote: “Use <IP_address>@<port> to specify a different port”).

                        1. that strange my stubby windows runing fine


                          this my config stubby windows


                          just paste my config to folder stubby and change dns on dhcp windows to

                          1. Thanks for your diligent efforts, but it still does not work (downloaded the very YML and changed DHCP exactly to, log contains the same errors as before, Apprarently, I am not alone, check Github!

                            1. maybe Sara Dickinson can help or correct me if I wrong

  15. I would add CleanBrowsing Anycast DNS here as well. They support DNSCrypt, DoH and DNS over TLS on port 853.

    IPv4 address: and

    IPv6 address: 2a0d:2a00:1:: and 2a0d:2a00:2::

  16. Hi Sara, I run a DoT & DoH DNS Service in China with minimal logging. The service is named 'Rubyfish DNS', ip address are, Port 853 for DoT, 443 for DoH. Hostname for TLS-authentication is, Location in East_China,  privacy policy page:

  17. May you add my DoT server in "Servers with minimal logging/limitations" list? I run two servers for 2 months. I have renewed ssl certificate once and keep the fixed SPKI "DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo=", It's the only public DoT service in China Mainland as far as I know.

    Hosted by: Rubyfish Internet Tech

    IP addresses: and

    TLS Ports:853

    Hostname for TLS

    SPKI pin:DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo=

    Logging:Yes, see rubyfish website(only chinese version now)


    Notes: use upstream located in Hongkong/Janpan to resolve domains poisoned by the China-GFW, use upstream located in US-West.

    1. I've added the server - thank you! One request - please consider enabling DNSSEC validation on your servers (smile)

      1. Sure, I've enabled DNSSEC.   Would you update the Map of test server? located in Shanghai, located in Hangzhou.

  18. Hello, can you add the server I provided in mainland China to the list?
    Support DOT&&DOH, block ads and trackers.

    Service address:
    Shanghai (Eastern China):

    Chongqing (Western China):

    Beijing (North China):

    Guangzhou (Southern China):

    TLS Ports: 853
    Hostname for TLS authentication:
    Software: Unbound + DOH C/S

    Description address:

    Google is used upstream, why not use self-built? Because it needs to be friendly to CDN. At the same time, two servers in Hong Kong were used to avoid GFW pollution. We do not collect any data.

    1. Sorry for delay - done now

  19. GJQ

    HI Sara,

    Can you help to advise how do I configure Adguard DNS in stubby.  Attach link for your information. I cannot get stubby to use the adguard dns. Please assist 

    1. Hope you got this working. If not, I've created a PR for the stubby config file with new AdGuard configuration:

  20. Hi all,

    We've launched our DNS project. Information is available at


    Hosted By:


    IP Address (Anycast): or

    2a09:: or 2a09::1

    TLS Port:



    SPKI pin(s):

    (Expiry Date: Thursday, March 18, 2021)






    Public adblock server that supports DoT & DoH for fun and learning, no logging, supports DNSSEC, qname-minimisation, ECS is not enabled. Located in Iceland, built on pihole, nginx, unbound, m13253/DNS-over-HTTPS

    Doh -

    DoT -

    - address_data:
    tls_auth_name: ""
    - digest: "sha256"
    value: r3RmOoDlDavbinPSwyWNnz0qYsfx4gaIGYfORLPNQOs=

    - address_data: 2001:678:888:69:c45d:2738:c3f2:1878
    tls_auth_name: ""
    - digest: "sha256"
    value: r3RmOoDlDavbinPSwyWNnz0qYsfx4gaIGYfORLPNQOs=