dnsmasq משליך תשובת DNS פרטית: האם זו הגנת rebinding?
תשובה פרטית יכולה להפעיל את הגנת ה-rebinding של dnsmasq. מצאו קודם את הדחייה ביומן, ואז הגבילו את החריגה לדומיין אחד במקום לכבות את ההגנה.
שרת ה-DNS של החברה מחזיר את הכתובת הפרטית הצפויה, ובכל זאת שאילתה דרך הפותר המפנה המקומי נכשלת. התשובה קיימת, מה ששולל את האזור שמעל ואת הרשומה עצמה. נשאר השלב שבו הפותר מחליט אם להחזיר את התשובה ללקוח. אם הפותר הזה הוא dnsmasq, הדחייה כנראה כבר ביומן.
לקבל תשובה ולבחור להחזיר אותה הם שני שלבים שונים.
השוו את אותו שם בשני הפותרים
רשמו איזה פותר האפליקציה באמת משתמשת בו, ואת שם המארח המדויק שהיא שואלת. אחר כך השוו את התוצאה מלמעלה לאירוע של הפותר המפנה עבור אותו שם. תשובה חסרה מלמעלה, תשובה שלילית מהמטמון ודחייה ביומן דורשות שלושה תיקונים שונים.
כתובת שנראית בשאילתת אבחון ישירה אינה מוכיחה שהאפליקציה קיבלה אותה במסלול הרגיל שלה. שתי השאילתות יכולות לצאת מפותרים שונים, או מאותו פותר תחת מדיניות שונה. רשמו את שתי התוצאות לפני שאתם בונים תיאוריה, כי בשלב הזה מחליפים אחת באחרת. ההשוואה היא כל האבחון.
קראו את הדחייה ולא את הסימפטום
האפשרות stop-dns-rebind ב-dnsmasq דוחה תשובות בכתובת פרטית שמגיעות מלמעלה ועומדות בתנאים, ורושמת אותן כשהיא עושה זאת. ההגנה הזאת קיימת מסיבה טובה: שם ציבורי שלפתע נפתר לכתובת פרטית הוא מתקפת ה-rebinding הקלאסית. אבל היא מצטלבת גם עם שירות פרטי במכוון, וזה המקרה שלכם.
חפשו ביומן את הדחייה לפני שתשנו משהו, כי ההודעה נוקבת בשם המנגנון.
אם אין דחייה ואין תשובה מלמעלה, הגנת ה-rebinding אינה הבעיה שלכם, וכיבויה יהיה שינוי שלא מתקן דבר ומרחיב את החשיפה. זה גרוע מהתקלה המקורית, כי הוא מסיר בקרה ומשאיר את הפגם. אשרו קודם את שורת היומן המדויקת. אחר כך החליטו.
הגבילו את החריגה לדומיין אחד
עבור דומיין מאומת, מדריך dnsmasq מציע חריגה מוגבלת לדומיין ולא מתג גלובלי.
rebind-domain-ok=corp.example
הדומיין שלמעלה הוא רק דוגמה. השתמשו בדומיין הניהולי שאתם באמת מפעילים, והבינו את היקף ההתאמה של האפשרות לפני שמחילים אותה, כי כלל סיומת מכסה יותר מהמארח האחד שבדקתם. מחולל התצורה של נתב עשוי לחשוף את אותה הגדרה דרך הבקרה שלו ולא כהוראה גולמית. שני המסלולים טובים כל עוד ההיקף המתקבל הוא זה שהתכוונתם אליו.
חריגה מזיהוי rebinding עושה בדיוק דבר אחד: היא מניחה לתשובות של אותו דומיין לעבור.
היא לא מגדירה מפנה split-DNS, לא הופכת מקור עליון בלתי נגיש לנגיש, ולא יוצרת מסלול לכתובת המוחזרת. כל אחד מאלה הוא דרישה נפרדת עם חתימת תקלה משלו, וכל אחד נכשל אחרת בלקוח.
אמתו בלי להסיר את הגבול
שאלו שוב את שם המארח דרך מסלול ההפניה, ואז התחברו לשירות עם בדיקות הזהות הרגילות שלו. חריגת DNS אינה סיבה לקבל תעודה לא צפויה, וקל לבלבל בין שתי התקלות כששתיהן מופיעות כשגיאת דפדפן. בדקו את השם ואת השירות בנפרד. רק אחד מהשניים היה אי פעם בעיית DNS.
שמרו את הסיבה לחריגה לצד התצורה, עם תאריך ואחראי.
בדקו אותה שוב כשהשירות הפרטי עובר או כשהדומיין משתנה. כיבוי ההגנה באופן גלובלי ישנה את הטיפול בתשובות לא קשורות, וישאיר בכל זאת את תקלת המסלול או השירות במקומה אם rebinding מעולם לא היה הסיבה.