DNSSEC מול VPN: מה מסתיר את שאילתות ה-DNS שלכם?

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

שלוש טענות שמתמזגות לאחת

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

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

תעבורת יישומים היא מקרה רביעי: HTTPS מגן ומאמת את החליפין ברשת בין הלקוח שלכם לאתר, ואף שכבת DNS לא מחליפה אותו.

מה אימות חתימות יכול לעשות ומה לא

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

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

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

מאין באמת מגיעה הסודיות

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

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

השילוב שאנשים באמת רוצים הוא בדרך כלל שלושה דברים בבת אחת: אימות פועל, הובלה מוצפנת אל פותר שהם בחרו, ו-TLS של היישום ביעד. כל אחד מהם עצמאי, ודילוג על אחד משאיר פער אחר.

בדקו אימות והובלה בנפרד

שני מבחנים פותרים את רוב הבלבול. הראשון שואל אם הפותר אימת את התשובה; השני שואל אם ההובלה הייתה מוגנת. הם נכשלים בדרכים שונות ואף אחד מהם לא מרמז על האחר.

הפקודות האלה מדפיסות את הדגלים משאילתה מאמתת, חוזרות על השאילתה עם בדיקה כבויה, ומריצות אימות מקומי עם delv:

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

תשובה עם דגל הנתונים המאומתים וחתימה נוכחת מראה אימות בפותר הזה. כשל אימות עם delv מראה שרשרת שבורה במקום כלשהו בין האזור לעוגן האמון, וזה בעיית פרסום ולא בעיית מנהרה. פסק זמן בלי שום דגלים הוא בעיית הובלה או נגישות, והתייחסות אליו ככשל חתימה שולחת אתכם לשכבה הלא נכונה.

מה לעשות כשה-VPN שובר שאילתות

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

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