تحتوي صفحة نظرة عامة على عمليات النقل الآمن
على أمثلة على سطر الأوامر curl لاستخدام كل من واجهة برمجة التطبيقات، بالإضافة إلى تفاصيل
بروتوكول أمان طبقة النقل والميزات الأخرى الشائعة لكل من نظام أسماء النطاقات عبر بروتوكول أمان طبقة النقل (DoT) وبروتوكول DoH.
لا يدعم "نظام أسماء النطاقات العام من Google" عناوين URL غير آمنة http: لاستدعاءات واجهة برمجة التطبيقات.
طرق HTTP
GET
يمكن أن يؤدي استخدام طريقة GET إلى تقليل وقت الاستجابة، حيث يتم تخزينها مؤقتًا بشكل أكثر فاعلية.
يجب أن تحتوي طلبات RFC 8484 GET على معلمة طلب البحث ?dns= مع رسالة نظام أسماء النطاقات بترميز Base64Url.
وطريقة GET هي الطريقة الوحيدة المتوافقة مع JSON API.
POST
لا يمكن استخدام طريقة POST إلا مع RFC 8484 API واستخدام رسالة نظام أسماء النطاقات الثنائية مع Content-Type/dns-message في نص الطلب وفي استجابة DoH HTTP.
HEAD
HEAD غير متاح حاليًا، ويعرض الخطأ 400 "طلب غير صالح".
تعرض الطرق الأخرى أخطاء 501 لم يتم التنفيذ.
رموز حالة HTTP
تعرض خدمة Google Public DNS DoH رموز حالة HTTP التالية:
تم الإجراء بنجاح
200 حسنًا
نجح تحليل HTTP والتواصل باستخدام برنامج تعيين نظام أسماء النطاقات، وكان
محتوى نص الاستجابة عبارة عن استجابة نظام أسماء النطاقات إما بترميز ثنائي أو ترميز JSON،
بناءً على نقطة نهاية طلب البحث، والعنوان "قبول" ومعلمات GET.
إعادات التوجيه
301 تم نقلها نهائيًا
على العملاء إعادة المحاولة على عنوان URL المقدَّم في عنوان Location:. إذا كان طلب البحث الأصلي عبارة عن طلب POST، يجب على البرامج إعادة المحاولة باستخدام GET فقط إذا كان عنوان URL الجديد يحدد وسيطة معلَمة GET dns، وإلا يجب على البرامج إعادة المحاولة باستخدام POST.
قد يتم استخدام رموز أخرى في المستقبل مثل 302 Found أو 307 عدو التوجيه 307 أو إعادة التوجيه الدائمة 308 ، ويجب على عملاء DoH معالجة جميع الرموز الأربعة.
يجب تخزين الردود التي تتضمّن الرمزين الدائمين 301 و308 مؤقتًا إلى أجل غير مسمى، وإذا كان ذلك عمليًا، قد يُطلب من المستخدمين تعديل الإعدادات الأصلية باستخدام عنوان URL الجديد.
إنّ طلبات POST التي تتلقّى 307 أو 308 ردود يجب إعادة المحاولة دائمًا باستخدام POST.
الأخطاء
ستعرض استجابات الخطأ حالة HTTP في النص الأساسي، باستخدام HTML أو نص عادي.
400 طلب غير صالح
حدثت مشاكل أثناء تحليل معلَمات GET، أو رسالة طلب غير صالحة لنظام أسماء النطاقات.
بالنسبة إلى معلمات GET غير صحيحة، يجب أن يشرح نص HTTP الخطأ. تحصل معظم رسائل نظام أسماء النطاقات غير الصالحة
على نسبة 200 مقبولة مع FORMERR؛ ويظهر خطأ HTTP
للرسائل المشوهة التي لا تحتوي على قسم أسئلة، أو علامة استجابة سريعة تشير إلى رد، أو
مجموعات العلامات الأخرى غير المنطقية التي تتضمن أخطاءً في تحليل نظام أسماء النطاقات الثنائية.
413 حمولة البيانات كبيرة جدًا
تجاوز نص طلب RFC 8484 POST الحد الأقصى لحجم الرسالة وهو 512 بايت.
414 URI طويل جدًا
كان عنوان طلب البحث GET كبيرًا جدًا أو احتوت المعلمة dns على رسالة نظام أسماء نطاقات بترميز Base64Url تتجاوز الحد الأقصى لحجم الرسالة وهو 512 بايت.
415 نوع الوسائط غير متوافق
لم يتضمّن نص POST عنوانًا من نوع المحتوى application/dns-message.
429 طلب كبير جدًا
أرسل العميل عددًا كبيرًا جدًا من الطلبات في فترة زمنية معيّنة. ويجب أن يتوقف العملاء عن إرسال الطلبات حتى الوقت المحدَّد في العنوان "إعادة المحاولة بعد" (وقت نسبي بالثواني).
500 خطأ في الخادم الداخلي
أخطاء DoH الداخلية العامة لنظام أسماء النطاقات في Google
501 لم يتم التنفيذ
يتم تنفيذ طريقتَي GET وPOST فقط، بينما يظهر هذا الخطأ في الطرق الأخرى.
502 مدخل غير صالح
تعذّر على خدمة وزارة الصحة التواصل مع برامج تعيين نظام أسماء النطاقات العام من Google.
في حالة الاستجابة 502، على الرغم من أن إعادة محاولة استخدام عنوان نظام أسماء نطاقات عام بديل لـ Google قد يكون مفيدًا، فإن الاستجابة الاحتياطية الأكثر فعالية ستكون تجربة
خدمة DoH أخرى أو التبديل إلى نظام أسماء النطاقات UDP أو TCP التقليدي في الإصدار 8.8.8.8.
مزايا DoH
يوفر استخدام HTTPS، وليس تشفير TLS فقط، بعض المزايا العملية:
تعمل واجهات برمجة تطبيقات HTTPS المتاحة على نطاق واسع والمتوافقة على تبسيط عملية التنفيذ
لكل من "نظام أسماء النطاقات العام من Google" نفسه والعملاء المحتملين.
وتوفّر خدمة HTTPS لتطبيقات الويب إمكانية الوصول إلى جميع أنواع سجلات نظام أسماء النطاقات،
متجنبًا القيود المفروضة على واجهات برمجة التطبيقات لنظام أسماء النطاقات للمتصفّح وأنظمة التشغيل الحالية، والتي
لا تتيح بشكل عام سوى عمليات البحث من المضيف إلى العنوان.
يمكن للعملاء الذين يستخدمون دعم HTTPS استنادًا إلى بروتوكول QUIC UDP أن يتجنّبوا مشاكل مثل حظر البداية التي قد تحدث عند استخدام بروتوكول TCP لنقل البيانات.
أفضل ممارسات الخصوصية لدى وزارة الصحة
على مطوّري تطبيقات DoH مراعاة أفضل ممارسات الخصوصية الموضّحة في RFC 8484 والموضّحة أدناه:
الحدّ من استخدام عناوين HTTP
تكشف عناوين HTTP عن معلومات حول تنفيذ DoH لدى العميل ويمكن استخدامها لإخفاء هوية العملاء. إن العناوين، مثل Cookie وUser-Agent وAccept-Language، هي أكثر الأخطاء تعقيدًا، ولكن حتى مجموعة العناوين المرسَلة قد تكون ظاهرة. للحد من هذا الخطر، أرسل فقط عناوين HTTP المطلوبة لـ DoH: المضيف، ونوع المحتوى (لـ POST)، والقبول إذا لزم الأمر.
يجب تضمين وكيل المستخدم في أي إصدارات للتطوير أو الاختبار.
استخدام خيارات المساحة المتروكة في EDNS
اتَّبِع الإرشادات الواردة في RFC 8467 لاستخدام خيارات المساحة المتروكة في EDNS لضبط طلبات بحث DoH على عدد قليل من الأطوال الشائعة للحماية من تحليل عدد الزيارات. من الممكن أيضًا استخدام مساحة متروكة لـ HTTP/2، ولكن على عكس المساحة المتروكة EDNS، لن يستدعي ذلك مساحة متروكة للاستجابات من خوادم DoH.
استخدام RFC 8484 POST فقط في التطبيقات الحسّاسة المتعلقة بالخصوصية أو أوضاع المتصفّح
يؤدي استخدام POST لطلبات 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)."]]
