שני שרתי DNS במתאם אחד אינם מחלקים מרחבי שמות

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

המיתוס: שתי כתובות מחלקות שני תחומים

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

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

במה Windows באמת משתמש כדי לבחור

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

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

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

כלל אחד לכל מרחב שמות, שמרו את האובייקט

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

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

הנקודה המובילה מסמנת התאמת סיומת, ולכן הכלל מכסה את app.svc.internal.example וכל דבר אחר מתחתיו. שתי הכתובות כאן שייכות לתוכנית הניתוב של המעבדה הזו; כלל אינו יוצר אזור, אינו מתקין נתיב ואינו מאשר את היישום שמתחבר בסופו של דבר, ו מדריך Add-DnsClientNrptRule מתעד בדיוק איזה פרמטר עושה מה.

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

הוכיחו שהלקוח בחר בשרת

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

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

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

הסירו בדיוק את מה שיצרתם

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

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

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