שני אתרים, אזור DNS פרטי אחד: למי שייכות הרשומות?

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

התסמין נוקב בשם הבעלים החסר

סביר שלכל אתר יש עקיפה מקומית, רשומת Pi-hole או שורת dnsmasq שמישהו הוסיף כשנזקק לשם. הרשומה הירוקה קיימת רק ב-resolver הירוק, ולכן לקוח בצהוב שואל את ה-resolver שלו ומקבל "אין שם כזה" אמיתי. תשובה מיושנת נראית אחרת: המארח עבר, אתר אחד עדכן את העותק שלו, והשני עדיין מחזיר את הכתובת הישנה.

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

אם כן שאלת התכנון צרה וניתנת למענה: מי רשאי ליצור רשומה, ואיך אותה רשומה מגיעה לכל resolver שחייב להשיב עליה?

אפשרות A: אזור סמכותי אחד עם משניים

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

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

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

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

אפשרות B: תת־דומיין לכל אתר

האצילו את green.internal.example.com לאתר הירוק ואת yellow.internal.example.com לאתר הצהוב. כל אתר הופך לסמכותי לשמות שלו, ואזור האב נושא רק את רשומות ההאצלה. המחלוקת על קובץ אחד נעלמת, וצוות מקומי יכול להוסיף מארח בלי להמתין לשינוי מרכזי.

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

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

גרמו לכל resolver לפעול לפי הבחירה

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

אם Pi-hole מספק פתרון מקומי, רשמו אילו רשומות הוא מחזיק ואילו שאילתות הוא מעביר. שתי רשימות Pi-hole שנערכות בנפרד עדיין אינן משוכפלות. ב-Pi-hole v6, שורות dnsmasq מותאמות מוגדרות דרך אפשרויות בצד המארח כגון TOML, CLI או משתני סביבה ואינן נחשפות דרך ה-API; טעינת קבצים של /etc/dnsmasq.d/ היא אפשרות נפרדת שכבויה כברירת מחדל.

אחר כך בדקו משני הצדדים עם שם שאמור להיות גלוי בכל מקום:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

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

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