If you are interested in running your own DoT or DoH server this page provides some ideas. If you have specific questions feel free to email firstname.lastname@example.org
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 and DNS Public Resolvers.
While there are now several large organisations offering DNS Privacy services we encourage operators to run their on DNS Privacy servers to provide user choice. We recommend reading the Internet Draft on Best Current Practices for DNS Privacy Operators in order to try to provide a good, secure and private service for users. The document is a work in progress - feedback and comments welcome!
We are also 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, a few elsewhere) 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.
See the Implementations page to see what features are currently supported in the various open source nameserver implementations.
Example configurations can be found on this site for DNS-over-TLS
One good reference for available DoH implementations is https://github.com/curl/curl/wiki/DNS-over-HTTPS
A best current practice document for DNS privacy operators is under development, see BCP for DNS privacy operators for more details.
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.
Note that If you run a server which offers more than one certificate (e.g. via a proxy which uses SNI to route traffic) be aware that SPKI only authentication of the upstream can be limited. Because no SNI is provided when the client is performing SPKI only authentication it is limited to working (by many TLS library client implementations) for only the first certificate returned.
If you want to test connectivity to your nameserver from an external source you can use the getdns query webpage:
“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
You can also use various command line tools: