Traditional DNS queries and responses are sent over UDP or TCP without encryption. This is vulnerable to eavesdropping and spoofing (including DNS-based Internet filtering). Responses from recursive resolvers to clients are the most vulnerable to undesired or malicious changes, while communications between recursive resolvers and authoritative name servers often incorporate additional protection.
To address these problems, Google Public DNS offers DNS resolution over TLS-encrypted TCP connections as specified by RFC 7858. DNS-over-TLS improves privacy and security between clients and resolvers. This complements DNSSEC and protects DNSSEC-validated results from modification or spoofing on the way to the client.
How it Works
A client system can use DNS-over-TLS with one of two profiles: strict or opportunistic privacy. With the strict privacy profile, the user configures a DNS server name (the authentication domain name in RFC 8310) for DNS-over-TLS service and the client must be able to create a secure TLS connection on port 853 to the DNS server. Failure to establish a secure connection is a hard error and will result in no DNS service for the client.
With the opportunistic privacy profile, the DNS server IP address may be configured directly by the user or obtained from the local network (using DHCP or some other means). The client resolver attempts to establish a secure connection on port 853 to the specified DNS server. If a secure connection is established, this provides privacy for the user's queries from passive observers on the path. Since the client does not verify the authenticity of the server it is not protected from an active attacker. If the client cannot establish a secure connection on port 853, it falls back to communicating with the DNS server on the standard DNS port 53 over UDP or TCP without any security or privacy. The use of Opportunistic Privacy is intended to support incremental deployment of increased privacy with a view to widespread adoption of the strict privacy profile.
When using a strict privacy profile, stub resolvers establish a DNS-over-TLS connection with the following steps.
- The stub resolver is configured with the DNS-over-TLS resolver name
- The stub resolver obtains the IP address(es) for
dns.googleusing the local DNS resolver.
- The stub resolver makes a TCP connection to port 853 at the one those IP address.
- The stub resolver initiates a TLS handshake with the Google Public DNS resolver.
- The Google Public DNS server returns its TLS certificate along with a full chain of TLS certificates up to a trusted root certificate.
- The stub resolver verifies the server's identity based on the certificates
- If the identity cannot be validated, DNS name resolution fails and the stub resolver returns an error.
- After the TLS connection is established, the stub resolver has a secure communication path between to a Google Public DNS server.
- Now the stub resolver can send DNS queries and receive responses over the connection.
When using an opportunistic privacy profile, the client first attempts to create a secure TLS connection to the server. This is done similarly to the above with one important difference - no certificate validation is performed by the client. This means the identity of the server cannot be trusted. If a TLS connection on port 853 to the server cannot be established, the stub resolver falls back to talking to the DNS server on port 53.
As an experiment during the initial launch of the service we have disabled EDNS client subnet (ECS) for queries received over DNS-over-TLS. We plan to enable ECS for the DNS-over-TLS service at the end of the experiment.
Google Public DNS implements DNS-over-TLS based on RFC 7858. In addition we support the following recommendations to provide a high quality and low-latency DNS service.
- TLS 1.3 (RFC 8846)
- TCP Fast Open (RFC 7413)
- DNS Transport over TCP Implementation Requirements (RFC 7766)
Start Using It
See instructions to configure it on an Android 9 (Pie) device.