Azure DNS: הגדרת אזורים ציבוריים ופרטיים, אוטומציה

Azure DNS נשבר בשקט: היכן צווארי הבקבוק של אזורים ורשומות

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

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

הוסיפו לכך רשומות יתומות: כתובות של צמתים שהוצאו משימוש, ששמותיהם עדיין מצביעים על צומת שהוסר מפעילות, ו-CNAME שיוריים לאחר מיגרציות.

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

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

מה נותנת סכמת אזורים מסודרת: מהירות, כשלים, שליטה

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

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

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

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

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

אזורים ציבוריים ופרטיים ב-Azure DNS: בחירת מצב

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

השוואת אפשרויות

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

שלבי הטמעה: מביקורת אזורים ועד מסירת נהלים

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

1. ביקורת אזורים ורשומות. מייצאים את כל האזורים והרשומות, משווים סוגים A, CNAME, MX ו-TXT, ערכי TTL, מחפשים קישורים תלויים וכפילויות. בנפרד מתעדים מי מבצע שינויים כעת — ידנית דרך הפאנל או בסקריפט.

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

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

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

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

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

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

מה נשאר אצלכם: אזורים, רשומות, מדיניות, סכמות, נהלים

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

• תצורת אזורים ורשומות. אזורים ציבוריים עם סט מלא של A, AAAA, CNAME, MX ו-TXT והאצלה תקינה דרך NS אצל הרשם; אזורים פרטיים — עם קישור לרשתות וירטואליות ורישום אוטומטי של רשומות מופעל.
• תיאורי תשתית בקוד. מודולים שמהם האזורים נבנים באופן חוזר: הרצה לא יוצרת כפילויות ולא דורסת TTL של רשומות שמנוהלת על ידי צוות אחר.
• סכמת קשרים. תרשים: מה הואצל, אילו רשתות מקושרות לאזורים פרטיים, היכן מסתיים האזור ומתחיל מאזן עומסים או שירות חיצוני.
• מדיניות גישה. תפקידים לקריאה ולעריכה לפי צוותים, גישה לאזורים פרטיים רק מתוך הרשת, ועריכות בעקיפת המאגר חסומות ברמת ההרשאות.
• נוהל שינויים. מי מאשר רשומה חדשה, באיזה ענף היא מופיעה, אילו בדיקות היא עוברת לפני ההחלה, וכיצד שינוי שגוי מוחזר לאחור בהרצה אחת.
• הוראות למשמרת תורנית. בדיקה שלב אחר שלב כאשר שם אינו זמין: האצלה, מטמון מפענח, מצב הרשומה — בלי לחפש אחראי במסרים.
• דוח מלאי. מה היה באזורים לפני העבודה: רשומות תלויות, התנגשויות שמות, רשומות בלי בעלים.

מקרה בוחן: הפרדת המעגל הציבורי והפנימי של האזור

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

מה היה

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

מה עשינו ומה נהיה

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

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

• השבתה בשינוי מתוכנן: מ-~40 דקות לאפס — עריכות מיושמות בלי לקטוע את הפענוח.
• אירועים בגלל התנגשות רשומות: מ-5–6 ברבעון לאפס בתקופה הנצפית.
• זמן לשינוי רשומה: מ-~2 שעות לדקות, כולל סקירה.
• חזרה לאחור: החזרת גרסה קודמת של קובץ האזור במקום עריכה ידנית בפאנל.

בנפרד תיעדנו TTL עבור רשומות פנימיות — כעת רשומה ישנה לא "נתקעת" במטמון לשעות לאחר החלפת הכתובת.

במה אזור פרטי שונה מאזור ציבורי באותו דומיין?

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

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

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

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

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

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

שאלות טכניות נפוצות: האצלה, מטמון, חזרה לאחור

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

האם אפשר להעביר האצלה בלי השבתה?

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

איך מתבצעת מיגרציה חלקית של רשומות?

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

מה יקרה אם השינוי שגוי?

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

איך להגביל גישה לאזורים פנימיים?

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

נדון באזור שלכם: נבנה סכמה ותוכנית מיגרציה

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

בתשובה תקבלו:

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

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