Google Public DNS는 API 호출에 안전하지 않은 http: URL을 지원하지 않습니다.
HTTP 메서드
GET
GET 메서드를 사용하면 더 효과적으로 캐시되므로 지연 시간을 줄일 수 있습니다.
RFC 8484 GET 요청에는 Base64Url로 인코딩된 DNS 메시지가 있는 ?dns= 쿼리 매개변수가 있어야 합니다.
GET 메서드는 JSON API에 지원되는 유일한 메서드입니다.
POST
POST 메서드는 RFC 8484 API에서만 지원되며 요청 본문과 DoH HTTP 응답에 Content-Type application/dns-message와 함께 바이너리 DNS 메시지를 사용합니다.
HEAD
HEAD는 현재 지원되지 않으며 400 Bad Request 오류를 반환합니다.
다른 메서드는 501 Not Implemented 오류를 반환합니다.
HTTP 상태 코드
Google Public DNS DoH는 다음 HTTP 상태 코드를 반환합니다.
성공
200 확인
HTTP 파싱 및 DNS 리졸버와의 통신이 성공했으며 응답 본문 콘텐츠는 쿼리 엔드포인트, Accept 헤더 및 GET 매개변수에 따라 바이너리 또는 JSON 인코딩의 DNS 응답입니다.
리디렉션
301 영구 이전
클라이언트는 Location: 헤더에 제공된 URL로 다시 시도해야 합니다. 원래 쿼리가 POST 요청인 경우 클라이언트는 새 URL이 dns GET 매개변수 인수를 지정하는 경우에만 GET로 재시도해야 합니다. 그렇지 않으면 클라이언트는 POST로 다시 시도해야 합니다.
302 Found, 307 Temporary Redirect, 308 Permanent Redirect와 같은 다른 코드는 향후에 사용할 수 있으며 DoH 클라이언트는 4개의 코드를 모두 처리해야 합니다.
영구 301 및 308 코드가 포함된 응답은 무기한으로 캐시되어야 하며, 가능한 경우 사용자에게 새 URL을 사용하여 원래 구성을 업데이트하라는 메시지가 표시될 수 있습니다.
307 또는 308 응답을 받는 POST 요청은 항상 POST로 다시 시도해야 합니다.
오류
오류 응답은 HTML 또는 일반 텍스트를 사용하여 본문에 HTTP 상태를 설명합니다.
400 잘못된 요청
GET 매개변수 파싱 중 문제 발생 또는 잘못된 DNS 요청 메시지
잘못된 GET 매개변수의 경우 HTTP 본문에서 오류를 설명합니다. 대부분의 유효하지 않은 DNS 메시지는 FORMERR로 200 OK를 받습니다. 질문 섹션이 없는 깨진 메시지, 응답을 나타내는 QR 플래그 또는 바이너리 DNS 파싱 오류가 있는 기타 무의미한 플래그 조합의 경우 HTTP 오류가 반환됩니다.
413 페이로드가 너무 큼
RFC 8484 POST 요청 본문이 최대 메시지 크기인 512바이트를 초과했습니다.
414 URI가 너무 김
GET 쿼리 헤더가 너무 크거나 dns 매개변수에 최대 메시지 크기 512바이트를 초과하는 Base64Url로 인코딩된 DNS 메시지가 있습니다.
415 지원되지 않는 미디어 유형
POST 본문에 application/dns-message Content-Type 헤더가 없습니다.
429 너무 많은 요청
클라이언트가 일정 시간 동안 너무 많은 요청을 보냈습니다. 클라이언트는 Retry-After 헤더에 지정된 시간 (초 단위의 상대적 시간)이 될 때까지 요청 전송을 중지해야 합니다.
500 내부 서버 오류
Google Public DNS 내부 DoH 오류.
501 구현되지 않음
GET 메서드와 POST 메서드만 구현되며 다른 메서드에서 이 오류가 발생합니다.
502 잘못된 게이트웨이
DoH 서비스가 Google Public DNS 리졸버에 연결할 수 없습니다.
502 응답의 경우 대체 Google 공개 DNS 주소에서 재시도하면 도움이 될 수 있지만 더 효과적인 대체 응답은 다른 DoH 서비스를 사용해 보거나 8.8.8.8에서 기존 UDP 또는 TCP DNS로 전환하는 것입니다.
DoH의 이점
TLS 암호화뿐만 아니라 HTTPS를 사용하면 다음과 같은 실질적인 이점이 있습니다.
널리 지원되고 잘 지원되는 HTTPS API는 Google Public DNS 자체와 잠재 클라이언트의 구현을 간소화합니다.
HTTPS 서비스는 웹 앱에 모든 DNS 레코드 유형에 대한 액세스를 제공하여 일반적으로 호스트 간 조회만 지원하는 기존 브라우저 및 OS DNS API의 제한을 피합니다.
QUIC UDP 기반 HTTPS 지원을 구현하는 클라이언트는 TCP 전송을 사용할 때 발생할 수 있는 대기 행렬 차단과 같은 문제를 방지할 수 있습니다.
DoH 개인 정보 보호 권장사항
DoH 애플리케이션 개발자는 RFC 8484에 설명되어 있고 아래에 확장된 개인 정보 보호 권장사항을 고려해야 합니다.
HTTP 헤더 사용 제한
HTTP 헤더는 클라이언트의 DoH 구현에 관한 정보를 보여주며 클라이언트의 익명처리를 수행하는 데 사용할 수 있습니다. Cookie, User-Agent, Accept-Language와 같은 헤더는 최악의 위반자이지만 전송된 헤더 집합도 드러날 수 있습니다. 이러한 위험을 최소화하려면 DoH에 필요한 HTTP 헤더(Host, Content-Type(POST용), 필요한 경우 Accept)만 전송합니다.
User-Agent는 모든 개발 또는 테스트 버전에 포함되어야 합니다.
EDNS 패딩 옵션 사용
EDNS 패딩 옵션 사용에 관한 RFC 8467 안내에 따라 DoH 쿼리를 일반적인 길이로 패딩하여 트래픽 분석으로부터 보호하세요. HTTP/2 패딩을 사용할 수도 있지만 EDNS 패딩과 달리 DoH 서버의 응답에 패딩을 적용하지는 않습니다.
개인 정보 보호에 민감한 애플리케이션 또는 브라우저 모드에만 RFC 8484 POST를 사용합니다.
DoH 쿼리에 POST를 사용하면 응답의 캐시 가능성이 낮아지고 DNS 지연 시간이 늘어날 수 있으므로 일반적으로 권장하지 않습니다. 하지만 개인 정보 보호에 민감한 애플리케이션에는 캐싱을 줄이는 것이 바람직하며, 사용자가 최근에 방문한 도메인을 확인하려고 하는 웹 앱의 타이밍 공격으로부터 보호할 수 있습니다.
[null,null,["최종 업데이트: 2025-07-25(UTC)"],[[["\u003cp\u003eGoogle Public DNS offers two DoH APIs: \u003ccode\u003edns.google/dns-query\u003c/code\u003e (RFC 8484, GET & POST) and \u003ccode\u003edns.google/resolve\u003c/code\u003e (JSON API, GET only).\u003c/p\u003e\n"],["\u003cp\u003eDoH supports both IPv4 and IPv6 using HTTPS for enhanced security and wider accessibility.\u003c/p\u003e\n"],["\u003cp\u003eFor privacy, minimize HTTP headers, utilize EDNS padding, and consider RFC 8484 POST for sensitive applications.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Public DNS returns various HTTP status codes, including 200 OK for success (check DNS response code for errors) and error codes like 400, 413, 414, 415, 429, 500, 501, and 502.\u003c/p\u003e\n"],["\u003cp\u003eDoH benefits include wider API support, access to all DNS record types for web apps, and potential performance improvements with QUIC.\u003c/p\u003e\n"]]],["Google Public DNS offers two DoH APIs: one using RFC 8484 (supporting GET and POST) and a JSON API (GET only). GET requests use Base64Url-encoded DNS messages in the query parameters; POST requests use binary DNS messages. The service returns standard HTTP status codes, including 200 OK for success, and various error codes (400, 413, 414, 415, 429, 500, 501, 502), with 301, 307, and 308 for redirection. Privacy best practices include limiting HTTP headers, using EDNS padding, and employing POST for sensitive applications.\n"],null,["# DNS-over-HTTPS (DoH)\n\nGoogle Public DNS provides two distinct DoH APIs at these endpoints:\n\n- https://dns.google/dns-query -- [RFC 8484](https://tools.ietf.org/html/rfc8484) (GET and POST)\n- https://dns.google/resolve? -- [JSON API](/speed/public-dns/docs/doh/json) (GET)\n\n| **Note:** There is also a human-friendly web interface at \u003chttps://dns.google/\u003e. This web app displays JSON results in a browser but does not implement an API; do not confuse its https://dns.google/query? URLs with the two API URLs.\n\nThe [Secure Transports Overview](/speed/public-dns/docs/secure-transports#doh)\npage has `curl` command line examples for using both APIs as well as details of\nTLS and other features common to both DNS over TLS (DoT) and DoH.\n\nDoH is also supported for the IPv6-only\n[Google Public DNS64 service](/speed/public-dns/docs/dns64#secure).\n\nGoogle Public DNS does not support insecure `http:` URLs for API calls.\n\nHTTP methods\n------------\n\nGET\n: Using the GET method can reduce latency, as it is cached more effectively.\n RFC 8484 GET requests must have a `?dns=` query parameter with a\n Base64Url encoded DNS message.\n The GET method is the only method supported for the JSON API.\n\nPOST\n: The POST method is only supported for the RFC 8484 API and uses a binary DNS\n message with Content-Type application/dns-message in the request body and in\n the DoH HTTP response.\n\nHEAD\n: *HEAD is not currently supported, and returns a 400 Bad Request error*.\n\nOther methods return 501 Not Implemented errors.\n\nHTTP status codes\n-----------------\n\nGoogle Public DNS DoH returns the following HTTP status codes:\n\n### Success\n\n200 OK\n: HTTP parsing and communication with DNS resolver was successful, and the\n response body content is a DNS response in either binary or JSON encoding,\n depending on the query endpoint, Accept header and GET parameters.\n| **Note:** An HTTP success may still be a DNS failure. Check the DNS response code (JSON \"Status\" field) for the DNS errors SERVFAIL, FORMERR, REFUSED, and NOTIMP.\n\n### Redirections\n\n301 Moved Permanently\n: Clients should retry at the URL provided in the `Location:` header. If the\n original query was a POST request, clients should only retry with GET if the\n new URL specifies a `dns` GET parameter argument; otherwise clients should\n retry with POST.\n\nOther codes such as 302 Found, 307 Temporary Redirect or 308 Permanent Redirect\nmay be used in the future, and DoH clients should handle all four codes.\n\nResponses with the permanent 301 and 308 codes should be cached indefinitely,\nand if practical, users may be prompted to update their original configuration\nusing the new URL.\n\nPOST requests that get 307 or 308 responses should always be retried with POST.\n\n### Errors\n\nError responses will have an explanation of the HTTP status in the body,\nusing either HTML or plain text.\n\n400 Bad Request\n: Problems parsing the GET parameters, or an invalid DNS request message.\n For bad GET parameters, the HTTP body should explain the error. Most invalid\n DNS messages get a 200 OK with a FORMERR; the HTTP error is returned for\n garbled messages with no Question section, a QR flag indicating a reply, or\n other nonsensical flag combinations with binary DNS parse errors.\n\n413 Payload Too Large\n: An RFC 8484 POST request body exceeded the 512 byte maximum message size.\n\n414 URI Too Long\n: The GET query header was too large or the `dns` parameter had a Base64Url\n encoded DNS message exceeding the 512 byte maximum message size.\n\n415 Unsupported Media Type\n: The POST body did not have an `application/dns-message` Content-Type header.\n\n429 Too Many Requests\n: The client has sent too many requests in a given amount of time. Clients\n should stop sending requests until the time specified in the Retry-After\n header (a relative time in seconds).\n\n500 Internal Server Error\n: Google Public DNS internal DoH errors.\n\n501 Not Implemented\n: Only GET and POST methods are implemented, other methods get this error.\n\n502 Bad Gateway\n: The DoH service could not contact Google Public DNS resolvers.\n\nIn the case of a 502 response, although retrying on an alternate Google Public\nDNS address might help, a more effective fallback response would be to try\nanother DoH service, or to switch to traditional UDP or TCP DNS at 8.8.8.8.\n\nBenefits of DoH\n---------------\n\nUsing HTTPS, not just TLS encryption, has some practical benefits:\n\n- Widely available and well-supported HTTPS APIs simplify implementation for both Google Public DNS itself and potential clients.\n- An HTTPS service provides web apps with access to all DNS record types, avoiding the limitations of existing browser and OS DNS APIs, which generally support only host-to-address lookups.\n- Clients that implement QUIC UDP-based HTTPS support can avoid problems like head-of-line blocking that can occur when using TCP transport.\n\nPrivacy Best Practices for DoH\n------------------------------\n\nDevelopers of DoH applications should consider the privacy best practices\noutlined in [RFC 8484](https://tools.ietf.org/html/rfc8484#section-8) and\nexpanded below:\n\n- Limit use of HTTP Headers\n\n HTTP headers reveal information about the client's DoH implementation and\n can be used to deanonymize clients. Headers like Cookie, User-Agent, and\n Accept-Language are the worst offenders, but even the set of headers sent\n can be revealing. To minimize this risk, send only the HTTP headers required\n for DoH: Host, Content-Type (for POST), and if necessary, Accept.\n User-Agent should be included in any development or testing versions.\n- Use EDNS padding options\n\n Follow the guidance in [RFC 8467](https://tools.ietf.org/html/rfc8467) for\n use of EDNS padding options to pad DoH queries to a few common lengths to\n protect against traffic analysis. Use of HTTP/2 padding is also possible but\n unlike EDNS padding, will not elicit padding on responses from DoH servers.\n- Use RFC 8484 POST only for privacy sensitive applications or browser modes\n\n Using POST for DoH queries reduces the cacheability of responses and can\n increase DNS latency, so it is not generally recommended. However, reducing\n caching is probably desirable for privacy sensitive applications, and might\n protect against timing attacks from web apps trying to determine what\n domains the user has visited lately.\n\nIssues\n------\n\nTo report a bug or request a new feature, please open an [issue for DoH](https://issuetracker.google.com/issues/new?component=191657&template=1189745)."]]
