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