יומני רזולבר DNS לעומת יומני חיבור VPN: מה כל אחד מחזיק
רזולבר רושם שמות שהתבקש לענות עליהם; VPN רושם אירועי מנהרה מהמימוש שלו עצמו. מדיניות שמירה אחת אינה מכסה את האחרת.
יומן רזולבר DNS ויומן חיבור VPN הם שניהם רשומות רשת, שניהם שימושיים ואינם ניתנים להחלפה. הרזולבר מקבל שמות שהתבקש לענות עליהם. נקודת הקצה של ה-VPN מטפלת בחיבורי מנהרה ורושמת את מה שהמימוש שלה בחר לרשום עליהם. הם יכולים לשבת באותו בניין, להיות מופעלים על ידי אותו צוות ולהיות מכוסים על ידי אותה הודעת פרטיות, ובכל זאת הם מתארים אירועים שונים עם מזהים שונים ושמירה שונה. קריאה של האחד כאילו היה האחר היא הדרך שבה חקירות יוצאות מהפסים.
שני יומנים, שני אירועים
רשומה ברזולבר עונה על שאלה בנוגע למתן שמות: הלקוח הזה ביקש את השם הזה בזמן הזה, והתשובה הייתה זו. רשומה ב-VPN עונה על שאלה בנוגע לקישוריות: העמית הזה הקים או איבד מנהרה, הוקצתה לו הכתובת הזו, והוא העביר בערך כמות כזו של נתונים לפני שנעלם. אף אחד מהם אינו רשומה של מה שהמשתמש עשה בתוך הפעלת HTTPS, ואף אחד אינו מחליף את השני.
להבחנה יש השלכה מעשית על הבטחות. אמירה שספק VPN אינו רושם פעילות מנהרה אינה אומרת דבר על הרזולבר שהוא מספק, ומדיניות השמירה של רזולבר אינה אומרת דבר על מי שהתחבר למנהרה. כל טענה שייכת למפעיל שלה ולמערכת שלה.
עקבו אחר השאילתה לפני קריאת כל אחד מהיומנים
שאילתה מגיעה לרזולבר רק אם המסלול באמת שואל אותו. יישום יכול להשתמש ברזולבר של מערכת ההפעלה, להריץ לקוח DNS מוצפן משלו, או לקרוא תשובה שמורה ולא לשלוח דבר. לכן יומן רזולבר שלא מראה דבר אינו ראיה לכך ששם מעולם לא שימש; היא ראיה לכך שהרזולבר הזה לא נשאל.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerהפקודה האחרונה קוראת את היומן של הרזולבר המקומי עצמו, וזה אינו אותו דבר כמו היומן של השרת במעלה הזרם. אם השאילתות שלך יוצאות דרך DNS over HTTPS לספק, ייתכן שהסטוב המקומי לא יראה דבר בעוד שלספק יש את הרשומה המלאה, והספק הוא מפעיל אחר עם מדיניות אחרת.
מה כל רשומה יכולה להראות ומה לא
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
חיבור ביניהם הוא העבודה האמיתית, וחיבור ביניהם אינו תמיד אפשרי. רזולבר שרושם כתובות לקוח ניתן להשוות ל-VPN שמקצה כתובות ממאגר מוכר, וההשוואה הזו מייצרת קשר סביר בין שם שנשאל לבין מנהרה, והוא נשאר קשר בין שתי רשומות ולא רשומה של אדם.
DNS מוצפן משנה את התעבורה, לא את הנראות בנקודת הקצה. הרזולבר עדיין מקבל את השאלה שהוא עונה עליה, כפי ש-RFC 8484 מבהיר, והשמירה באותו רזולבר היא החלטת מדיניות ולא תכונה של הפרוטוקול.
היכן ש-DNS מפוצל ומטמונים מבלבלים את הסיפור
מספר רזולברים הוא מצב רגיל. תכנון של DNS מפוצל שולח שמות פנימיים לשרת פנימי ואת כל השאר לשרת ציבורי, כך שחקירה אחת יכולה לכלול שני יומנים שלא נועדו מעולם להצטרף ושני כיווני שמירה שלא נועדו מעולם להיות מושווים. לראות שאילתות בשניהם הוא ראיה שהתכנון עובד, לא ראיה לדליפה.
מטמונים חותכים בכיוון השני. שם פופולרי עשוי להיענות מהמטמון במשך שעות, כך שהרשומה של הרזולבר מראה את השאילתה הראשונה ואחר כך דבר לא, בעוד היישום של המשתמש ממשיך לפתור את אותו שם בשמחה. היעדר רשומות אחרי זמן מסוים אינו אומר שאיש לא השתמש בשם אחרי אותו זמן.
תעבורת רקע היא העיוות השלישי. טלפון שפותר שם טלמטריה בעת האתחול, דפדפן שפותר דומיין של הצעת חיפוש, ומעדכן שמדווח בכל שעה מופיעים כולם ביומן רזולבר לצד השם שבאמת אכפת לך ממנו. נפח ביומן הזה אינו תשומת לב, וספירת שאילתות אינה ספירת ביקורים. יומן רזולבר הוא רשומה של שאלות, ושאלות זולות לייצור.
שאלו את שאלות השמירה בנפרד
לכל מערכת, שאלו שלוש שאלות: מי אוסף, מה נאסף, וכמה זמן הוא נשמר. אחר כך שאלו מי יכול לקרוא אותו ובאיזה תהליך. הדיון ב-RFC 8484 על DNS over HTTPS הוא תזכורת טובה לכך שתעבורה מוצפנת אינה מסירה את נקודת הקצה, והתיעוד של המפעיל עצמו הוא האמירה היחידה שאפשר לסמוך עליה בנוגע למה שנקודת הקצה הזו שומרת.
כשטענה על פרטיות נאמרת על “ה-VPN”, פצלו אותה לרכיבים לפני שאתם מקבלים אותה: מפעיל המנהרה, הרזולבר שהמנהרה מספקת, כל רזולבר במעלה הזרם שהשאילתות האלה מגיעות אליו, והיישומים במכשיר. לכל אחד יש תשובה משלו, וטענה שנכונה לאחד מושמעת שוב ושוב כאילו כיסתה את כל הארבעה.
לפתרון תקלות, השתמשו באותו פיצול. שאלו איזה יישום ערך את השאילתה ואיזה רזולבר ענה עליה, ואז הסתכלו ביומן שבאמת מחזיק באירוע הזה. ניחוש מהיומן האחר חוסך דקה ועולה אחר צהריים.