רשומות DNS של לקוחות VPN: בעלים, TTL וניקוי הם דברים נפרדים
לכתובת VPN, לרשומת DNS ולערך במטמון יש בעלים נפרדים: החליטו מי רשאי לפרסם את השם, אילו ממשקים נרשמים ומתי הרשומות מתיישנות.
מחשבים ניידים מתחברים, מקבלים כתובת VPN, והשם ששאר המערכות מפענחות עדיין מצביע על כתובת המשרד מאתמול. דבר לא נכשל: כתובת הוקצתה, רשומה לא עודכנה, ומטמון עדיין מחזיק בתשובה הישנה. אלה שלושה אובייקטים עם שלושה בעלים, ורק אחד מהם שייך ל-VPN. תכנון פרסום פירושו להחליט מי כותב את השם, אילו ממשקים משתתפים ומתי הנתונים המיושנים נעלמים.
התסמין: שם שעוקב אחרי הכתובת הלא נכונה
מהמכשיר המנהרה פעילה וכתובת ה-VPN עונה. מעמדת העבודה של עמית, אותו שם מארח מפענח לכתובת פרטית שהמכשיר כבר אינו מחזיק, ולכן החיבור נגמר בזמן מול מכונה שעברה מקום. הרשומה סמכותית ושגויה, וזה גרוע מהיעדרה. כולם בוטחים בה ואיש אינו יכול להתחבר.
המקרה ההפוך שקט יותר: הרשומה נעלמת והשם מפסיק להתפענח לגמרי. שתי התוצאות באות מאותו פער בתכנון, ואף אחת מהן לא מתוקנת בהורדת ה-TTL. משך מטמון קצר יותר משנה כמה זמן התשובה השגויה שורדת, ולא אם היא נכתבת.
התחילו בשאלה איזה אובייקט מיושן. לכתובת שהוקצתה על ידי ה-VPN, לרשומה באזור ולתשובה במטמון של פותר יש תוחלות חיים ובעלים שונים.
שלושה אובייקטים, שלושה בעלים
ה-VPN הוא הבעלים של הקצאת הכתובות, והוא עשוי למסור את הכתובת ממאגר פנימי בלי שום חילופי DHCP שמגיעים למחשב הנייד. אזור ה-DNS הוא הבעלים של הרשומה, ומודל האבטחה שלו מחליט מי רשאי ליצור או לשנות אותה. המטמון של הפותר הוא הבעלים של העותק שהקורא משתמש בו כעת, ושום דבר שהמכשיר עושה אינו יכול להגיע אליו.
ההנחה שרכיב אחד עושה את שלושתם היא המקום שבו התכנון נשבר. כתובת שנראית כאילו הגיעה מטווח מנוהל אינה מוכיחה ששרת DHCP ביצע את הרישום, ורישום מוצלח אינו מוכיח שהקוראים רעננו את המטמון שלהם.
| Object | Owner | What it decides |
|---|---|---|
| VPN address | Tunnel gateway pool | Which address the device holds now |
| DNS record | Zone security model | Which name resolves to which address |
| Cached answer | Each resolver | How long a reader keeps the old answer |
מי רשאי לעדכן את הרשומה
באזור המשולב ב-Active Directory ועם עדכונים דינמיים מאובטחים, ההרשאות יושבות על הרשומה עצמה. רשומה שנוצרה על ידי חשבון שירות DHCP עשויה שלא להיות ניתנת לכתיבה מחשבון המחשב של הנייד, ושינוי מודל הבעלות בהמשך הוא מעבר, לא מתג. לכן קונפליקט בעלות שורד כל הגדרה בצד הלקוח.
ההנחיות של Microsoft לעדכונים דינמיים מעדיפות רישום מצד הלקוח לנקודות קצה היברידיות המחוברות לתחום. אימוץ זה משמעו העברה מכוונת של רשומות קיימות, ולא רק סימון תיבה במתאם ה-VPN וקיווי שהבעלים הישן ייסוג.
כאשר שירות DHCP חייב לרשום מחלקות התקנים אחרות, תנו לו את מודל ההרשאות ופרטי הכניסה הנתמך לתפקיד הזה. שמרו על רשומות קדמיות והפוכות באותה תוכנית, משום שרכיבים שונים מתחזקים אותן לעתים קרובות ואחת מהן נשכחת בדרך כלל.
ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042הפקודה הראשונה מציגה אילו כתובות המכשיר חושב שיש לו והאם החיבור מוגדר לרשום אותן. השנייה והשלישית משוות את מה שהלקוח מפענח למה שהאזור באמת מאחסן, וזה מפריד בין בעיית מטמון לבעיה סמכותית.
שלושה שעונים, לא אחד
פרסום ורענון הוא השעון הראשון: מתי המעדכן המורשה מודיע שכתובת השתנתה. TTL של המטמון הוא השני: כמה זמן פותר רשאי להחזיק בתשובה שקיבל. ניקוי סמכותי הוא השלישי: כיצד רשומות מיושנות מוסרות על ידי תהליך הרישום או על ידי הזדקנות וסריקה.
השעונים האלה בלתי תלויים, וערבובם מייצר תיקונים שאינם עובדים. שינוי באחד בלתי נראה לשניים האחרים. TTL קצר מקצר את חיי התשובה שבמטמון ואינו מעניק הרשאת עדכון. הסריקה מסירה רשומות שלא רועננו, והיא אינה יכולה לתקן רשומה שמעולם לא נכתבה על ידי הבעלים הנכון.
קבעו את ה-TTL לפי כמה מהר הקוראים חייבים לראות שינוי, ואת הסריקה לפי כמה זמן מכשיר נטוש צריך להחזיק בשם. אף אחד משני המספרים אינו מחליט מי רשאי לכתוב את הרשומה, ואף ערך TTL אינו הופך הקצאת כתובות לזכויות ניהול DNS.
תכננו פרסום למכשיר נודד
החליטו אילו ממשקים משתתפים ברישום. כתובת Wi-Fi ביתית, כתובת VPN וכתובת משרד ישנה משרתות קהלים שונים, ופרסום כולן מייצר שם עם כמה תשובות בעלות תועלת לא שווה. רשמו את הממשקים שהקוראים המיועדים באמת יכולים להגיע אליהם.
השאירו את שם המחשב הקבוע כזהות והתייחסו לכתובות כתכונות שלו. שמרו על רשומות גילוי התחום שהמכשיר צריך, ואל תשביתו את הרישום כליל כדי לפתור בעיית רשומות כפולות שתיקון הרשאות היה פותר.
כתבו את המקצה, המעדכן ובעל הניקוי ברשומה אחת, עם הקוראים המיועדים בשמם. כאשר השם שוב יצביע על הכתובת הלא נכונה, הרשומה הזו תגיד לכם מי משלושת השלושה לבדוק ראשון במקום להתחיל את החקירה מחדש.