DNS של VPN שגוי? ייתכן ששרת סמכותי אחד מיושן

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

התסמין משתנה עם הפותר

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

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

הבדיקה המבחינה היא שאילתה ישירה לכל שרת מפורסם.

שאלו כל סמכות ישירות

התחילו מההאצלה ולא מרשימה שאתם זוכרים. שאלו את ההורה על קבוצת ה-NS, ואז שאלו כל שם בקבוצה הזו על הרשומה שמעניינת אתכם. שתי שאילתות לאותו שם אצל סמכויות שונות אומרות לכם מיד אם האזור עקבי.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

עשו אותו דבר לרשומות ה-NS בקצה האזור, כי האצלת ההורה וקבוצת ה-NS של האזור עצמו יכולות לחלוק לאחר מעבר. מספרי סידור ב-SOA הם הדבר הבא להשוואה, ושרת משני שנשאר הרחק מאחור הוא בעיית העברה ולא בעיית תשובה.

הריצו את השאילתות האלה מהרשת שנכשלת, לא רק מהשולחן שלכם.

הפרידו תצוגות מכוונות מתצוגות שבורות

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

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

שרת שעונה SERVFAIL קל יותר לאבחון מזה שעונה בביטחון ובטעות.

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

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

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

החלפת הפותר במחשב נייד מתקנת את אותו מחשב נייד ושום דבר אחר.

תקנו את האזור, לא את הפותר

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

לאחר מכן הריצו שוב את השאילתות הישירות משתי הרשתות והמתינו לפקיעת ה-TTL של הרשומה ששיניתם.

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