DNS דרך HTTPS: מה זה וכיצד הוא מגן על השאילתות שלך

מדריך אלפא » מחשוב » DNS דרך HTTPS: מה זה וכיצד הוא מגן על השאילתות שלך

כשאתה מקליד כתובת אינטרנט, יש רכיב שפועל מאחורי הקלעים כדי להבטיח שתגיע לאתר הנכון: מערכת שמות המתחם (DNS). DNS מתרגם שמות שקל לזכור לכתובות IP שמחשבים יכולים להבין. זה נוח, כן, אבל במשך שנים הוא פעל עם פגיעות משמעותית: שאילתות אלו עברו ללא הצפנה. זו הסיבה ש-DNS דרך HTTPS, המכונה גם DoH, הפך להיות כל כך בולט - שכבת הגנה נוספת שמקשה על ספק שירותי האינטרנט שלך לעקוב אחר הדומיינים שאתה מבקר בהם.

חשוב להבהיר דבר אחד כבר מההתחלה: DoH משפר את הפרטיות של שאילתות DNS, אבל זה לא VPN, וגם לא הופך את כל החיבור שלך למנהרה סודית . לאורך מאמר זה, נחקור בדיוק מה זה, למה זה הפך פופולרי, איך להפעיל אותו ב-Chrome, Edge ו-Firefox, היתרונות והחסרונות שלו, במה זה שונה מ-DNS על פני TLS ו-VPN, ומה מידת המגבלות הטכניות והמעשיות שלו.

מהו DNS ומדוע המערכת המסורתית לוכדת?

שרתי DNS הם אחד מאותם רכיבים שכמעט אף אחד לא מסתכל עליהם, אך הם מהווים בסיס לחלק גדול מהגלישה המקוונת. תפקידם הוא לקשר שם דומיין לכתובת ה-IP של השרת המתאים . כשאתה מבקר באתר אינטרנט, המחשב שלך לא מבין אותיות: הוא זקוק לכתובת IP כדי לדעת לאיזו מכונה להתחבר. נתבים רבים מגיעים עם שרתי DNS שכבר הוגדרו על ידי ספק שירותי האינטרנט, מה שהופך את התהליך לנוח, אם כי הוא גם משאיר עקבות גלויים עבור מי ששולט בתשתית זו.

הבעיה הבסיסית היא ששאילתות DNS מסורתיות נעשות בטקסט רגיל וללא הגנה . זה פותח את הדלת להאזנות סתר, התקפות אדם-באמצע ומניפולציה של התגובה. ספק שירותי אינטרנט יכול ללמוד אילו דומיינים אתה מבצע שאילתה ומתי; תוקף ברשת משותפת יכול לנסות ליירט את הבקשה ולהחזיר תגובה הונאה. טכניקה זו ידועה בשם חטיפת DNS ויכולה בסופו של דבר להוביל אותך לדף מזויף, פרסום לא רצוי או אתר שנועד לגנוב נתונים. ממשלות וספקי שירותי אינטרנט ניצלו בעבר חולשות אלו כדי ליישם צנזורה, לחסום דומיינים או להציג פרסום נוסף.

• האזנה פסיבית: מישהו צופה בשאלות ומסיק אילו שירותים או אתרים אתה מבקר לעתים קרובות.
• איש באמצע: התקשורת יורטת והתגובה משתנה כדי להתחזות לשרת.
• חסימה וסינון: זה מונע את הרזולוציה של דומיינים מסוימים על מנת לשלוט בגישה לתוכן.

DNS דרך HTTPS: הצפנת השאילתה כך שהיא לא תהיה גלויה לכולם.

DNS over HTTPS, או DoH, הוא פתרון הממנף את פרוטוקול HTTPS כדי להעביר שאילתות ותגובות DNS בצורה מוצפנת . במקום לשלוח בקשת DNS ברורה, המכשיר עוטף אותה בתוך חיבור מאובטח, בדרך כלל באמצעות פורט 443, אותו פורט בו משתמשים אתרים מאובטחים. זה מגן הן על השאילתה והן על התגובה, ומונע מצופה חיצוני לקרוא אותן בקלות.

כדי שזה יעבוד, שרת ה-DNS שאליו נשאלת השאילתה חייב לתמוך גם ב-DNS מבוסס דומיין (DoH ). הפעלה פשוטה של ​​אפשרות בדפדפן אינה מספיקה: הרזולוטור הנבחר חייב לעמוד בתקן זה. המפרט התפתח ועדיין נחשב לטכנולוגיה מתפתחת, אם כי מאז 2018 חברות כמו גוגל וקרן מוזילה בודקות ומשלבות אותו. בנוסף לשיפור הפרטיות, בדיקות מצביעות על כך ש-DoH יכול להפחית את זמן ההשהיה ולהפוך את השאילתות למהירות יותר, מכיוון שלא תמיד יש צורך לפתור את כל הדומיין, אלא רק את החלק המינימלי הנדרש.

יתרונות DoH: יותר פרטיות, פחות מניפולציה וביצועים טובים יותר

היתרון הבולט ביותר הוא אבטחה. מכיוון שהן עוברות מוצפן, קשה הרבה יותר לרגל או לשנות שאילתות DNS . זה מסבך התקפות "אדם באמצע", מפחית את החשיפה ברשתות Wi-Fi ציבוריות ומונע ממפעיל מקומי לראות בבירור אילו דומיינים אתה מבקש. מכיוון שתעבורת DoH משתמשת בפורט 443, היא משתלבת עם חיבורי HTTPS אחרים וקשה להבחין בינה לבין ביקור רגיל באינטרנט.

ישנן גם סיבות לביצועים. DoH יכול להפחית את השהייה ולהאיץ את תקשורת ה-DNS הודות לשינויים באופן שבו שמות נפתרו וניצול טוב יותר של המטמון. לדוגמה, שיטת GET של חלק ממשקי ה-APIs נועדה להישמר במטמון בצורה יעילה יותר. בפועל, זה יכול להתבטא בגלישה מהירה מעט יותר, אם כי זה לא תרופת קסם וההבדל לא תמיד מורגש. יתר על כן, מכיוון שהוא מיושם בדפדפן, המשתמש אינו צריך לחכות שספק שירותי האינטרנט שלו יפעיל אותו.

חסרונות ודיונים: כאשר הצפנה מסבכת את החיים

לא כולם רואים בחיוב הצפנה מבוססת דומיין (DoH). אותה הצפנה שמגנה על המשתמש גם מקשה על ניטור הרשת . תוכנות בקרת הורים רבות מסתמכות על בדיקת שאילתות DNS כדי לקבוע לאילו אתרים ילדים מנסים לגשת; עם DoH, משימה זו הופכת למסובכת הרבה יותר ואף עשויה להיות בלתי אפשרית. מצב דומה קיים עבור מנהלי רשת ארגוניים, שמאבדים את הנראות לדומיינים הנבדקים ואינם יכולים לאכוף כללים מסוימים באותה קלות.

ספקי אינטרנט גם מאבדים את היכולת לנטר גישה ולחסום דומיינים ספציפיים לפי בקשת מוסד. זה יוצר ויכוח לגיטימי: יש הרואים בכך ניצחון לפרטיות, בעוד שאחרים רואים בכך בעיית בקרה וניהול . במקרה של DoT, הוא סופג ביקורת גם על השימוש בפורט מזוהה משלו, המאפשר זיהוי של שאילתות DNS גם מבלי לדעת בדיוק מה נשאל. DoH נמנעת מאותת ברור זה על ידי הסוואת עצמו בתוך תעבורת HTTPS, אך בתמורה, מנהלי הרשת נותרים עם פחות כלים לניהול התקשורת שלהם.

כיצד להפעיל DoH בכרום, אדג' ופיירפוקס

הפעלת מערכת שמות תחומים (DNS) בדפדפן מודרני היא בדרך כלל פשוטה, במיוחד אם הוא מבוסס על Chromium או Firefox. האפשרות קיימת, אם כי במקרים מסוימים היא מוסתרת בתפריטי הגדרות מתקדמות . לפני שינוי כלשהו, ​​חשוב להבין שהדפדפן מגן רק על השאילתות שלו עצמו: יישומים אחרים במכשיר עשויים להמשיך להשתמש במערכת DNS שונה אם היא לא מוגדרת גם ברמת המערכת.

Google Chrome

בכרום, הדרך המהירה היא להקליד chrome://flags/#dns-over-https בשורת הכתובת. זה מוביל אותך ישירות לדגלים או לתכונות הניסיוניות של Chrome.תראה אפשרות בשם חיפושי DNS מאובטחים נבחרים; לחץ על התפריט הנפתח שאומר ברירת מחדל ובחר מופעל. לאחר מכן תצטרך להפעיל מחדש את הדפדפן כדי שהשינוי ייכנס לתוקף.

אדג מיקרוסופט

ב-Edge המבוסס על Chromium, התהליך כמעט זהה. פתח את הדפדפן שלך והקלד edge://flags/#dns-over-https בסרגל החיפושתזין את דגלי Edge ותופיע אותה אפשרות חיפושי DNS מאובטחים. שנה את ברירת המחדל לאפשרות מופעל והפעל מחדש את הדפדפן כשתתבקש.

Mozilla Firefox

בפיירפוקס, אינך צריך לעבור ל"דגלים". לחץ על כפתור התפריט בפינה הימנית העליונה ובחר "אפשרויות" . במקטע "כללי", גלל לתחתית ולחץ על "הגדרות רשת". בחלון שנפתח, סמן את התיבה שליד "הפעל DNS דרך HTTPS". לאחר מכן תוכל לבחור מבין ספקים כמו Cloudflare ו-NextDNS כדי לבצע הצפנה דרך HTTPS.

DNS מעל TLS (DoT): הנתיב המוצפן השני

DNS over TLS, או DoT, היא דרך נוספת להגן על שאילתות DNS. במקום להשתמש ב-HTTPS, הוא משתמש ב-TLS דרך חיבור TCP ופורט סטנדרטי, 853. TLS הוא אותו בסיס אבטחה כמו HTTPS, כך שהרעיון דומה: ליצור מנהרה מוצפנת שבה רק שני המשתתפים יכולים לפענח ולעבד את המידע. זה מקשה על התקפות man-in-the-middle ומונע מצד שלישי לקרוא או לתמרן את השאילתה.

ל-DotT יש יתרונות, במיוחד בהשוואה ל-DNS מסורתי, שאינו מציע אמצעי אבטחה. הצפנה מונעת מפושעי סייבר ליירט בקשות וגם פוגעת באמצעי צנזורה מסוימים . עם זאת, היא דורשת תאימות הן מהלקוח והן מהשרת. מספר ספקים מציעים שרתים תואמים, אך השימוש בה במחשב שולחני או נייד דורש בדרך כלל התקנת תוכנה נוספת; באנדרואיד המודרני, לפחות מאז אנדרואיד 9, היא כבר משולבת. קיימים פתרונות עבור Windows ו-Linux, אם כי הם לא תמיד שקופים כפי שאפשר היה לרצות.

בין החסרונות, מומחים רבים להגנת מידע מבקרים את DoT על השימוש בפורט יחיד וניתן לזיהוי. אמנם בלתי אפשרי לדעת לאיזה אתר אינטרנט ניגשים, אך ניתן לזהות תעבורת DNS . עבור חלק ממנהלי הרשת, זה שימושי משום שזה מאפשר להם לשמור על סקירה כללית של מה שקורה; עבור אחרים, זהו אות שהם מעדיפים להסתיר. יתר על כן, DoT עדיין אינו נפוץ כמו DNS מסורתי, והאימוץ שלו בצד השרת מוגבל. ישנם חששות שכמה חברות ירכזו יותר ויותר שאילתות DNS, דבר שעלול ליצור מעין מונופול בינלאומי.

DoH לעומת DoT: שתי דרכים להגן על אותו הדבר

ההבדל העיקרי בין DoH ל-DoT טמון בפורט ובאופן שבו התעבורה מוסווית. DoT משתמש בפורט משלו, 853, בעוד ש-DoH משתמש ב-443 ומשתלב עם חיבורי HTTPS רגילים . הבדל זה, שנראה קטן, עורר ויכוח ניכר. מנקודת מבט של פרטיות, חוסר ההבחנה בין שאילתות DNS לתעבורה אחרת הוא יתרון: אם הן אינן מזוהות, לא ניתן לתמרן אותן באותה קלות. מנקודת מבט של ניהול רשת, לעומת זאת, אובדת שליטה, וקשה יותר ליישם מדיניות אבטחה או סינון.

בליבתה, ישנם שני חזונות. IETF, הקונסורציום שמפתח סטנדרטים רבים באינטרנט, עומד מאחורי DoT , בעוד שגוגל וקרן מוזילה קידמו מאוד את DoH. אלו אינן טכנולוגיות מנוגדות, אך הן מייצגות דרכים שונות להבנת פרטיות, נראות רשת ותפקידם של מתווכים. הבחירה בין אחת לשנייה תלויה במה שצריך להגן ובמי צריך לנהל את הרשת.

DoH לעומת VPN: זה מגן על השאלה, לא על כל המסע

משרד ההגנה וה-VPN עולים לעתים קרובות באותן שיחות על פרטיות, אך הם לא עושים את אותו הדבר. משרד ההגנה מגן על שאילתת השם; VPN מגן על הנתיב שהנתונים שלך עוברים . הדרך הפשוטה ביותר להבין זאת היא לחשוב על משרד ההגנה ששם שאלה רגישה במעטפה סגורה, בעוד ש-VPN גורם לכל המסע לעבור דרך מנהרה פרטית לפני שהוא חוזר לכביש הציבורי. שניהם יכולים לשפר את הפרטיות, אך רק אחד מהם נועד לכסות באופן מקיף את תעבורת הטלפונים, הטאבלטים והמחשבים.

מה עושה DNS לפני שאתר נטען?

לפני שהדפדפן שלך יוכל לטעון אתר אינטרנט, המכשיר שלך צריך לדעת את מיקומו. DNS פועל כמו ספר טלפונים, ומתרגם שם אתר אינטרנט לכתובת IP . זה קורה כל הזמן: כשאתה פותח דף, מפעיל אפליקציה, מעדכן את האימייל שלך או מנגן סרטון. ברוב הפעמים זה קורה בשקט, ואתה לא שם לב לזה, וזה נהדר לנוחות, אבל זה גם מקל על התעלמות מזה כבעיית פרטיות. שאילתות DNS מסורתיות אינן מוצפנות, כך שספק שירותי האינטרנט שלך, המעסיק שלך, בית הספר שלך, Wi-Fi של בית קפה או רשת מלון יכולים לראות לאילו דומיינים המכשיר שלך מנסה להגיע. הם לא רואים את התוכן המלא של דף HTTPS, אבל הם כן מקבלים סקירה די חושפנית של הפעילות שלך.

שאילתת DNS לא חושפת כל עמוד שצפית בו או כל מה שאתה מקליד בטופס, אבל רשימת דומיינים יכולה לחשוף הרגלים, תחומי עניין, כלי עבודה, מחקר בריאותי או שירותים פיננסיים . זו הסיבה ש-DNS מוצפן הפך לתכונת פרטיות שימושית. הוא לא חושף הכל, אבל הוא חושף יותר ממה שרבים מבינים.

מה משרד הביטחון מסתיר ומה הוא חושף?

משרד התקשורת של ארה"ב שולח שאילתות DNS דרך HTTPS, אותו פרוטוקול מוצפן המשמש אתרים מאובטחים. הבקשה משאירה את המכשיר שלך מוצפן ומגיעה לרזולוטור התומך בתקן . ברשת Wi-Fi ציבורית, הדבר עלול להקשות על מפעיל הרשת לקרוא את השאילתות שלך בטעות. אם ספק האינטרנט שלך מנהל DNS, מעבר לרזולוטור של משרד התקשורת של ארה"ב יכול למנוע ממנו לראות שאילתות אלו בדרך הרגילה. יתר על כן, אם רשת מבצעת מניפולציה בתוצאות רזולוציית שמות, DNS מוצפן יכול להפחית צורות מסוימות של מניפולציה.

כעת, DoH מסתיר את השאילתה, לא את כל השיחה. זה אולי ימנע מחלק מהצופים לראות בבירור את חיפוש הדומיין, אבל זה לא הופך את כל חיבור האינטרנט שלך למנהרה מוצפנת . ברגע שהמכשיר יודע את כתובת ה-IP, שאר החיבור ימשיך בנתיב הרגיל שלו, אלא אם כן כלי פרטיות אחר משנה מסלול זה. DoH לא מסתיר את כתובת ה-IP האמיתית שלך מאתרים, אפליקציות או שירותים שאתה מתחבר אליהם, וגם לא גורם לך להיראות כאילו אתה נמצא בעיר או במדינה אחרת. אם אתה מתחבר לחשבון, השירות יודע שזה אתה. אם לדפדפן יש קובצי Cookie, פעילויות שמורות, מזהי פרסום או טביעת אצבע ניתנת לזיהוי, DoH לא מוחק את האותות האלה.

זה גם לא מגן על כל אפליקציה אלא אם כן היא מוגדרת ברמת המערכת והאפליקציה מכבדת הגדרה זו. דפדפן אחד עשוי להשתמש ב-DNS מאובטח בעוד שאפליקציה אחרת באותו מכשיר משתמשת בנתיב DNS שונה . אפליקציות מסוימות מנהלות את הרשת שלהן ולא תמיד מתאימות להגדרות המערכת או הדפדפן. לכן, DoH יכול ליצור תחושה כוזבת של הגנה מלאה: הוא משפר את הפרטיות של שאילתות DNS, אך הוא לא מגן על העברות קבצים, תעבורת הודעות, שיחות וידאו, חיבורי משחקים, סנכרון רקע או יישומי סטרימינג כפי ש-VPN היה מגן.

על מה VPN מגן ומה הוא לא יכול להסתיר?

VPN מגן על חלק אחר במסע שלך. הוא יוצר מנהרה מוצפנת בין המכשיר שלך לשרת VPN, ומנתב את תעבורת האינטרנט שלך דרך שרת זה . ספק שירותי האינטרנט שלך או רשת ה-Wi-Fi המקומית רואים חיבור מוצפן לשרת ה-VPN, ולא תצוגה ברורה של כל אתר ושירות שאתה מתחבר אליהם. בנוסף, ה-VPN משנה את כתובת ה-IP הציבורית שאתרים ואפליקציות רואים: במקום כתובת ה-IP של ספק האינטרנט הביתי או הסלולרי שלך, היעד רואה את כתובת ה-IP של שרת ה-VPN. זה יכול להפחית מעקב מבוסס מיקום, לעזור לך לעקוף פרופילים מסוימים של ספקי אינטרנט ולהפוך את השימוש ב-Wi-Fi ציבורי לבטוח יותר.

VPN מקיף יכול להגן על דפדפנים, אפליקציות סטרימינג, לקוחות דוא"ל, כלי גיבוי ענן, אפליקציות העברת הודעות, משחקים ושירותי רקע. הוא יכול גם לנתב בקשות DNS דרך המנהרה המוצפנת כאשר הוא מוגדר כראוי , ולכן מומלץ להריץ בדיקת דליפת DNS. עם זאת, VPN אינו קסם. אם אתם מתחברים לרשת חברתית, חשבון דוא"ל, שירות סטרימינג או חנות מקוונת, שירות זה עדיין יודע מי אתם. הוא יכול להסתיר את כתובת ה-IP המקורית שלכם, אך הוא לא הופך את פרטי ההתחברות שלכם לאנונימיים. אותו הדבר חל על כל דבר שאתם שולחים ישירות: שמכם, כתובת הדוא"ל שלכם, פרטי התשלום, כתובת המשלוח, תמונות או הודעות.

קובצי Cookie וטביעת אצבע בדפדפן עדיין חשובים. אפליקציות יכולות ליצור בעיות דומות באמצעות מזהי פרסום, הרשאות, גישה למיקום, סריקת Bluetooth, שמות Wi-Fi בקרבת מקום וכלי סריקה. תוכנה זדונית היא מכשול קשה נוסף מכיוון שהיא יכולה ללכוד נתונים עוד לפני שהם מגיעים למנהרת ה-VPN . בקיצור, VPN מסתיר ומצפין הרבה פעילות, אך הוא לא מסווה כל טביעת אצבע דיגיטלית.

ניתן להשתמש בו זמנית ב-DoH וב-VPN

כן, ניתן לשלב ביניהם, אך ההגדרה האידיאלית תלויה באופן שבו המכשיר, הדפדפן ואפליקציית ה-VPN מטפלים ב-DNS. במקרים רבים, הפתרון הפשוט ביותר הוא לאפשר ל-VPN לטפל ב-DNS . אפליקציה טובה צריכה לשלוח שאילתות DNS דרך המנהרה המוצפנת כך שספק האינטרנט שלך לא יקבל אותן ישירות. בדרך זו, אתה מקבל פרטיות DNS כחלק מחיבור ה-VPN מבלי שתצטרך להתאים את הגדרות הדפדפן שלך בנפרד.

הבעיה מתעוררת כאשר הדפדפן משתמש בתצורת רשות דומיין (DoH) משלו בזמן שה-VPN מנסה לנהל את ה-DNS ברמת המערכת. שום דבר לא יכול להשתבש, אבל בלבול אכן מתרחש : אתם עשויים לחשוב שכל השאילתות עוברות דרך ה-VPN, אבל במציאות, הדפדפן שולח חלק מהן בעצמו לפתרון אחר. כאן בדיקת דליפת DNS שימושית. אם, לאחר התחברות ל-VPN, אתם רואים את שרתי ה-DNS של ספק האינטרנט שלכם, משהו לא עובד כצפוי; אם אתם רואים שרתים המשויכים ל-VPN, סביר יותר שהתצורה עובדת כראוי.

מתי DoH מספיק ומתי VPN מומלץ?

DoH יכול להספיק כאשר הדאגה העיקרית שלך היא הפרטיות הבסיסית של שאילתות DNS בדפדפן שלך. ברשת ביתית מהימנה, הפעלת DNS מאובטח מפחיתה את החשיפה לטקסט רגיל מבלי שתצטרך לשנות את מיקומך או לאבטח את כל היישומים שלך . זה גם שימושי ברשתות שבהן סינון או מניפולציה של DNS מהווים דאגה, מכיוון שנסיעה דרך HTTPS מקשה על בדיקה או שינוי בקלות. זה לא אומר שזה עוקף את כל ההגבלות או עמיד בפני צנזורה, אבל זה שיפור משמעותי לעומת DNS לא מוצפן. יתר על כן, זה קל משקל: אינך צריך לבחור שרת VPN או לשנות באופן משמעותי את הניתוב שלך, ובדרך כלל לא תבחין בהשפעה משמעותית על המהירות.

VPN הוא הגיוני ביותר כשרוצים הגנה על כל המכשיר, לא רק חיפושי DNS. זה כולל שדות תעופה, מלונות, בתי ספר, חללי עבודה משותפים, בתי קפה ומקומות לינה להשכרה . ברשתות משותפות, אינכם יודעים מי שולט בנתב, מי עוד מחובר, או אם מישהו מנסה ליירט תעבורה. VPN עוזר גם כשאינכם רוצים שספק האינטרנט שלכם יבנה פרופיל של דפוסי הגלישה שלכם: למרות ש-HTTPS מגן על תוכן הדף, מטא-נתונים של הרשת עדיין יכולים לחשוף דפוסים שימושיים. נסיעה היא דוגמה מובהקת נוספת: VPN יכול להפוך את החיבור שלכם לעקביות יותר, להגן עליכם ברשתות לא מוכרות ולגרום לאתרים לראות את מיקום שרת ה-VPN במקום את החיבור המקומי הזמני שלכם.

פרטים טכניים של ממשקי ה-API של DoH של ה-DNS הציבורי של גוגל

ה-DNS הציבורי של גוגל מציע שני ממשקי API נפרדים של DoH. אחד מיועד עבור RFC 8484 ומקבל בקשות GET ו-POST בכתובת https://dns.google/dns-query; השני הוא API של JSON התומך רק בבקשות GET בכתובת https://dns.google/resolve . ישנו גם ממשק אינטרנט בכתובת https://dns.google/ המציג תוצאות JSON בדפדפן, אך הוא אינו מיישם API מלא. אין לבלבל ממשק זה עם כתובות URL של ה-API או עם https://dns.google/query. השירות אינו תומך בכתובות URL של HTTP לא מאובטחות, ו-DoH נתמך גם על ידי שירות DNS64 הציבורי של גוגל, אם כי במקרה זה, רק IPv6 נתמך. תיעוד התעבורה המאובטחת של גוגל כולל דוגמאות של curl ופרטים על TLS, DoT ו-DoH.

שיטות HTTP זמינות

שיטת GET יכולה להפחית את ההשהיה מכיוון שהיא מאחסנת במטמון בצורה יעילה יותר. בקשות GET ב-RFC 8484 חייבות לכלול פרמטר `?dns=` עם הודעת DNS מקודדת ב-Base64Url , וזוהי השיטה היחידה הנתמכת על ידי ממשק ה-API של JSON. שיטת POST זמינה גם היא רק ב-RFC 8484 ומשתמשת בהודעת DNS בינארית עם `application/dns-message` הן בגוף הבקשה והן בגוף התגובה. שיטת HEAD אינה נתמכת כרגע ומחזירה שגיאת 400 Bad Request. שיטות אחרות מחזירות שגיאות 501 Not Implemented.

קודי סטטוס ושגיאות

ה-API מחזיר מספר קודי HTTP שכדאי להכיר. ערך OK של 200 מציין שניתוח ה-HTTP והתקשורת עם פותר ה-DNS היו מוצלחים ; גוף התגובה יכול להיות תגובת DNS בינארית או JSON, בהתאם לנקודת הקצה, לכותרת Accept ולפרמטרי GET. הערה: שגיאת HTTP יכולה להיות גם כשל DNS, לכן מומלץ לבדוק את קוד תגובת ה-DNS, לדוגמה, את השדה "Status" של ה-JSON, עבור שגיאות כגון SERVFAIL, FORMERR, REFUSED או NOTIMP.

• 301 הועבר לצמיתות: על הלקוח לנסות שוב את הבקשה בכתובת ה-URL שצוינה תחת Location. אם הבקשה המקורית הייתה POST, עליו לנסות שוב באמצעות GET רק אם כתובת ה-URL החדשה מציינת פרמטר DNS; אחרת, עליו לחזור על עצמו באמצעות POST. קודי סטטוס 302, 307 ו-308 עשויים להופיע גם כן, ולקוחות DoH חייבים לטפל בארבעתם. קודי סטטוס קבועים 301 ו-308 ניתנים לאחסון במטמון ללא הגבלת זמן. בקשות POST המקבלות קוד סטטוס 307 או 308 חייבות תמיד לעבור ניסיון חוזר באמצעות POST.
• 400 בקשה גרועה: בעיות בניתוח פרמטרי GET או הודעת בקשת DNS לא חוקית. רוב הודעות ה-DNS הלא חוקיות מקבלות דירוג 200 בסדר עם FORMERR, אך שגיאות HTTP מתרחשות עבור הודעות בלתי קריאות ללא מקטע שאלה, עם קוד QR המציין תגובה, או עם שילובי קודים חסרי הגיון.
• 413 מטען גדול מדי: גוף בקשת POST RFC 8484 חורג מגודל ההודעה המרבי של 512 בתים.
• 414 URI ארוך מדי: כותרת שאילתת ה-GET הייתה גדולה מדי או שפרמטר ה-dns חרג מ-512 בתים.
• 415 סוג מדיה לא נתמך: גוף ה-POST לא הכיל את סוג התוכן header application/dns-message.
• 429 יותר מדי בקשות: נשלחו יותר מדי בקשות בפרק זמן נתון. הלקוח חייב להמתין עד לזמן שצוין בכותרת Retry-After.
• 500 שגיאה פנימית בשרת: שגיאות פנימיות בשירות DoH.
• 501 לא יושם: רק GET ו-POST מיושמים; השאר מחזירים שגיאה זו.
• 502 שער פגום: שירות DoH לא הצליח לתקשר עם רזולוטורי DNS ציבוריים של גוגל. ניסיון כתובת אחרת עשוי לעבוד, אך תוכנית גיבוי יעילה יותר היא לנסות שירות DoH אחר או לעבור ל-DNS מסורתי באמצעות UDP או TCP בכתובת 8.8.8.8.

שיטות עבודה מומלצות לפרטיות וביצועים

מפתחי אפליקציות DoH צריכים להגביל כותרות HTTP. כותרות כגון Cookie, User-Agent ו-Accept-Language יכולות לחשוף מידע על יישום הלקוח ולתרום לדה-אנונימיזציה . מומלץ לשלוח רק את הכותרות הנחוצות ל-DoH: Host, Content-Type (עבור בקשות POST), ובמידת הצורך, Accept. יש לכלול את כותרת User-Agent בגרסאות פיתוח או בדיקה. מומלץ גם להשתמש באפשרויות ריפוד EDNS כדי לקצר שאילתות לאורכים נפוצים ולהקשות על ניתוח תעבורה. ריפוד HTTP/2 אפשרי, אך בניגוד לריפוד EDNS, הוא אינו מייצר ריפוד בתגובות שרת DoH.

יש להשתמש בשיטת POST ב-RFC 8484 רק ביישומים רגישים לפרטיות או במצבי דפדפן. שימוש ב-POST מפחית את קיבולת המטמון ויכול להגדיל את זמן ההשהיה, ולכן בדרך כלל אינו מומלץ . עם זאת, הקטנת גודל המטמון עשויה להיות מומלצת עבור יישומים המעוניינים למנוע התקפות סנכרון של אפליקציות אינטרנט שמטרתן לגלות באילו דומיינים המשתמש ביקר לאחרונה. לגישת HTTPS יש גם יתרונות מעשיים: ממשקי API של HTTPS זמינים ונתמכים באופן נרחב, מה שמפשט את היישום; שירות HTTPS מעניק לאפליקציות אינטרנט גישה לכל סוגי רשומות ה-DNS, תוך הימנעות מהמגבלות של ממשקי API של דפדפן או מערכת הפעלה המוגבלים בדרך כלל לחיפושי מארח לכתובת; ולקוחות המיישמים HTTPS מעל UDP עם QUIC יכולים להימנע מבעיות כמו חסימת ראשי שורה המתרחשות עם TCP. אם נתקלת בבאג או רוצה לבקש תכונה חדשה, עליך לדווח על הבעיה הקשורה ל-DoH דרך הערוצים הרגילים.

שאלות נפוצות לגבי DoH ו-VPN

אחת השאלות הנפוצות ביותר היא האם הגיוני להשתמש ב-DoH כשכבר משתמשים ב-VPN. זה אפשרי, אבל הגישה המעשית ביותר היא בדרך כלל לתת ל-VPN לטפל ב-DNS ולאמת באמצעות בדיקת דליפה שהשאילתות עוברות דרך הערוצים הנכונים. אם הדפדפן שולח שאילתות משלו לכיוון אחד וה-VPN לכיוון אחר, אתם עלולים להפתיע בצורה לא נעימה.

שאלה נפוצה נוספת היא האם DoH מונע מספק האינטרנט שלך לראות באילו אתרים אתה מבקר. DoH מסתיר שאילתות DNS מצופים רבים, אך הוא אינו מסיר את כל המטא-דאטה או מסתיר את כתובת ה-IP שלך : ספק האינטרנט שלך עדיין יכול לראות לאילו כתובות IP אתה מתחבר ומידע רשת אחר. להגנה רחבה יותר, אתה זקוק ל-VPN או לשילוב של שכבות פרטיות מרובות.

כדאי גם לשאול האם DomainHost (DoH) מספיק ברשת Wi-Fi ציבורית. הוא יכול לעזור למנוע ממפעיל הרשת לקרוא בקלות את שאילתות ה-DNS שלך, אך הוא אינו מגן על החיבור כולו או על התעבורה של כל היישומים . בשדות תעופה, בתי מלון ובתי קפה, שימוש ב-VPN הוא בדרך כלל מקיף יותר, במיוחד אם אינך יודע מי שולט בנתב או אם אנשים אחרים מחוברים.

מערכת שמות תחומים (DoH) ו-VPN אינם יריבים ישירים, אלא כלים עם יכולות שונות. DoH מצפין חיפוש דומיינים ומפחית את החשיפה של חלק זה של התהליך; VPN מצפין את הנתיב בין המכשיר שלך לשרת ומשנה את כתובת ה-IP שרואים יעדים . אף אחד מהם לא הופך אותך לבלתי נראה: חשבונות, קובצי Cookie, טביעות אצבע של דפדפן, הרשאות אפליקציה, תוכנות זדוניות וכל נתונים שאתה משתף ישירות עדיין יכולים לזהות אותך. אבל זה לא הופך אותם לחסרי תועלת. זה פשוט אומר שלכל אחד מהם יש את התפקיד שלו. DoH מגן על חיפוש הכתובות; VPN מגן על הרבה יותר מהנתיב שהנתונים שלך עוברים.