DNS Privacy Services

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)