صفحه بررسی اجمالی حمل و نقل ایمن دارای نمونه‌های خط فرمان curl برای استفاده از هر دو API و همچنین جزئیات TLS و سایر ویژگی‌های مشترک برای DNS از طریق TLS (DoT) و DoH است.
Google Public DNS از آدرس های http: ناامن برای تماس های API پشتیبانی نمی کند.
روش های HTTP
گرفتن
استفاده از روش GET می تواند تاخیر را کاهش دهد، زیرا به طور موثرتری در حافظه پنهان ذخیره می شود. درخواست های RFC 8484 GET باید دارای یک پارامتر پرس و جو ?dns= با پیام DNS کدگذاری شده Base64Url باشند. متد GET تنها روشی است که برای JSON API پشتیبانی می شود.
پست
روش POST فقط برای RFC 8484 API پشتیبانی می‌شود و از یک پیام DNS باینری با Content-Type application/dns-message در بدنه درخواست و در پاسخ HTTP DoH استفاده می‌کند.
سر
HEAD در حال حاضر پشتیبانی نمی‌شود و یک خطای 400 Bad Request را برمی‌گرداند .
روش‌های دیگر خطاهای 501 Not Implemented را برمی‌گردانند.
کدهای وضعیت HTTP
Google Public DNS DoH کدهای وضعیت HTTP زیر را برمی گرداند:
موفقیت
200 باشه
تجزیه HTTP و ارتباط با حل‌کننده DNS موفقیت‌آمیز بود، و محتوای بدنه پاسخ، بسته به نقطه پایانی پرس و جو، هدر پذیرش و پارامترهای GET، یک پاسخ DNS در کدگذاری باینری یا JSON است.
تغییر مسیرها
301 به طور دائم منتقل شد
مشتریان باید در URL ارائه شده در هدر Location: دوباره امتحان کنند. اگر پرس و جو اصلی یک درخواست POST بود، کلاینت ها فقط باید با GET دوباره امتحان کنند که URL جدید یک آرگومان پارامتر dns GET را مشخص کند. در غیر این صورت مشتریان باید با POST دوباره امتحان کنند.
ممکن است در آینده از کدهای دیگری مانند 302 Found، 307 Temporary Redirect یا 308 Permanent Redirect استفاده شود و مشتریان DoH باید هر چهار کد را کنترل کنند.
پاسخ‌هایی با کدهای 301 و 308 دائمی باید به‌طور نامحدود ذخیره شوند و در صورت عملی، ممکن است از کاربران خواسته شود که پیکربندی اصلی خود را با استفاده از URL جدید به‌روزرسانی کنند.
درخواست های POST که 307 یا 308 پاسخ می گیرند همیشه باید با POST دوباره امتحان شوند.
خطاها
پاسخ های خطا با استفاده از HTML یا متن ساده توضیحی درباره وضعیت HTTP در بدنه خواهند داشت.
400 درخواست بد
مشکل در تجزیه پارامترهای GET یا پیام درخواست DNS نامعتبر. برای پارامترهای بد GET، بدنه HTTP باید خطا را توضیح دهد. اکثر پیام های DNS نامعتبر با FORMERR 200 OK دریافت می کنند. خطای HTTP برای پیام‌های مخدوش بدون بخش سؤال، یک پرچم QR که نشان‌دهنده پاسخ است، یا سایر ترکیب‌های پرچم غیرمعنا با خطاهای تجزیه DNS باینری بازگردانده می‌شود.
413 محموله خیلی بزرگ
یک بدنه درخواست RFC 8484 POST از حداکثر اندازه پیام 512 بایت فراتر رفته است.
414 URI خیلی طولانی است
سرصفحه پرس و جو GET خیلی بزرگ بود یا پارامتر dns یک پیام DNS رمزگذاری شده Base64Url داشت که از حداکثر اندازه پیام 512 بایت بیشتر بود.
415 نوع رسانه پشتیبانی نشده
بدنه POST هدر application/dns-message Content-Type نداشت.
429 درخواست خیلی زیاد
مشتری در مدت زمان معین درخواست های زیادی ارسال کرده است. مشتریان باید ارسال درخواست ها را تا زمان مشخص شده در سربرگ Retry-After متوقف کنند (زمان نسبی بر حسب ثانیه).
500 خطای سرور داخلی
خطاهای DoH داخلی DNS عمومی Google.
501 اجرا نشد
فقط متدهای GET و POST پیاده سازی می شوند، روش های دیگر این خطا را دریافت می کنند.
دروازه بد 502
سرویس DoH نمی تواند با حل کننده های DNS عمومی Google تماس بگیرد.
در مورد یک پاسخ 502، اگرچه تلاش مجدد بر روی یک آدرس DNS عمومی Google جایگزین ممکن است کمک کند، یک پاسخ بازگشتی موثرتر این است که سرویس DoH دیگری را امتحان کنید یا به UDP سنتی یا TCP DNS در 8.8.8.8 تغییر دهید.
مزایای DoH
استفاده از HTTPS، نه فقط رمزگذاری TLS، مزایای عملی دارد:
API های HTTPS به طور گسترده در دسترس و با پشتیبانی خوب، پیاده سازی را هم برای خود DNS عمومی Google و هم برای مشتریان بالقوه ساده می کند.
یک سرویس HTTPS به برنامه‌های وب دسترسی به انواع رکوردهای DNS را فراهم می‌کند، و از محدودیت‌های موجود در مرورگر و APIهای DNS سیستم‌عامل، که عموماً فقط جستجوهای میزبان به آدرس را پشتیبانی می‌کنند، اجتناب می‌کند.
کلاینت هایی که پشتیبانی از HTTPS مبتنی بر UDP QUIC را اجرا می کنند، می توانند از مشکلاتی مانند مسدود کردن سر خط که هنگام استفاده از انتقال TCP رخ می دهد، جلوگیری کنند.
بهترین شیوه های حفظ حریم خصوصی برای DoH
توسعه دهندگان برنامه های کاربردی DoH باید بهترین شیوه های حفظ حریم خصوصی را که در RFC 8484 بیان شده و در زیر گسترش یافته است، در نظر بگیرند:
استفاده از هدرهای HTTP را محدود کنید
هدرهای HTTP اطلاعاتی را در مورد اجرای DoH کلاینت نشان می‌دهند و می‌توان از آنها برای بی‌نام کردن کلاینت‌ها استفاده کرد. سرصفحه هایی مانند Cookie، User-Agent و Accept-Language بدترین متخلفان هستند، اما حتی مجموعه هدرهای ارسال شده نیز می تواند فاش کننده باشد. برای به حداقل رساندن این خطر، فقط هدرهای HTTP مورد نیاز برای DoH را ارسال کنید: Host، Content-Type (برای POST)، و در صورت لزوم، Accept. User-Agent باید در هر نسخه توسعه یا آزمایشی گنجانده شود.
از گزینه های EDNS padding استفاده کنید
دستورالعمل RFC 8467 را برای استفاده از گزینه‌های padding EDNS برای تکمیل درخواست‌های DoH به چند طول معمول برای محافظت در برابر تجزیه و تحلیل ترافیک دنبال کنید. استفاده از padding HTTP/2 نیز امکان پذیر است، اما بر خلاف EDNS padding، باعث ایجاد padding در پاسخ ها از سرورهای DoH نمی شود.
از RFC 8484 POST فقط برای برنامه های حساس به حریم خصوصی یا حالت های مرورگر استفاده کنید
استفاده از POST برای پرس و جوهای DoH قابلیت ذخیره سازی پاسخ ها را کاهش می دهد و می تواند تأخیر DNS را افزایش دهد، بنابراین به طور کلی توصیه نمی شود. با این حال، کاهش حافظه پنهان احتمالاً برای برنامه‌های حساس به حریم خصوصی مطلوب است و ممکن است در برابر حملات زمان‌بندی برنامه‌های وب که تلاش می‌کنند تعیین کنند کاربر اخیراً از چه دامنه‌هایی بازدید کرده است محافظت کند.
مسائل
برای گزارش یک اشکال یا درخواست یک ویژگی جدید، لطفاً یک مشکل را برای DoH باز کنید.
تاریخ آخرین به‌روزرسانی 2025-07-25 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین به‌روزرسانی 2025-07-25 بهوقت ساعت هماهنگ جهانی."],[[["\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)."]]
