기존 DNS 쿼리 및 응답은 암호화 없이 UDP 또는 TCP를 통해 전송됩니다.
이는 도청 및 스푸핑(DNS 기반 인터넷 필터링 포함)에 취약합니다.
재귀 리졸버에서 클라이언트에 대한 응답은 원하지 않거나 악의적인 변경에 가장 취약한 반면, 재귀 리졸버와 신뢰할 수 있는 네임서버 간의 통신에는 추가 보호가 적용되는 경우가 많습니다.
이러한 문제를 해결하기 위해 Google Public DNS는 RFC 7858에 지정된 대로 TLS로 암호화된 TCP 연결을 통해 DNS 변환을 제공합니다.
DNS-over TLS는 클라이언트와 리졸버 간의 개인 정보 보호 및 보안을 강화합니다. 이는 DNSSEC를 보완하고 클라이언트로 전송되는 도중에 수정 또는 스푸핑으로부터 DNSSEC 검증 결과를 보호합니다.
작동 방식
클라이언트 시스템은 엄격한 개인 정보 보호와 상황별 개인 정보 보호라는 두 가지 프로필 중 하나로 DNS-over-TLS를 사용할 수 있습니다. 엄격한 개인 정보 보호 프로필을 사용하면 사용자가 DNS over TLS 서비스를 위한 DNS 서버 이름 (RFC 8310의 인증 도메인 이름)을 구성하고 클라이언트는 포트 853에서 DNS 서버로의 보안 TLS 연결을 만들 수 있어야 합니다. 보안 연결 설정에 실패하면 심각한 오류이며 클라이언트에 대한 DNS 서비스가 제공되지 않습니다.
상황별 개인 정보 보호 프로필을 사용하면 DNS 서버 IP 주소를 사용자가 직접 구성하거나 DHCP 또는 다른 수단을 사용하여 로컬 네트워크에서 가져올 수 있습니다. 클라이언트 리졸버는 포트 853에서 지정된 DNS 서버에 대한 보안 연결을 설정하려고 시도합니다. 보안 연결이 설정된 경우 경로에 있는 수동적 관찰자의 사용자 쿼리에 대한 개인 정보 보호가 제공됩니다. 클라이언트는 서버의 진위를 확인하지 않으므로 활성 공격자로부터 보호되지 않습니다.
클라이언트가 포트 853에서 보안 연결을 설정할 수 없으면 보안 또는 개인 정보 보호 없이 UDP 또는 TCP를 통해 표준 DNS 포트 53에서 DNS 서버와의 통신으로 대체됩니다. Opportunistic Privacy(기회적 개인 정보 보호)의 사용은 엄격한 개인 정보 보호 프로필을 광범위하게 채택하여 강화된 개인 정보 보호를 점진적으로 배포할 수 있도록 지원하기 위한 것입니다.
엄격한 개인 정보 보호 프로필을 사용하는 경우 스텁 리졸버는 다음 단계에 따라 DNS-over-TLS 연결을 설정합니다.
스텁 리졸버는 DNS-over-TLS 리졸버 이름 dns.google로 구성됩니다.
스터브 리졸버는 로컬 DNS 리졸버를 사용하여 dns.google의 IP 주소를 가져옵니다.
스텁 리졸버는 해당 IP 주소의 포트 853에 TCP 연결을 설정합니다.
스텁 리졸버가 Google Public DNS 리졸버와 TLS 핸드셰이크를 시작합니다.
Google Public DNS 서버는 TLS 인증서를 신뢰할 수 있는 루트 인증서까지 전체 TLS 인증서 체인과 함께 반환합니다.
스터브 리졸버는 제공된 인증서를 기반으로 서버의 ID를 확인합니다.
ID를 확인할 수 없으면 DNS 이름 확인에 실패하고 스터브 리졸버가 오류를 반환합니다.
TLS 연결이 설정되면 스텁 리졸버에 Google Public DNS 서버와의 보안 통신 경로가 생깁니다.
이제 스터브 리졸버가 DNS 쿼리를 보내고 연결을 통해 응답을 수신할 수 있습니다.
편의적 개인 정보 보호 프로필을 사용할 때 클라이언트는 먼저 서버에 대한 보안 TLS 연결을 만들려고 합니다. 이 방법은 위와 유사하게 수행되며 한 가지 중요한 차이점이 있습니다. 클라이언트에서 인증서 유효성 검사를 실행하지 않는다는 점입니다.
즉, 서버의 ID를 신뢰할 수 없습니다. 포트 853에서 서버로의 TLS 연결을 설정할 수 없는 경우 스텁 리졸버는 포트 53의 DNS 서버와의 통신으로 대체됩니다.
[null,null,["최종 업데이트: 2025-07-25(UTC)"],[[["\u003cp\u003eGoogle Public DNS offers DNS resolution over TLS to enhance privacy and security between clients and resolvers, protecting against eavesdropping and spoofing.\u003c/p\u003e\n"],["\u003cp\u003eDNS-over-TLS operates using strict or opportunistic privacy profiles, with strict requiring authenticated connections to a specific server and opportunistic allowing fallback to unencrypted DNS if TLS fails.\u003c/p\u003e\n"],["\u003cp\u003eClient systems using DNS-over-TLS establish a secure connection by verifying the server's identity through TLS certificates, ensuring data is exchanged over an encrypted channel.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Public DNS supports standards such as TLS 1.3, TCP Fast Open, and DNS Transport over TCP to provide a high-quality and low-latency service.\u003c/p\u003e\n"],["\u003cp\u003eUsers can configure DNS-over-TLS on devices running Android 9 or higher and also utilize it with the IPv6-only Google Public DNS64 service, though the latter is not recommended for mobile devices on multiple networks.\u003c/p\u003e\n"]]],["DNS-over-TLS encrypts DNS queries and responses, enhancing privacy and security. It operates in two profiles: *strict* and *opportunistic*. Strict requires secure TLS connection verification on port 853, failing if validation fails. Opportunistic attempts secure connection on 853 but falls back to unsecured port 53 if it fails, without validating the server. Clients using strict profile resolve the server name, establish a TLS connection on port 853, and validate the server's certificate. Google Public DNS supports this method and follows related RFC specifications.\n"],null,["# DNS-over-TLS\n\nIntroduction\n------------\n\nTraditional DNS queries and responses are sent over UDP or TCP without\nencryption.\nThis is vulnerable to eavesdropping and spoofing\n(including DNS-based Internet filtering).\nResponses from recursive resolvers to clients are the most vulnerable to\nundesired or malicious changes, while communications between recursive resolvers\nand authoritative name servers often incorporate\n[additional protection](/speed/public-dns/docs/security#mitigations).\n\nTo address these problems, Google Public DNS offers DNS resolution over\nTLS-encrypted TCP connections as specified by [RFC 7858](https://tools.ietf.org/html/rfc7858).\nDNS-over-TLS improves privacy and security between clients and resolvers. This\ncomplements DNSSEC and protects DNSSEC-validated results from modification or\nspoofing on the way to the client.\n\nHow it Works\n------------\n\n| **Note:** This section gives an overview of DNS-over-TLS operation when talking to the Google Public DNS resolver (with the name `dns.google`). If you are interested in more details, please read the RFCs [Specification for DNS over Transport Layer Security](https://tools.ietf.org/html/rfc7858) and [Usage Profiles for DNS over TLS and DNS over DTLS](https://tools.ietf.org/html/rfc8310).\n\nA client system can use DNS-over-TLS with one of [two profiles](https://tools.ietf.org/html/rfc8310#section-5):\n*strict* or *opportunistic* privacy. With the strict privacy profile, the user\nconfigures a DNS server name (the *authentication domain name* in\n[RFC 8310](https://tools.ietf.org/html/rfc8310#section-2))\nfor DNS-over-TLS service and the client must be able to create a secure TLS\nconnection on port 853 to the DNS server. Failure to establish a secure\nconnection is a hard error and will result in no DNS service for the client.\n\nWith the opportunistic privacy profile, the DNS server IP address may be\nconfigured directly by the user or obtained from the local network (using DHCP\nor some other means). The client resolver attempts to establish a secure\nconnection on port 853 to the specified DNS server. If a secure connection is\nestablished, this provides privacy for the user's queries from passive observers\non the path. Since the client does not verify the authenticity of the server it\nis not protected from an active attacker.\nIf the client cannot establish a secure connection on port 853, it falls back to\ncommunicating with the DNS server on the standard DNS port 53 over UDP or TCP\nwithout any security or privacy. The use of Opportunistic Privacy is intended to\nsupport incremental deployment of increased privacy with a view to widespread\nadoption of the strict privacy profile.\n\nWhen using a strict privacy profile, stub resolvers establish a DNS-over-TLS\nconnection with the following steps.\n\n1. The stub resolver is configured with the DNS-over-TLS resolver name `dns.google`.\n2. The stub resolver obtains the IP address(es) for `dns.google` using the local DNS resolver.\n3. The stub resolver makes a TCP connection to port 853 at the one those IP address.\n4. The stub resolver initiates a TLS handshake with the Google Public DNS resolver.\n5. The Google Public DNS server returns its TLS certificate along with a full chain of TLS certificates up to a trusted root certificate.\n6. The stub resolver verifies the server's identity based on the certificates presented.\n - If the identity cannot be validated, DNS name resolution fails and the stub resolver returns an error.\n7. After the TLS connection is established, the stub resolver has a secure communication path between to a Google Public DNS server.\n8. Now the stub resolver can send DNS queries and receive responses over the connection.\n\nWhen using an opportunistic privacy profile, the client first attempts to create\na secure TLS connection to the server. This is done similarly to the above with\none important difference - no certificate validation is performed by the client.\nThis means the identity of the server cannot be trusted. If a TLS connection on\nport 853 to the server cannot be established, the stub resolver falls back to\ntalking to the DNS server on port 53.\n| **Note:** To prevent denial of service attacks and resource exhaustion on the server, Google Public DNS may close DNS-over-TLS connections that have been idle too long or when a large number of queries have been received on the connection. The next time the client needs to perform DNS queries, the stub resolver will repeat the steps above to re-establish a connection to the Google Public DNS resolver.\n\nPrivacy\n-------\n\nOur [privacy policy](/speed/public-dns/privacy) applies to the DNS-over-TLS service.\n\nOn 2019/06/27 we have re-enabled [EDNS client subnet (ECS)](/speed/public-dns/docs/ecs)\nfor the DNS-over-TLS service. ECS was disabled at the launch of the service.\n\nStandards Support\n-----------------\n\nGoogle Public DNS implements DNS-over-TLS based on [RFC 7858](https://tools.ietf.org/html/rfc7858).\nIn addition we support the following recommendations to provide a high quality\nand low-latency DNS service.\n\n- [TLS 1.3 (RFC 8846)](https://tools.ietf.org/html/rfc8446)\n- [TCP Fast Open (RFC 7413)](https://tools.ietf.org/html/rfc7413)\n- [DNS Transport over TCP Implementation Requirements (RFC 7766)](https://tools.ietf.org/html/rfc7766)\n\nStart Using It\n--------------\n\nSee [instructions](/speed/public-dns/docs/using#android) to configure it on a\ndevice with Android 9 (Pie) or higher.\n\nDNS-over-TLS is also supported for the IPv6-only\n[Google Public DNS64 service](/speed/public-dns/docs/dns64#secure). Note that configuring DNS64 for a\nmobile device that will attach to multiple networks is not recommended, as DNS64\nonly works when IPv6 is available."]]
