DNS-over-HTTPS (DoH)

ב-Google Public DNS יש שני ממשקי API נפרדים של DoH בנקודות הקצה האלה:

• https://dns.google/dns-query – RFC 8484 (GET ו-POST)
• https://dns.google/resolve? – JSON API (GET)

בדף סקירה כללית של העברות מאובטחות תוכלו למצוא curl דוגמאות לשורת הפקודה לשימוש בממשקי ה-API וגם בפרטים של TLS ושל תכונות אחרות המשותפות ל-DNS over TLS (DoT) ול-DoH.

אפשר להשתמש ב-DoH גם בשירות IPv6 הציבורי של Google שמיועד ל-IPv6 בלבד.

ב-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.