Public resolvers
- Quad9 (9.9.9.9) and Cloudflare (1.1.1.1) 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.
DoT servers
The following servers are experimental DNS-over-TLS servers.
Stubby
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).
**Note that the Yeti servers use a different root key for DNSSEC! See the Yeti project for more details
Servers run by the Stubby developers
Hosted by | IP addresses | TLS Ports | Hostname for TLS authentication | Base 64 encoded form of SPKI pin(s) for TLS authentication (RFC7858) | TLSA record published | Logging | Software | Notes |
---|---|---|---|---|---|---|---|---|
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. | ||||||||
Surfnet | 145.100.185.15 2001:610:1:40ba:145:100:185:15 | 853 443 | dnsovertls.sinodun.com | 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4= | Y | Traffic volume only | HAProxy + BIND 9.12 | |
Surfnet | 145.100.185.16 2001:610:1:40ba:145:100:185:16 | 853 443 | dnsovertls1.sinodun.com | cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA= | Y | Traffic volume only | Nginx + BIND 9.12 | |
getdnsapi.net | 185.49.141.37 2a04:b900:0:100::37 | 853 | getdnsapi.net | foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9S= | Y | Traffic volume only | Unbound |
Other servers with a 'no logging' policy
Hosted by | IP addresses | TLS Ports | Hostname for TLS authentication | Base 64 encoded form of SPKI pin(s) for TLS authentication (RFC7858) | TLSA record published | Logging | Software | Notes |
UncensoredDNS | 89.233.43.71 2a01:3a0:53:53::0 | 853 | unicast.censurfridns.dk | wikE3jYAA6jQmXYTr/rbHeEPmC78dQwZbQp6WdrseEs= | Y | Traffic volume only | See https://blog.uncensoreddns.org/ | |
Fondation RESTENA | 158.64.1.29 | 853 | kaitain.restena.lu | 7ftvIkA+UeN/ktVkovd/7rPZ6mbkhVI7/8HnFJIiLa4= | Traffic volume only | Unbound | Configured with qname-minimisation, use-caps-for-id, aggressive-nsec, prefetch, harden-below-nxdomain and the newest auth-zone for local root | |
Surfnet | 145.100.185.18 2001:610:1:40ba:145:100:185:18 | 853 | dnsovertls3.sinodun.com | 5SpFz7JEPzF71hditH1v2dBhSErPUMcLPJx1uk2svT8= | Y | Traffic volume only | HAProxy + BIND 9.12 | Supports TLS 1.3 and TLS 1.2. Our initial stability problems are solved... see here for details. |
Surfnet | 145.100.185.17 2001:610:1:40ba:145:100:185:17 | 853 | dnsovertls2.sinodun.com | NAXBESvpjZMnPWQcrxa2KFIkHV/pDEIjRkA3hLWogSg= | Y | Traffic volume only | Knot Resolver | |
dkg | 199.58.81.218 2001:470:1c:76d::53 | 853 443 | dns.cmrg.net | 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo= 5zFN3smRPuHIlM/8L+hANt99LW26T97RFHqHv90awjo= | None | Knot Resolver | See https://dns.cmrg.net/ 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. | |
dns.larsdebruin.net (Previously dns1.darkmoon.is) | 51.15.70.167 | 853 | UPDATED on 30 Jan 2018 dns.larsdebruin.net | UPDATED on 30 Jan 2018 AAT+rHoKx5wQkWhxlfrIybFocBu3RBrPD2/ySwIwmvA= | Traffic volume only | Unbound | ||
securedns.eu | 146.185.167.43 2a03:b0c0:0:1010::e9a:3001 | 853 | dot.securedns.eu | h3mufC43MEqRD6uE4lz6gAgULZ5/riqH/E+U+jE3H8g= | None | HaProxy + Bind | NOTE 1: SecureDNS has support for additional TLDs of OpenNIC, Emercoin, and NamecoinNOTE 2: While both secure.eu and dot.secure.eu are running pin only validation for dot.secure.eu will not work! | |
dns-tls.bitwiseshift.net | 81.187.221.24 2001:8b0:24:24::24 | 853 | dns-tls.bitwiseshift.net | YmcYWZU5dd2EoblZHNf1jTUPVS+uK3280YYCdz4l4wo= | None | Unbound | ||
ns1.dnsprivacy.at | 94.130.110.185 2a01:4f8:c0c:3c03::2 | 853 | ns1.dnsprivacy.at | vqVQ9TcoR9RDY3TpO0MTXw1YQLjF44zdN3/4PkLwtEY= | None | Unbound | See https://dnsprivacy.at/ | |
ns2.dnsprivacy.at | 94.130.110.178 2a01:4f8:c0c:3bfc::2 | 853 | ns2.dnsprivacy.at | s5Em89o0kigwfBF1gcXWd8zlATSWVXsJ6ecZfmBDTKg= | None | Unbound | ||
dns.bitgeek.in (India) | 139.59.51.46 | 853 | dns.bitgeek.in | FndaG4ezEBQs4k0Ya3xt3z4BjFEyQHd7B75nRyP1nTs= | Traffic volume only | Nginx + BIND | ||
Lorraine Data Network | 80.67.188.188 2001:913::8 | 853 443 | WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM= | Traffic volume only | stunnel 4 + BIND | See https://ldn-fai.net/serveur-dns-recursif-ouvert/ (note, logging of IP address at stunnel no longer performed). A self-signed certificate is used, so SPKI pinning is must be used. | ||
dns.neutopia.org | 89.234.186.112 2a00:5884:8209::2 | 853 443 | dns.neutopia.org | wTeXHM8aczvhRSi0cv2qOXkXInoDU+2C+M8MpRyT3OI= | No logging | Knot resolver | ||
BlahDNS | 108.61.201.119 2001:19f0:7001:1ded:5400:01ff:fe90:945b | 853 | dot-jp.blahdns.com | No logging | NOTE: Located in Japan. Also does DoH. UPDATED 22nd JAN 2018: note the authentication name has changed | |||
BlahDNS | 159.69.198.101 2a01:4f8:1c1c:6b4b::1 | 853 | dot-de.blahdns.com | No logging | NOTE: Located in Frankfurt. Also does DoH. | |||
Go6Lab | 2001:67c:27e4::35 | 853 | privacydns.go6lab.si | g5lqtwHia/plKqWU/Fe2Woh4+7MO3d0JYqYJpj/iYAw= | No logging | Unbound | ||
Tenta | 99.192.182.200, 66.244.159.200 | 853 | iana.tenta.io | Traffic volume only | Tenta | https://tenta.com/privacy-policy | ||
Tenta | 99.192.182.100, 66.244.159.100 | 853 | opennic.tenta.io | Traffic volume only | Tenta | NOTE: Uses OpenNIC Root! | ||
dns.233py.com | Various, see notes | 853 | dns.233py.com | No logging | Unbound + DOH C/S | https://dns.233py.com (Chinese language version) Shanghai (Eastern China): 47.101.136.37/edns.233py.com NOTE: Blocks ads and trackers. Also support DoH (see website) | ||
DNS Warden | 213.136.85.253 | 853 | dot1.dnswarden.com | No logging | dnsdist | DETAILS UPDATED 6th Nov 2018 Website is a work in progress: dnswarden.com NOTE1: These servers have ad and tracker blocking with return of NXDOMAIN for bad domains. NOTE2: Also supports OpenNIC TLDs. Also does DoH. | ||
DNS Warden | 213.136.83.50 | 853 | dot2.dnswarden.com | No logging | dnsdist | |||
Servers with minimal logging/limitations
These servers use some logging, self-signed certs or no support for Strict mode.
Hosted by | IP addresses | TLS Ports | Hostname for TLS authentication | Base 64 encoded form of SPKI pin(s) for TLS authentication (RFC7858) | TLSA record published | Logging | Software | Notes |
NIC Chile dnsotls.lab.nic.cl | 200.1.123.46 2001:1398:1:0:200:1:123:46 | 853 | sG6kj+XJToXwt1M6+9BeCz1SOj/1/mdZn56OZvCyZZc= | Y | Yes, for research purposes | Unbound | Self-signed certificate, use SPKI pinning. | |
OARC | 184.105.193.78 2620:ff:c000:0:1::64:25 | 853 | tls-dns-u.odvr.dns-oarc.net | pOXrpUt9kgPgbWxBFFcBTbRH2heo2wHwXp1fd4AEVXI= | Yes, see OARC website | Unbound | See OARC website NOTE: As of June 2017 this server does not support Strict Mode because it does not offer the correct cipher suites to match RFC7525 recommendations. | |
Rubyfish Internet Tech | 115.159.154.226 | 853 | dns.rubyfish.cn | DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo= | Yes, see rubyfish website(only chinese version now) | Unbound | 115.159.154.226/ea-dns.rubyfish.cn use upstream located in Hongkong/Janpan to resolve domains poisoned by the China-GFW,47.99.165.31/uw-dns.rubyfish.cn use upstream located in US-West. |
40 Comments
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.
Sara Dickinson
Thanks - updated!
Anonymous
Anonymous
Lorraine Data Network server is not enabled in monitoring
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.
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
Sara Dickinson
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.
Anonymous
All entrys for IPv4 servers, except the logging ones, for use in the yml config file (110317): https://pastebin.com/Wd45uhXu
Sara Dickinson
Thanks - we already have a PR https://github.com/getdnsapi/stubby/pull/41 to add the servers to the .yml file so users can choose which ones to enable. Should be in the next release of Stubby.
Anonymous
Wow thanks for all fixes...
Some small cosmetic bugs:
Anonymous
The recently released knot-resolver 1.5.1 fixes some stability issues, please update and check if the issue still exist
John Dickinson
It doesn't fix them all unfortunately. We are working with the developers to get this fixed.
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?
Sara Dickinson
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:
https://github.com/getdnsapi/stubby/issues
Please let us know what OS you are using too.
Anonymous
No. I'll enable logging and create an issue when I have the problem again.
David Mora
Hi Sara,
It appears quad9 has officially announced support for DNS over TLS.
https://www.quad9.net/faq/#Does_Quad9_support_DNS_over_TLS
Sara Dickinson
Woop! Thanks
David Mora
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.
https://1.1.1.1/
https://developers.cloudflare.com/1.1.1.1/dns-over-https/
https://developers.cloudflare.com/1.1.1.1/dns-over-tls/
bagio
how to add on stubby.yaml i try something like this but fail ?
here1
here2
edited: just delete the pinset and change transport from TLS to TCP and just work
David Mora
You should be able to use the transport TLS. I have something like this in my config:
#Cloudflare
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
I think their doc might need a slight bit of clarification - they mention "dns.cloudflare.com" but if you check the example output they use "tls-host=cloudflare-dns.com"
bagio
yes the problem is on their cloudflare doc I just replace dns.cloudflare.com to cloudflare-dns.com work with pinset and TLS transport
James Bond
DOES NOT WORK ON MY END
#Cloudflare
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
tls_pubkey_pinset:
- 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: 1.1.1.1 : Conn opened : TLS - Strict Profile
STUBBY: 1.1.1.1 : Verify failed : Transport=TLS - *Failure* - (20) "unable to get local issuer certificate"
STUBBY: 1.1.1.1 : Conn closed : Transport=TLS - *Failure*
STUBBY: *FAILURE* no valid transports or upstreams available!
STUBBY: 1.1.1.1 : Conn closed : TLS - Resps=0, Timeouts=0, Curr_auth=Failed, Keepalive(ms)=0
STUBBY: 1.1.1.1 : Upstream : TLS - Resps=0, Timeouts=0, Best_auth=Failed
STUBBY: 1.1.1.1 : Upstream : TLS - Conns=0, Conn_fails=0, Conn_shuts=0, Backoffs=0
bagio
try config david more with no pinset
James Bond
REMOVING PINSET MAKES NO DIFFERENCE
#Cloudflare
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
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
P.S.
Other TLS resolvers such as unicast.censurfridns.dk work fine.
Also, Cloudlflare’s DoH server works, so there are no issues with connectivity per se.
bagio
I dont know what your problem but my config just something like
config
log
and just work
James Bond
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?
bagio
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
https://github.com/getdnsapi/stubby/blob/develop/stubby.yml.example
You need to be careful around whitespaces in yaml file, it's sensitive to it
edited wrong upload : https://transfer.sh/N5TkP/stubby.yml
James Bond
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”).
bagio
that strange my stubby windows runing fine
stubbywindows
this my config stubby windows
https://transfer.sh/v8av8/stubby.yml
just paste my config to folder stubby and change dns on dhcp windows to 127.0.1.1
James Bond
Thanks for your diligent efforts, but it still does not work (downloaded the very YML and changed DHCP exactly to 127.0.1.1), log contains the same errors as before, Apprarently, I am not alone, check Github!
bagio
maybe Sara Dickinson can help or correct me if I wrong
nick
I would add CleanBrowsing Anycast DNS here as well. They support DNSCrypt, DoH and DNS over TLS on port 853.
https://cleanbrowsing.org/dnsoverhttps
IPv4 address: 185.228.168.168 and 185.228.168.169
IPv6 address: 2a0d:2a00:1:: and 2a0d:2a00:2::
Yingbo Qiu
Hi Sara, I run a DoT & DoH DNS Service in China with minimal logging. The service is named 'Rubyfish DNS', ip address are 115.159.154.226, 47.99.165.31. Port 853 for DoT, 443 for DoH. Hostname for TLS-authentication is dns.rubyfish.cn, Location in East_China, privacy policy page: https://www.rubyfish.cn/privacy
Yingbo Qiu
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: 115.159.154.226 and 47.99.165.31
TLS Ports:853
Hostname for TLS authentication:dns.rubyfish.cn
SPKI pin:DBDigty3zDS7TN/zbQOmnjZ0qW+qbRVzlsDKSsTwSxo=
Logging:Yes, see rubyfish website(only chinese version now)
Software:Unbound
Notes:115.159.154.226/ea-dns.rubyfish.cn use upstream located in Hongkong/Janpan to resolve domains poisoned by the China-GFW,47.99.165.31/uw-dns.rubyfish.cn use upstream located in US-West.
Sara Dickinson
I've added the server - thank you! One request - please consider enabling DNSSEC validation on your servers
Yingbo Qiu
Sure, I've enabled DNSSEC. Would you update the Map of test server? 115.159.154.226 located in Shanghai, 47.99.165.31 located in Hangzhou.
XYZM
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): 47.101.136.37/edns.233py.com
Chongqing (Western China): 118.24.208.197/wdns.233py.com
Beijing (North China): 114.115.240.175/ndns.233py.com
Guangzhou (Southern China): 119.29.107.85/sdns.233py.com
TLS Ports: 853
Hostname for TLS authentication: dns.233py.com
Software: Unbound + DOH C/S
Description address: https://dns.233py.com/
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.
Sara Dickinson
Sorry for delay - done now
GJQ
HI Sara,
Can you help to advise how do I configure Adguard DNS in stubby. Attach link https://adguard.com/en/blog/adguard-dns-announcement/ for your information. I cannot get stubby to use the adguard dns. Please assist
Sara Dickinson
Hope you got this working. If not, I've created a PR for the stubby config file with new AdGuard configuration:
https://github.com/getdnsapi/stubby/pull/161