A number of organisations have expressed interest in running experimental public DNS Privacy servers. At the moment this page just attempts to capture the different features/characteristics that a DNS Privacy server can offer in more detail that the overview here: DNS Privacy Implementation Status
The intension in future is to document what each service actually offers as it goes live, to allow users to make informed choices about which service they might utilise.
Feature/Characteristic | Relevant RFCs/I-Ds | Notes |
DNS-over-TLS on port 853 (IPv4) | RFC7858 | |
DNS-over-TLS on port 853 (IPv6) | RFC7858 | |
Compliance with BCP195 | RRC7525 | In particular, MUST implement TLS 1.2, SHOULD NOT negotiate TLS 1.1Use recommended Cipher Suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
TLS authentication via SPKI public keys provided securely via an out-of-band mechanism | RFC7858,draft-ietf-dprive-dtls-and-tls-profiles | Required for Strict Privacy using SPKI pinsets |
Verifiable certificate/certificate chain | RFC7858,draft-ietf-dprive-dtls-and-tls-profiles | Required for Strict Privacy using CA Certs |
Concurrent processing of TCP/TLS queries | RFC7766 | Improves performance by eliminating head of line blocking at the query level |
EDNS0 Keepalive | RFC7828 | Recommended for TLS connection management |
EDNS0 Client subnet privacy option | RFC7871 | Allows end users to specify their client subnet should not be sent to an authoritative server in the ENDS0 Client Subnet option |
EDNS0 padding | RFC7830 | Obfuscates message size, reduces effectiveness of traffic analysis. |
TCP Fast Open | RFC7413 | Data can be sent in the TCP SYN. For TLS the Client Hello can therefore be sent in the SYN reducing latency. |
QNAME minimisation to Auth Servers | RFC7816 | Reduce data sent to Authoritative servers, improves end user privacy |
De-identification of data | ||
Data retention policy (if no de-identification) |