לכידת Split-DNS: אמרו היכן נלקחה כל תצפית

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

חיפוש אחד, כמה נקודות תצפית

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

כל אחד מהם עונה על שאלה אחרת, ואף אחד מהם לבדו לא מוכיח לאן השאילתה הלכה.

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

המסנן של הלקוח יושב בין היישום לחוט

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

ההנחיות של Secure Client ל-Split-DNS של Cisco מכסות התאמת דומיין ואת המסנן של Windows, והן מפרידות בין מה שיישום רואה כשהוא משתמש ב-API המקורי של resolver לבין מה שכלי כמו nslookup רואה. ההבדלים האלה הם העיקר.

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

nslookup הולך במסלול אחר מהיישום

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

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

קראו את המדיניות ואז שאלו את אותה שאלה דרך ה-resolver הרגיל:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

resolvers מוצפנים מסתירים את השאילתה, לא את החיבור

דפדפן עם resolver משלו מסוג DNS-over-HTTPS הוא מקרה אחר לגמרי. השאילתה יוצאת בתוך TLS, ולכן לכידת מנות מציגה חיבור לכתובת resolver אבל לא את השם שנשאל.

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

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

השוו לבדיקה מתויגת

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

היכן שמותר, השוו את הקבלה ב-resolver לתצפית צרה אחת מהלקוח או מהשער:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

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