이 페이지는 Cloud Translation API를 통해 번역되었습니다.

DNS-over-HTTPS (DoH)

Google Public DNS는 다음 엔드포인트에서 두 가지 고유한 DoH API를 제공합니다.

보안 전송 개요 페이지에는 두 API를 모두 사용하는 명령줄 예시 curl개가 포함되어 있으며, TLS와 DNS over TLS (DoT) 및 DoH 둘 다에 공통으로 적용되는 기타 기능에 대한 자세한 내용도 확인할 수 있습니다.

DoH는 IPv6 전용 Google Public DNS64 서비스에서도 지원됩니다.

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 오류를 반환합니다.

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로 전환하는 것입니다.

TLS 암호화뿐만 아니라 HTTPS를 사용하면 다음과 같은 실질적인 이점이 있습니다.

널리 지원되고 잘 지원되는 HTTPS API는 Google Public DNS 자체와 잠재 클라이언트의 구현을 간소화합니다.
HTTPS 서비스는 웹 앱에 모든 DNS 레코드 유형에 대한 액세스를 제공하여 일반적으로 호스트 간 조회만 지원하는 기존 브라우저 및 OS DNS API의 제한을 피합니다.
QUIC UDP 기반 HTTPS 지원을 구현하는 클라이언트는 TCP 전송을 사용할 때 발생할 수 있는 대기 행렬 차단과 같은 문제를 방지할 수 있습니다.

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 지연 시간이 늘어날 수 있으므로 일반적으로 권장하지 않습니다. 하지만 개인 정보 보호에 민감한 애플리케이션에는 캐싱을 줄이는 것이 바람직하며, 사용자가 최근에 방문한 도메인을 확인하려고 하는 웹 앱의 타이밍 공격으로부터 보호할 수 있습니다.

버그를 신고하거나 새로운 기능을 요청하려면 DoH 문제를 여세요.