איך לבדוק את פותרי ה-DNS שה-Mac שלך משתמש בהם ב-VPN

scutil --dns מדפיס את תצורת הפותר ש-macOS באמת מתייעץ איתה, ולא את שרת ה-DNS היחיד שהקלדתם בלוח הגדרות. הפלט ארוך מכפי שרוב האנשים מצפים, מפני שהמערכת מחזיקה בלוקי פותר נפרדים לנתיב ברירת המחדל, לממשקים עם היקף ולהעברה ייעודית לתחום. הבלוק בראש הפלט אינו בהכרח זה שעונה לשאילתה. אם שם פרטי נפתר במשרד ונכשל ברגע שה-VPN עולה, אי-ההתאמה נמצאת בכללי ההתאמה ובמסלולים, לא בכתובת השרת. קראו קודם את הסדר ואחר כך הוכיחו את התשובה בחיפוש אמיתי.

קראו את סדר הבלוקים לפני הכתובות

כל רשומה נפתחת ב-resolver #N ומפרטת nameserver[0], לפעמים if_index, שורת flags, reach, וכשהבלוק אינו ברירת מחדל פשוטה, domain ורשימת search domain. פותר מספר 1 בלי תחום הוא ברירת המחדל שמטפלת בשמות ציבוריים. כל דבר שנושא Scoped בדגליו קשור לממשק ש-if_index מציין, וכל דבר המסומן ב-Supplemental חל רק על התחומים הרשומים מתחתיו.

הבחירה היא התאמת סיומת. עבור שם כמו intranet.corp.example, macOS מעדיף את הפותר שרשומת ה-domain שלו היא הסיומת התואמת הארוכה ביותר, כך שבלוק עם domain : corp.example מנצח את ברירת המחדל גם כשהוא נמצא עמוק בפלט. order מכריע שוויון בין תחומים באותו אורך. מבט ראשון לרוב אינו זקוק ליותר מזה: כל הפלט כשרוצים לקרוא בלוק אחד מתחילתו ועד סופו, השורות הראשונות כדי ללמוד את סדר הבלוקים, ומעבר מסונן שמדפיס את כותרות הבלוקים לצד שורות השדות. בלוקים עם היקף מופיעים תחת כותרת משלהם ונקראים כמו המשך של הרשימה שמעליהם, לכן החזיקו כותרת לנגד העיניים בכל פעם שאתם מצטטים את הפלט.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

התאימו את if_index לממשק המנהרה

אינדקס מועיל רק אם אפשר למנות את הממשק שמאחוריו. scutil --nwi מפרט את פרטי הרשת שהמערכת מחזיקה, כולל הממשק הראשי ונגישות, ואילו ifconfig -l נותן לכם את השמות, כאשר utun0 עד utun9 הם מועמדי המנהרה שלקוח יוצר בדרך כלל. אפל משתמשת ב-scutil --dns כדוגמת הבדיקה שלה במדריך הפריסה, ומתעדת כיצד Network Extension יכול לנתב תחומים נבחרים לפותרים נבחרים, וזה המנגנון שאותם בלוקים עם היקף חושפים.

הבדיקה שמכריעה את השאלה היא אם הפותר יושב בנתיב שהמנהרה התקינה:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

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

שאלו את פותר המערכת, ואחר כך את השרת

שלושה כלים עונים על שלוש שאלות שונות, וערבובם מייצר את רוב המסקנות השגויות בתחום הזה. dscacheutil -q host -a name עובר דרך אותו פותר מערכת שיישומים רגילים משתמשים בו, ולכן בלוקים עם היקף ובלוקים משלימים חלים. dig בלי ארגומנט שרת קורא את /etc/resolv.conf, שאינו מקור האמת לפתרון עם היקף ב-macOS, והוא מדלג לגמרי על הכללים לכל תחום. dig @address מגיע בדיוק לשרת אחד ולא אומר דבר על הבחירה.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

כשהפקודה הראשונה עונה והשנייה מחזירה NXDOMAIN, מצאתם את הפיצול שחיפשתם ושום דבר אינו שבור. כשהראשונה מגיעה לפסק זמן בעוד dig @10.20.0.53 עונה, הפותר עובד אבל אינו נגיש בנתיב שהמנהרה בחרה, ולכן הצעד הבא הוא route -n get ולא עריכה של הגדרות DNS. החזיקו שמות פרטיים מחוץ לכל דבר שאתם מדביקים בכרטיס או בהערה משותפת.

מה שהפלט לא יכול להראות לכם

כמה שכבות יושבות מעל רשימת הפותרים או לצידה, וכל אחת יכולה לשלוח שאילתה למקום שהפלט לא מזכיר לעולם. דפדפן עם DNS מאובטח פעיל עשוי לפתור דרך הערוץ המוצפן שלו, כך שדף שנטען בזמן ש-dscacheutil מגיע לפסק זמן אינו סתירה. פרוקסי DNS שמותקן על ידי תוכנת אבטחה פועל כספק Network Extension ומעביר שאילתות בעצמו, ו-scutil --dns מציג מה הוגדר ולא את כתובת המעלה שהפרוקסי השתמש בה בסופו של דבר. תחומי חיפוש מוסיפים קמט שלישי: לשם לא מסויג מתווספת כל סיומת רשומה לפי הסדר, כך שהבלוק שענה עשוי להיות כזה שלא חשדתם בו מעולם.

תשובות מיושנות הן הדבר הזול ביותר לשלול והנפוץ ביותר לפספס:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

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

מדריך קצר לפני ואחרי

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

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

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

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

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