NXDOMAIN דרך VPN אינו מעיד על נפילת המנהרה

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

מה התשובה באמת מוכיחה

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

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

המיתוס: שם פרטי חסר אומר שהמנהרה נכשלה

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

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

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

שאלו את הפותר הנכון עם השם הנכון

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

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

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

מטמון שלילי מסביר את העיכוב אחרי תיקון

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

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

הפרידו את השם מהמסלול

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

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