DNS-over-TLS

Introduction

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.

  1. The stub resolver is configured with the DNS-over-TLS resolver name dns.google.
  2. The stub resolver obtains the IP address(es) for dns.google using the local DNS resolver.
  3. The stub resolver makes a TCP connection to port 853 at the one those IP address.
  4. The stub resolver initiates a TLS handshake with the Google Public DNS resolver.
  5. The Google Public DNS server returns its TLS certificate along with a full chain of TLS certificates up to a trusted root certificate.
  6. The stub resolver verifies the server's identity based on the certificates presented.
    • If the identity cannot be validated, DNS name resolution fails and the stub resolver returns an error.
  7. After the TLS connection is established, the stub resolver has a secure communication path between to a Google Public DNS server.
  8. 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.

Privacy

Our privacy policy applies to the DNS-over-TLS service.

On 2019/06/27 we have re-enabled EDNS client subnet (ECS) for the DNS-over-TLS service. ECS was disabled at the launch of the service.

Standards Support

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.

Start Using It

See instructions to configure it on a device with Android 9 (Pie) or higher.

DNS-over-TLS is also supported for the IPv6-only Google Public DNS64 service. Note that configuring DNS64 for a mobile device that will attach to multiple networks is not recommended, as DNS64 only works when IPv6 is available.