בדף סקירה כללית של העברות מאובטחות תוכלו למצוא curl דוגמאות לשורת הפקודה לשימוש בממשקי ה-API וגם בפרטים של TLS ושל תכונות אחרות המשותפות ל-DNS over TLS (DoT) ול-DoH.
ב-DNS הציבורי של Google אין תמיכה בכתובות URL לא מאובטחות של http: לקריאות ל-API.
שיטות HTTP
GET
שימוש בשיטת GET יכול לקצר את זמן האחזור, כי הוא נשמר במטמון בצורה יעילה יותר.
בקשות RFC 8484 GET חייבות לכלול פרמטר שאילתה ?dns= עם הודעת DNS בקידוד Base64Url.
שיטת GET היא השיטה היחידה שנתמכת ב-JSON API.
POST
שיטת ה-POST נתמכת רק ב-RFC 8484 API ומשתמשת בהודעת DNS בינארית עם Content-Type application/dns-message בגוף הבקשה ובתגובת ה-HTTP של DoH.
HEAD
HEAD אין כרגע נתמך, ומחזיר שגיאה 400 של 'בקשה שגויה'.
שיטות אחרות מחזירות שגיאות 501 Not Implemented.
קודי מצב HTTP
Google Public DNS DoH מחזיר את קודי מצב ה-HTTP הבאים:
הפעולה הצליחה
200 תקין
ניתוח HTTP ותקשורת עם מקודד ה-DNS בוצע בהצלחה, והתוכן של גוף התגובה הוא תגובת DNS בקידוד בינארי או בקידוד JSON, בהתאם לנקודת הקצה של השאילתה, הפרמטרים מסוג 'קבלה של הכותרת' ו-'GET'.
הפניות מחדש
301 הועבר לצמיתות
הלקוחות צריכים לנסות שוב בכתובת ה-URL שצוינה בכותרת Location:. אם
השאילתה המקורית הייתה בקשת POST, לקוחות צריכים לנסות שוב עם GET רק אם
בכתובת ה-URL החדשה מצוין ארגומנט של פרמטר GET dns. אחרת, הלקוחות צריכים
לנסות שוב עם POST.
ניתן להשתמש בקודים אחרים כמו 302 Found, 307 Redirect Redirect או 308 Redirect Redirect, ולקוחות DoH צריכים לטפל בכל ארבעת הקודים.
תגובות עם קודי 301 ו-308 קבועים יישמרו במטמון ללא הגבלת זמן, ואם זה יהיה אפשרי, ייתכן שהמשתמשים יתבקשו לעדכן את ההגדרות המקוריות באמצעות כתובת ה-URL החדשה.
אם בקשות POST מקבלות תשובות 307 או 308, תמיד צריך לנסות שוב באמצעות POST.
שגיאות
בתגובות לשגיאות יוצג הסבר על מצב ה-HTTP בגוף, באמצעות HTML או טקסט פשוט.
400 בקשה לא תקינה
בעיות בניתוח הפרמטרים של GET או הודעה לא חוקית של בקשת DNS.
אם מדובר בפרמטרים שגויים של GET, גוף ה-HTTP צריך להסביר את השגיאה. רוב הודעות ה-DNS הלא חוקיות מקבלות ערך 200 OK עם FORMERR, שגיאת HTTP מוחזרת כשיש הודעות משובשות ללא קטע Question, דגל QR עם תשובה לשאלה או שילובים לא הגיוניים של דגלים עם שגיאות ניתוח של DNS בינארי.
413 Payload Large
גוף של בקשת RFC 8484 POST חרג מגודל ההודעה המקסימלי של 512 בייטים.
414 URI יותר מדי
הכותרת של שאילתת ה-GET הייתה גדולה מדי או שבפרמטר dns הייתה הודעת DNS בקידוד Base64Url שחורגת מגודל ההודעה המקסימלי של 512 בייטים.
415 סוג מדיה לא נתמך
גוף ה-POST לא הכילו כותרת Content-Type מסוג application/dns-message.
429 יותר מדי בקשות
הלקוח שלח יותר מדי בקשות בפרק זמן נתון. הלקוחות אמורים להפסיק לשלוח בקשות עד לזמן שצוין בכותרת Retry-After (זמן יחסי בשניות).
500 שגיאת שרת פנימית
שגיאות DoH פנימיות של DNS ציבורי של Google.
501 לא יושם
מוטמעות רק שיטות GET ו-POST. שיטות אחרות מקבלות את השגיאה הזו.
502 Bad Gateway
לשירות DoH לא הייתה אפשרות ליצור קשר עם מקודדי ה-DNS הציבורי של Google.
במקרה של תגובת 502, למרות שניסיון חוזר בכתובת DNS ציבורית חלופית של Google יכול לעזור, כדאי לנסות להשתמש בשירות DoH אחר כדי לנסות שירות DoH או לעבור ל-UDP רגיל או ל-TCP DNS ב-8.8.8.8.
היתרונות של DoH
לשימוש ב-HTTPS, ולא רק בהצפנת TLS, יש כמה יתרונות שימושיים:
ממשקי API של HTTPS עם תמיכה רחבה ועם תמיכה נרחבת מפשטים את ההטמעה של Google Public DNS עצמה וגם של לקוחות פוטנציאליים.
באמצעות שירות HTTPS, אפליקציות אינטרנט יכולות לגשת לכל הסוגים של רשומות DNS,
וכך נמנעת המגבלות של ממשקי ה-API הקיימים של ה-DNS או הדפדפן, שתומכים בדרך כלל רק בחיפושים מסוג 'ממארח לכתובת'.
לקוחות שמטמיעים תמיכה ב-HTTPS שמבוסס על QUIC UDP יכולים למנוע בעיות כמו חסימה מסוג ראשי (head-of-line) שעשויות להתרחש במהלך שימוש בתעבורה ב-TCP.
שיטות מומלצות בנושא פרטיות ל-DoH
למפתחים של אפליקציות DoH מומלץ ליישם את השיטות המומלצות לשמירה על פרטיות המפורטות ב-RFC 8484 ומורחבות בהמשך:
הגבלת השימוש בכותרות HTTP
כותרות HTTP חושפות מידע על הטמעת DoH של הלקוח, ואפשר להשתמש בהן כדי להפוך לקוחות לאנונימיים. כותרות כמו Cookie, User-Agent ו-Accept-Language הן הגורם הבעייתי ביותר, אבל אפילו קבוצות הכותרות שנשלחות יכולות לחשוף את העסק. כדי למזער את הסיכון, כדאי לשלוח רק את כותרות ה-HTTP שנדרשות עבור DoH: Host, Content-Type (ל-POST) ובמידת הצורך, Accept.
צריך לכלול את ה-User-Agent בכל גרסה של פיתוח או בדיקה.
שימוש באפשרויות המרווח הפנימי של EDNS
עליכם לפעול לפי ההנחיות ב-RFC 8467 לגבי שימוש באפשרויות המרווח הפנימי של EDNS כדי להציב שאילתות DoH באורכים נפוצים כדי להגן מפני ניתוח תעבורת הנתונים. אפשר גם להשתמש במרווח פנימי של HTTP/2, אבל בניגוד למרווח פנימי של EDNS, לא ייווצר מרווח פנימי בתגובות משרתי DoH.
שימוש ב-RFC 8484 POST רק לאפליקציות רגישות של פרטיות או למצבי דפדפן
השימוש ב-POST לשאילתות של DoH מפחית את היכולת לשמור תשובות במטמון, ויכול
להאריך את זמן האחזור של ה-DNS, כך שבאופן כללי לא מומלץ להשתמש בו. עם זאת, צמצום של השמירה במטמון הוא כנראה רצוי עבור אפליקציות שרגישות לפרטיות, ועשויות להגן מפני התקפות תזמון של אפליקציות אינטרנט שמנסות לזהות את הדומיינים שהמשתמש ביקר בהם לאחרונה.
בעיות
כדי לדווח על באג או לבקש תכונה חדשה, צריך לפתוח בעיה ב-DoH.
[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)."]]
