הגדרת Azure DNS: היכן ניהול אזורים ידני מייצר תקלות
הגדרת Azure DNS בפועל מצטמצמת לעתים קרובות לפורטל: רשומות מוסיפים ביד, שינויים מבוצעים ישירות בסביבת הייצור, והיסטוריית השינויים נשארת בהתכתבות ובזיכרונו של מישהו. כל עוד יש עשרה שירותים, זה נסבל.
כשקיימים כמה אזורים וצוותים שונים עובדים עליהם במקביל, השינוי הופך לבלתי הפיך: מהנדס שני דורס את התוצאה של הראשון, ואין במה להחזיר את המצב הקודם — אין מול מה להשוות.
צרה נפרדת — רשומות שאינן מעודכנות. השירות עבר למאזן עומסים חדש, סביבת הבדיקות הוצאה משימוש, הכתובת שוחררה, אבל המצביעים לכתובת הישנה נשארו באזור: מישהו שכח, מישהו לא ידע שזה בתחום האחריות שלו.
לקוחות ושירותים פנימיים ממשיכים ללכת במסלול מיושן עד שיפוג ה-TTL, וחלק מהבקשות מגיעות למשאב זר ומחזירות תשובה בלתי צפויה.
המטריד מכל הוא האופן שבו זה מתגלה. כשלי תרגום שמות נראים כמו שגיאות של היישום: יש תקלות, אבל לא אצל כולם ולא תמיד, קשה לשחזר אותן, והבדיקה מתחילה מהקוד ולא מהאזור.
אזורים פרטיים שאינם מקושרים לכל הרשתות הווירטואליות מניבים התנהגות שונה בתת-רשתות שכנות — משירות אחד השם מתורגם, ומהשני לא.
המחיר — השבתת שירותים שמשתמשים מבחינים בה, ושעות של חיפוש הסיבה במקום הלא נכון. נבחן כיצד סוגרים את זה: כיצד מעבירים אזורים לתיאור כקוד, יוצרים רשומות alias ומקשרים אזורים פרטיים לרשתות, כדי שתרגום שמות יפסיק להיות פעולה ידנית.
האפקט של אזורים מנוהלים: מהירות השינויים וסוג התקלות שנעלם
שינוי באזור מנוהל של Azure DNS נכנס לתוקף תוך דקות: השינוי עובר באותו מסלול כמו שאר הקונפיגורציה, ואינו מחייב המתנה לחלון תחזוקה.
זמן ההחלה של השינויים מפסיק להיות תלוי במי מהתורנים נמצא כעת ליד הפורטל — מערך הרשומות נפרס באותו אופן ביום ובלילה, וההבדלים בין סביבת הבדיקות לייצור נשארים רק בערכי המשתנים.
מעבר אוטומטי בעת תקלה נשען על רשומות alias: הן מצביעות לא על כתובת קשיחה, אלא על שירות עם בדיקת זמינות. כל עוד הצומת מגיב, התעבורה עוברת אליו; הפסיק — האזור מחזיר את הכתובת של מסלול הגיבוי בלי התערבות ידנית ובלי טלפון לתורן. בעבר מעבר כזה נמשך עשרות דקות והסתמך על כך שמישהו יבחין בבעיה בזמן.
אפקט נפרד — עקבות ביקורת של השינויים. כל שינוי ברשומה מתועד: מי, מתי ומה שינה, ומאיזה ענף הגיעה הקונפיגורציה. זה מסיר את הוויכוח הקלאסי «ככה זה היה»: היסטוריית האזור נקראת כמו יומן, והחזרה לגרסה קודמת דורשת פעולה אחת במקום שחזור מהזיכרון.
שיעור הטעויות הידניות יורד בעיקר בזכות הוויתור על שינויים דרך הפורטל.
הרשומות מתוארות באופן דקלרטיבי ועוברות בדיקה לאיתור התנגשויות וכפילויות לפני ההחלה, ולכן שגיאת כתיב בכתובת, נקודה שנשמטה בסוף השם או זמן חיים שגוי של רשומה מפסיקים להיות מקור לאירועים — בדיקה אוטומטית תופסת אותם, ולא המשתמשים.
בסך הכול זה מעביר את האזור ממצב של «נוגעים בזהירות» למשאב מנוהל רגיל, שבו השינויים צפויים בלוח הזמנים והפיכים.
תרחישי פריסה של אזורים: ציבוריים, פרטיים, היברידיים
את תרחיש הפריסה בוחרים לפי מי שאמור לראות את השמות. אזור ציבורי משרת שירותים חיצוניים ואימות בעלות על הדומיין, אזור פרטי — פניות בין צמתים ולשירותים מנוהלים בתוך הרשת, והיברידי מכסה את המקרה שבו חלון הראווה פונה החוצה, בעוד מסדי הנתונים והממשקים הפנימיים מתורגמים רק מתוך ההיקף.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| אזור ציבורי | שירותים חיצוניים, אימות דומיין, רשומות לשותפים | השמות גלויים מהאינטרנט, אסור לפרסם כתובות פנימיות |
| אזור פרטי | פניות בין צמתים ולשירותים מנוהלים בתוך הרשת | מתורגם רק מרשתות וירטואליות מקושרות, מבחוץ אין שם |
| תרחיש היברידי | חלק מהשמות החוצה, חלק — רק מבפנים | שמות זהים בשני אזורים יש להפריד, אחרת התשובה תלויה בנקודת השאילתה |
כינויים (alias) לשירותים חיצוניים, למאזני עומסים ולנקודות הפצה פועלים מעל כל אחד מהתרחישים: הרשומה מפנה למשאב, והכתובת מוצבת אוטומטית, ולכן החלפת נקודת הכניסה אינה דורשת תיקון ידני של האזור ואינה מותירה שמות «תקועים».
פרט מפתח בתרחיש ההיברידי — קישור האזור הפרטי לרשתות וירטואליות. בלעדיו השם פשוט אינו מתורגם, וקישור מיותר חושף שמות פנימיים למסלולים שכנים, ולכן את רשימת הרשתות מקבעים ובודקים בכל שינוי בטופולוגיה.
סדר העבודה: ממלאי רשומות ועד העברת הניהול
אנחנו בונים את סדר העבודה כך שאף מעבר לא יישאר בלי נקודת חזרה. תחילה מתעדים את המצב הנוכחי של האזורים ב-Microsoft Azure, לאחר מכן אוספים מפת תלויות, ורק אחר כך משנים רשומות — אחת-אחת, עם בדיקה בכל נקודת ביקורת.
רצף הפעולות
- ביקורת אזורים. מייצאים את כל האזורים ומשווים את מערך הרשומות לתעבורה בפועל: היכן כתובות סטטיות מכפילות alias לשירות חיצוני, היכן ה-TTL מוגבה ומטמון הפותרות מחזיק ערך ישן יממה שלמה. בפלט — רשימת אי-התאמות לכל אזור.
- מפת תלויות השירותים. מסמנים אילו יישומים וקבלנים חיצוניים קוראים את האזור, מי מפנה ל-apex, ומי שהשמות הפנימיים שלו מתורגמים דרך אזור פרטי. המפה מראה מה יישבר אם הרשומה תיעלם.
- תכנון התרחיש. ממיינים את הרשומות לפי ייעודן: alias למאזן עומסים במקום כתובות סטטיות, אזורים פרטיים לשירותים פנימיים, כללי רישום אוטומטי של צמתים.
- הגדרה. מעבירים את הרשומות בשלבים, לאחר שהורדנו מראש את ה-TTL, כדי שהחלפת הכתובת תתבצע באופן צפוי ולא תימשך יממה שלמה.
- בדיקה בנקודות ביקורת. משווים תשובות ממספר פותרות (resolvers), ובנפרד — תרגום שמות פרטיים מתוך הרשת וההתנהגות כששירות היעד אינו זמין.
- תוכנית המעבר. מקבעים את סדר החלפת רשומות ה-NS, חלון העבודה, האחראי וקריטריון החזרה לאחור — לפי איזה אות מחזירים את הקונפיגורציה הקודמת.
- קבלת השינויים וההעברה. תפקידי גישה במקום פרטי התחברות משותפים, קונפיגורציות של אזורים במאגר קוד, הוראה קצרה לתיקונים אופייניים. אנחנו מקבלים את התוצאה יחד עם הצוות שלכם, כדי שמכאן והלאה האזורים יתוחזקו בלעדינו.
ערכת ההעברה: קונפיגורציות אזורים, תרשימים, נהלי שינויים
שינויים ב-DNS חיים יותר זמן מקבלן חיצוני: האזורים, הרשומות וההרשאות נשארים בטננט שלכם — ולצדם חייבות להישאר גם הידע. לכן אנחנו מעבירים לא גישה לפורטל, אלא מערך ארטיפקטים שניתן לשחזר, שלפיו מהנדס בצוות שלכם ישחזר את המצב הנוכחי ויבצע שינוי בלעדינו.
- קונפיגורציות של אזורים כקוד: אזורים ציבוריים ופרטיים, רשומות alias למשאבים, קישורים לרשתות וירטואליות — המצב משוחזר ממאגר הקוד ולא מהזיכרון.
- תרשים תרגום השמות: היכן נגמרים השמות הפנימיים ומתחילים החיצוניים, וכיצד זה משפיע על הפניות בין שירותים.
- מפת בעלי הרשומות: לכל אזור ורשומה קריטית — הצוות האחראי וערוץ התקשורת, כדי שבשעת תקלה לא לחפש את האשם.
- מדיניות גישה: מי קורא את האזורים, מי משנה, היכן נשמרים פרטי ההתחברות ומה עושים כשעובד עוזב.
- תפקידים לשינויים: הקריאה פתוחה למהנדסים, השינוי — דרך ערוץ מתואם עם סקירה; שינויים בפורטל מחוץ לנהלים אינם עוברים.
- נוהל שינויים: השלבים מהבקשה ועד הפרסום, בדיקה באזור שאינו סביבת ייצור, חלון ההחלה וסדר החזרה לאחור.
- יומן ורשימת בדיקה לקבלה: מה נבדק אחרי כל שינוי, היכן נשמרת ההיסטוריה ומי מתעד את סיבת השינוי.
ההעברה מסתיימת כשהצוות שלכם מוסיף בעצמו רשומה, בודק את תרגומה ומחזיר את השינוי לאחור. זהו הקריטריון שלפיו אנחנו מסיימים את העבודה.
ניתוח מקרה של הטמעה: לוחות זמנים של שינויים, שיעור הטעויות הידניות, תקלות
אזורי Azure DNS חיו בלוח בקרה מבוסס דפדפן: המהנדס תיקן רשומה ביד וצירף צילום מסך לטיקט. סבב שינוי אחד — מהבקשה ועד האישור — נמשך בממוצע יומיים והעסיק שלושה מאשרים.
יקר יותר היה לא המהירות אלא הצפיות. כשליש מהפניות במשמרת התורנית נבעו משינויים שבוצעו ביד: שגיאת כתיב בשם רשומה, מערך רשומות שאבד, מצביע שנמחק בטעות. לא הייתה היסטוריית שינויים, ולכן השחזור נמשך שעות.
מה שינינו
האזורים עברו למאגר קוד ומתוארים באופן דקלרטיבי: רשומות alias מפנות ישירות למשאבים ולא לשמות מתווכים, אזורי תרגום פרטי מקושרים לרשתות הווירטואליות שלהם, וכל שינוי עובר בדיקה לפני ההחלה. השינוי הפך לבקשת מיזוג — עם מחבר, היסטוריה והחזרה לאחור במעבר אחד.
- זמן ביצוע השינוי: יומיים → 20 דקות.
- שיעור האירועים משינויים ידניים: שליש מהפניות → מקרים בודדים.
- זמן השחזור: שעות → דקות, חזרה למצב הקודם.
«להחזיק רשומות במאגר קוד התברר כשקט יותר מאשר בפורטל: רואים מי שינה את האזור ולשם מה. אין יותר על מה להתווכח בישיבות הבוקר», — מנהל התשתיות בצד הלקוח.
נותר לעשות סדר באזורים הישנים שלא נכללו בגל ההעברה הראשון. אנחנו מעבירים אותם בלי לעצור את תרגום השמות.
במה שונה האצלת DNS מהעברת אזור?
האצלת דומיין משנה את מי שאחראי לשמות: אצל הרשם מתקנים רשומות שמציינות אילו שרתי שמות משרתים את האזור. העברת אזור היא מעבר של מערך הרשומות עצמו בין שרתי שמות או חשבונות, ונקודת הצביעה של האזור ההורה יכולה להישאר אותה נקודה. מכאן גם ההבדל בעבודה: במקרה הראשון משתנה מסלול השאילתות, ובשני — רק התוכן שמוגש במסלול הזה.
תחום האחריות בהאצלה רחב יותר: אנחנו מתחילים להשיב בסמכותיות עבור האזור כולו — רשומת ה-SOA, הרכב שרתי השמות, כל תת-הדומיינים ורשומות אימות הבעלות.
בהעברה אנחנו אחראים לשלמות המערך המועבר: אם תיאבד רשומה של דומיין הדואר או של אימות הבעלות, הדומיין ימשיך להתרגם, אבל הדואר והשירותים החיצוניים ייפלו. לכן העברה תמיד מלווה בהשוואת הייצוא לפני ואחרי.
מסוכן לבלבל בין העבודות האלה בתוכנית, כי סדרן הפוך מבחינת ההיגיון. תחילה האזור עולה במקום החדש ונבדק בשאילתות מפותרות חיצוניות, לאחר מכן מורידים את זמן השמירה במטמון, ורק אז מחליפים את שרתי השמות אצל הרשם.
אם מאצילים לפני שהאזור מוכן, הדומיין מחזיר תשובות ריקות כל עוד הרשומה הקודמת חיה במטמונים של הספקים. אם מעבירים רשומות אך לא מאצילים, השאילתות ממשיכות להגיע לשרתי השמות הישנים, ואיש לא יראה את השינויים.
גם ההחזרה לאחור בשלבים האלה שונה. האצלה מוחזרת על ידי החזרת שרתי השמות הקודמים אצל הרשם — הניהול אורך דקות, אבל ההתפשטות אורכת שעות. העברה מוחזרת על ידי החזרת מערך הרשומות הקודם, וכאן מציל אותנו ייצוא האזור שנלקח לפני השינויים.
ב-Azure DNS שתי הפעולות מבוצעות בכלים שונים, ולכן בתוכנית העבודה אנחנו מפרידים ביניהן כשלבים נפרדים עם נקודות בדיקה והחלטת סיום משלהם.
ספקות טכניים: אזורים פרטיים, כינויים, מגבלות
לפני השינוי הראשון באזור הייצור עולים אותן חמש שאלות — מבידוד אזורים פרטיים בין רשתות ועד הרשאות לשינוי רשומות. להלן תשובות קצרות, כדי להכריע בכך בשלב התכנון ולא ברגע ההעברה.
האם אזור אחד יכול לשרת כמה רשתות?
כן: לאזור פרטי אחד מוסיפים קישורים של רשתות וירטואליות. רישום שמות אוטומטי מפעילים רק באחת — אחרת רשומות המכונות דורסות זו את זו, ובידוד משיגים באמצעות תת-אזורים נפרדים.
כיצד מעבירים אזור שכבר פרוס?
ייצוא לקובץ אזור, ייבוא ל-Azure DNS, השוואת SOA, NS ו-CNAME הקודמים. יממה לפני המעבר מורידים את ה-TTL, מחליפים את ה-NS אצל הרשם, ומשאירים את האזור הישן זמין לחזרה לאחור עד שהתעבורה תתייצב.
לשם מה כינוי (alias) אם יש CNAME?
כינוי מפנה למשאב ולא לשם: הכתובת נקלטת מעצמה כשהמשאב נוצר מחדש, והוא מותר בקצה האזור, שם CNAME אסור. המגבלות — רק משאבי Azure ומכסה כוללת של מערכי רשומות ושאילתות.
מי יקבל הרשאות לשינויים?
את התפקיד נותנים לאזור מסוים ולא למנוי. השינויים עוברים דרך תיאור התשתית במאגר הקוד, על האזור מוטל מנעול מחיקה, וכל השינויים עם שם המחבר גלויים ביומן הפעולות.
מה קורה לאזור בעת תקלה אזורית?
אזורים ציבוריים הם גלובליים ואינם קשורים לאזור. באזורים פרטיים הקישור לרשת הוא אזורי — תרגום השמות באתר שנפגע ייעלם, ולכן אנחנו מחזיקים מראש קישורים באזור הגיבוי.
נדבר על המשימה: ננתח את תרחיש האזורים שלכם ונחזור עם תוכנית
הגדרת Azure DNS רק לעתים רחוקות מסתכמת בהוספת כמה רשומות: חשובים יותר תרחיש האזורים, ההאצלה והחיבור בין אזורים ציבוריים ופרטיים לשירותים. כדי שניתוח תרחיש האזורים יסתכם בשיחה אחת ולא בהתכתבות של שבוע, כדאי לאסוף מראש כמה נתוני פתיחה — ולפיהם נחזור עם הערכה ותוכנית עבודה.
- רשימת הדומיינים והאזורים: מה ציבורי, מה פרטי, היכן נמצא כעת כל אזור ומי מנהל את ההאצלה.
- טבלת הרשומות הנוכחית: A, CNAME, TXT, MX וכל מה שחייב להישאר ללא שינוי לאחר ההעברה.
- היכן נדרשות רשומות alias: קצה האזור, מאזן עומסים, נקודת הפצת תוכן — ואיזה משאב כל אחת מהן צריכה לעקוב אחריו.
- אזורים פרטיים והקישורים שלהם לרשתות וירטואליות: אילו שמות מתורגמים רק מבפנים ואילו רשתות צריכות לראות את אותו אזור.
- סדר המעבר: איזה מסלול נחשב לבדיקות, באיזה חלון מותרים שינויים וכמה מהר יידרש שחזור לאחור.
- גישות: המנוי, התפקיד בלוח הבקרה, כניסה לרשם לצורך החלפת שרתי השמות ולסביבה שבה נמצאים שירותי היעד.
אם חלק מהנתונים חסר — זו אינה סיבה לדחות את השיחה: הפערים בתרחיש הם בדרך כלל מקור הסיכון. תארו את המשימה בצורה חופשית, ונחזור עם הערכת היקף, סדר עבודה ולוחות זמנים ברורים.