If you are interested in running your own DNS-over-TLS server this page provides some ideas. If you have specific questions feel free to email email@example.com
Contributing to the project
We welcome and are keen to support anyone who would like to run an open DNS Privacy Server and make the server details available to the DNS Privacy project. For an overview of why DNS Privacy is important, please see DNS Privacy - The Problem. The current list of servers is available here DNS Privacy Test Servers.
No large scale DNS operators are offering DNS Privacy using DNS-over-TLS yet so the availability of the service is currently entirely dependent on the set of volunteers who run experimental servers and make them available to the project.
We are very keen to increase the number and geographical distribution of the available servers to better serve the global population of users for whom DNS Privacy is important. Most of the servers are currently based in Europe (a few in North America, one in South America) which means users in other parts of the world may be blocked from accessing them but are also likely to experience poor performance (high latency) for DNS queries. We see a particular need for DNS Privacy servers in areas such as the Middle East, Africa and Asia to enable activists and journalist local access to DNS Privacy services.
We have a goal of establishing at least two DNS Privacy servers in each of Asia, Africa, South America and Australia during 2018.
Pick your software
See the Implementations page to see what features are currently supported in the various open source nameserver implementations.
- Don't forget that you can also run a TLS-proxy in front of any nameserver too (and there is a Docker image for doing this with BIND).
Example configurations can be found on this site for:
Does my server need a X.509 certificate?
In order to allow users to authenticate the server (for 'Strict' mode) the server needs to be configured with a X.509 certificate. This is optional but recommended.
- Many of the existing servers use the great service at Let's Encrypt to obtain certificates. See our how-to guide on using Let's Encrypt.
- If you do this then it is helpful to also provide the pinset for the certificate (the SHA-256 fingerprint of the public key) as an alternative validation mechanism. See how to generate an SPKI pinset from a certificate.
- If you do this then it is also recommended to
- Use the same key(s) when renewing the certificate to avoid having to manage key rollovers see: short guide on Let's Encrypt Key renewal.
- Provide 2 keys to enable key roll should you need to roll your keys
Test your server
If you want to test connectivity to your nameserver from an external source you can use the getdns query webpage:
- Enter a domain name to query for in the top box
- Check the 'return_call_reporting' in the Extensions box
- Select 'TLS' as the transport in the Transport box and enter the IP address and optionally the Authentication domain name for your server
- Hit Query
- The output will contain a section at the top called 'call_reporting' which include the following fields
"transport": GETDNS_TRANSPORT_TLS to confirm the query worked over TLS
tls_auth_status": <bindata of "Success"> if the certificate was successfully authenticated
"run_time/ms": 215 response time from the query server which is based in the Netherlands
Monitor your server
A fork of dnsperf now exists that supports TCP. In future TLS support will also be added.