הגדרת AWS Route 53: היכן ניהול DNS נשבר
ניהול ידני של אזורים נשבר באופן צפוי: פערים ברשומות בין סביבות, היעדר בדיקות זמינות והעברת תעבורה לפי שיחת טלפון של התורן. הדומיין חי שנים, נוגעים בו עשרות פעמים, וכל עריכה בפאנל היא שינוי בלי היסטוריה ובלי מבט שני. את התקלה מבחינים לא לפי ניטור, אלא לפי פנייה של לקוח.
פערים מצטברים בשקט. רשומה שנוספה לבדיקה נשארת באזור הייצור; CNAME מתפצל מרשומת הכתובת של מאזן העומסים; רשומת דומיין מיושנת ממשיכה להחזיר כתובת של צומת שהוצא משימוש, כי ה-TTL הוגדר עם מרווח ורזולברים ביניים מחזיקים את התשובה הישנה. האבחון הופך לסריקה ידנית של אזורים, ואת התיקון מבצעים בלי להבין מי יצר את הרשומה המקורית ולשם מה.
סוג נפרד — כשל במעבר תעבורה. כשהצומת הראשי אינו זמין, ההחלטה מתקבלת בידי אדם: מבחין בתקלה, מעיר את התורן, משנה את הרשומה. בזמן שהתיאום הזה נמשך, השירות כבר לא עונה, וזמן ההתאוששות נמדד לא במהירות פעולת השירות, אלא במהירות ההתכתבות. בדיקות זמינות וכללים שתוארו מראש מוציאים את האדם מהמסלול הזה — אבל עדיין צריך להגדיר ולבדוק אותם.
בהמשך נפרט כיצד הגדרת AWS Route 53 מפסיקה להיות פעולה ידנית: אילו רשומות ובאיזה אזור אחריות צריכות להימצא, כיצד לתאר אזורים כקוד ומה לבדוק לפני שהתעבורה תעבור במסלול חדש.
מה נותן ניתוב מנוהל של תעבורה ואזורים
כל עוד האזור חי בפאנל ווב, כל שינוי הוא פעולה ידנית: מהנדס פותח קונסולה, עורך רשומה, בודק שלא נגע ברשומה הסמוכה. כשיש עשרות שירותים, חלקם של תיקונים ידניים גדל, ואיתו גם סוג הכשלים של "תיקנו את הדומיין הלא נכון".
במערך מנוהל רשומות מתוארות באופן הצהרתי: השינוי עובר בדיקה ומיושם באופן זהה בסביבת בדיקות ובסביבת עבודה.
מעבר עמיד לתקלות נשען על בדיקות זמינות של צמתים. AWS Route 53 סוקר נקודות כניסה במרווח נתון, ואם צומת מפסיק להגיב, הוא מוציא אותו מהתשובה — המשתמשים עוברים לצומת הגיבוי בלי לחכות לתורן.
זמן חיים קצר של הרשומה יחד עם הבדיקות נותן זמן התאוששות של השירות בטווח של עשרות שניות במקום שעות, עד שמישהו מבחין בבעיה ומגיב ידנית.
ניתוב לפי אזורים סוגר את המשימה השנייה: הלקוח מופנה לאתר הקרוב ביותר לפי השהיה או גיאוגרפיה, והעומס בין האזורים מתחלק לפי משקלים. מתקבלת דעיכה צפויה במקום כשל מלא — כאשר אתר נופל, התעבורה מתחלקת מחדש, ולא מחזירה שגיאה לכולם.
האפקט נמדד בשלושה מדדים: זמן התאוששות לאחר תקלת צומת, שיעור השינויים שעוברים בתהליך מאושר במקום תיקון ידני, ומספר התקריות מסוג "גורם אנושי ב-DNS". בהמשך — כיצד המערך הזה מוגדר לסביבה שלכם.
אפשרויות לארגון מערך DNS: השוואת מצבים
מערך DNS כמעט לעולם אינו הומוגני: החוצה פונה קבוצת שמות אחת, פנימה — אחרת, וחלק מהאזורים חיים אצל קבלן. בהמשך — סכימות עבודה שבהן באמת בוחרים בעת הגדרת Route 53, והמגבלות שלהן בתפעול.
מה להשוות לפני הבחירה
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| אזור ציבורי של הדומיין | שירותים חיצוניים: אתר, דואר, אימות בעלות על הדומיין, בדיקות של שירותי צד שלישי | הרשומות גלויות לכל; אין להוציא כתובות פנימיות, ופתרון שמות בתוך הרשת נסגר בנפרד |
| אזור פנימי של הרשת | שירותים הזמינים רק מרשתות מקושרות: מסדי נתונים, פאנלים תפעוליים, שירותים פנימיים | נפתר רק בתוך רשתות מקושרות; יש צורך בסכימת קישור בין אזורים לרשתות ובהתחשבות במגבלות על מספר הרשומות |
| מערך DNS היברידי | שם אחד צריך להשיב אחרת מבחוץ ומבפנים — פתרון שמות מפוצל | הרשומות משוכפלות, יש צורך בנהלי סנכרון ובמקור אמת אחד |
| האצלת תת-דומיין | צוות או מוצר נפרד מנהל את האזור שלו באופן עצמאי | גבולות האחריות מטשטשים: שינויים באזור הבן אינם נראים באזור האב |
| מערך מנוהל של קבלן | אין מהנדס פנימי ל-DNS, אבל צריך לשנות רשומות לעיתים קרובות | השינויים מתבצעים לפי נהלים ודרך תפקידים שהוקצו; הגישה המלאה לאזור נשארת אצלכם |
בפועל לרוב מתקבלת שילוב: אזור ציבורי בדומיין הראשי, פנימי — לשמות תפעוליים, ותתי-דומיינים מואצלים לצוותים. מערך DNS היברידי כזה נותן הפרדה צפויה — החוצה יוצא רק מה שצריך להיות ציבורי, ושינויים בתוך הרשת לא ממתינים לשחרור האזור החיצוני.
סדר היישום: ביקורת, סכימה, בדיקה, מסירה
הגדרת AWS Route 53 אינה תיקון רשומות חד-פעמי, אלא רצף עבודות שבו הצעד הבא מתחיל רק לאחר בדיקת הצעד הקודם. אנחנו עוברים מספירת מלאי למסירת השליטה: תחילה מתעדים את המצב בפועל של האזורים, אחר כך מרכיבים סכימה, בודקים אותה בתעבורה חיה ומוסרים ללקוח יחד עם נהלים. ביקורת האצלה שהוחמצה בדרך כלל צפה רק לאחר המעבר — כשחלק מהמבקרים מגיע לשרת זר.
- ביקורת אזורים והאצלה. משווים את רשימת הדומיינים עם רשומות NS אצל הרשם ובאזור האב, בודקים מועדי חידוש, כפילויות של תתי-דומיינים ורשומות שאיש אינו מאשר שהן פעילות.
- ספירת מלאי של רשומות. מייצאים את הרשומות הנוכחיות A, CNAME, MX ו-TXT, משווים לשירותים בפועל: אילו כתובות פעילות, אילו נותרו מסביבות בדיקה ישנות וניתן להסירן בבטחה.
- תכנון סכימת הרשומות. מפרקים אזורים ותתי-דומיינים לפי ייעוד, בוחרים סוגי רשומות, חיבור למאזן עומסים במקום כתובת קבועה, וזמן חיים של רשומות בהתאם לתדירות השינויים המתוכננת.
- הרכבת אזור חדש. מעבירים רשומות לאזור מתארח, בודקים תשובות דרך רזולברים שונים, ורק לאחר מכן נוגעים בהאצלה — כך נשארת לנו נקודת חזרה פעילה.
- בדיקת המעבר. משנים NS אצל הרשם, מנטרים את ההתפשטות לפי אזורים ומפעילים, ובודקים שהדואר ובדיקות הדומיין ממשיכים לעבור.
- נהלי שינויים. מתעדים מי ומתי מגיש בקשה, דרך איזו בקשה עורכים רשומות, כיצד מתואמת מחיקה, היכן מנוהלת היסטוריה וכיצד מבוצע שחזור.
- מסירת השליטה. מוסרים הרשאות עם הפרדת זכויות, סכימת אזורים כמסמך ורשימת בדיקה לפעולות שגרתיות, כדי שצוות הלקוח יעבוד עם DNS באופן עצמאי.
מה נשאר אצל הלקוח: אזורים, מדיניות, נהלים
העבודה נמסרת לא כאשר הרשומות נפתרות, אלא כאשר הלקוח משנה אותן בעצמו, בלי קבלן. לכן כל הערכה לאחר הגדרת Route 53 — ממפת האזורים ועד נהלי העריכות — נשארת אצלכם במאגר ומתעדכנת בכל שינוי.
- מפת אזורים ורשומות. אזורים ציבוריים ופרטיים, חיבור לחשבונות, ולכל רשומה — סוג, ערך, TTL וייעוד. ניתן לראות מה לכבות בעת הוצאת שירות משימוש ולאן להעביר את התעבורה.
- מדיניות גישה לפאנל. תפקידים עם הרשאות מינימליות בנפרד: קריאת אזורים, עריכת רשומות, ניהול האצלה. עריכת רשומה אינה דורשת גישה לחיוב ולשירותים סמוכים.
- הגדרות בדיקות זמינות. מרווחים, ספים ומספר אישורים, חיבור לרשומות עמידות לתקלות. ברור תוך כמה זמן כשל של צומת מעביר את התעבורה לגיבוי.
- נהלי עריכות DNS. סדר הפעולות: הכנה, בדיקה, חלון עבודה, הורדה מוקדמת של TTL, תוכנית שחזור. יומן עם מבצע השינוי, הזמן והסיבה.
- סכימת האצלה. רשומות NS, התאמת אזורים לרשם, שרשרת תתי-דומיינים ורשומות דואר. בעת החלפת רשם או חשבון דבר אינו הולך לאיבוד.
- ייצוא תצורה. האזורים מיוצאים לקוד תשתית: המצב משוחזר מהמאגר, והפער מול הפאנל נראה בהשוואה.
- תיעוד ומסירה. הוראות לפעולות שגרתיות, בעלי הרשאות, סדר שחזור האזור ואיש קשר למקרה של תקרית.
מקרה בוחן: העברת מערך DNS בלי השבתת השירות הראשי
תצורה התחלתית
האזור תופעל בקבוצת רשומות NS אחת אצל הרשם הקודם, וה-TTL של הרשומה הראשית עמד על יממה. כל עריכת כתובת התפשטה במטמוני הרזולברים כמעט יום, השינויים בוצעו ידנית דרך הפאנל, והאזור הגיבוי לא תוחזק במצב מעודכן. בעת כשל בפאנל הניהול היה צורך להרכיב את התמונה מהמטמונים — השירות נותר לא זמין כל זמן פער המטמונים.
מה שינו ומה התקבל
את האזור תיארנו כקוד במאגר נפרד והעברנו ל-Amazon Route 53: רשומות למאזן העומסים, בדיקות זמינות עם מעבר אוטומטי לכתובת גיבוי, שינויים — רק דרך תפקידים נפרדים עם יומן.
לפני העברת מערך ה-DNS הורדנו את ה-TTL לדקה, הרמנו אזור שני אצל רשם אחר וסנכרנו את הרשומות אוטומטית, כדי ששתי קבוצות רשומות ה-NS יענו באופן זהה.
| מדד | לפני | אחרי |
|---|---|---|
| זמן מעבר תעבורה | בסביבות יממה | 4 דקות |
| בקשות שאבדו ברגע החלפת NS | עד 2% | 0.02% |
| שחזור לאזור הקודם | שעות, ידנית | עריכה אחת, 6 דקות |
| פעולות ידניות לשחרור | 5–7 | 0 |
המעבר בלי אובדן תעבורה התאפשר הודות להחזקת שני האזורים: רזולברים עם מטמון שונה קיבלו תשובה תקינה מכל אחד מהם, ולכן לא הייתה השבתה של השירות. את המדידות לקחנו בניטור חיצוני מארבעה אזורים — לפי תשובות וזמן פתרון השם, ולא לפי סימנים עקיפים.
במה שונה ניתוב גיאוגרפי ממעבר עמיד לתקלות?
שתי המדיניות חיות באותו שירות ניהול DNS, למשל ב-Route 53, אבל עונות על שאלות שונות. ניתוב גיאוגרפי של בקשות מחליט לאן להפנות את הלקוח לפי מיקומו: לאירופאי — צומת אירופי, לאסיאתי — אסיאתי.
מעבר עמיד לתקלות עונה על השאלה "האם הצומת חי": כל עוד האתר עונה, הוא בתשובה; הפסיק — התעבורה עוברת לגיבוי.
ניתוב גיאוגרפי אינו בודק את מצב הצמתים. אם אתר אירופי נפל, ה-DNS ימשיך להחזיר את הכתובת שלו, והמשתמשים יקבלו שגיאה — כאן פשוט אין למה לעבור. בנוסף, דיוק זיהוי האזור אצל רזולברים ציבוריים מוגבל, ולכן את הכלל מגדירים עם ענף ברירת מחדל לשאר התעבורה.
מעבר עמיד לתקלות מבוסס על בדיקות זמינות סדירות: שירות הבדיקות פונה לצומת בכתובת ובפורט שהוגדרו, ולאחר סדרת כשלים הרשומה מוסרת מהתשובה.
את מהירות התגובה קובעים מרווח הבדיקות וזמן החיים של הרשומה במטמון: קצר מעביר לקוחות לגיבוי תוך דקות, אבל מגביר את העומס על שרתי השמות; ארוך — מאריך את המעבר לשעות.
בפועל משלבים בין המצבים: ניתוב גיאוגרפי בוחר אזור, ובתוך האזור מעבר עמיד לתקלות מפזר את התעבורה בין צמתים ומסיר צמתים שנפלו.
ניתוב גיאוגרפי מתאים במקום שבו חשובים קרבה למשתמש, גרסאות שונות של השירות לפי שוק ודרישות למיקום עיבוד הנתונים; עמיד לתקלות — במקום שבו צריך גיבוי והתאוששות אוטומטית. לבלבל ביניהם זו טעות אופיינית: ניתוב גיאוגרפי עוסק בקרבה, לא בזמינות.
ספקות טכניים נפוצים לפני העברת אזורי DNS
העברת אזור היא פעולה עם אפקט מושהה: השינויים מתפשטים במטמוני הרזולברים, ולכן חלק מהספקות מתעוררות כבר אחרי המעבר הפורמלי. בהמשך — ארבע שאלות שאנו מסירים לפני תחילת העבודה.
האם תהיה השבתה בעת העברת אזור לשירות אחר?
השבתה ממשית לא תהיה אם עותק האזור הוכן מראש. מעבירים רשומות לשירות החדש, משווים שורה-שורה עם הקיימות, ורק אחר כך משנים NS אצל הרשם — השירות הישן ממשיך לענות עד שהרזולברים ימצו את המטמון. כדי שחלון הזמן יהיה צפוי, מורידים את זמן החיים של הרשומות מראש, יממה לפני המעבר.
האם אפשר לעבור חלקית — רק עם חלק מהדומיינים?
דומיינים הם בלתי תלויים: לכל אחד יש רשומות NS משלו אצל הרשם, ולכן מעבר חלקי מתחלק לשלבים ומתבצע דומיין-דומיין. המגבלה היחידה — אין לפזר רשומות קשורות (דואר, אימות) בין שני שירותים, אחרת חלק מההודעות ילך לאיבוד.
כיצד בודקים את תוצאת המעבר?
משווים את תשובות הרזולברים הציבוריים לעותק ייחוס של האזור, ובודקים ש-NS התעדכנו, שההאצלה נשמרה ושהדואר והשירותים המקוונים עונים. תשובות מהשירות הישן בחלק מהרזולברים הן מטמון, לא תקלה: הן ייעלמו לאחר שיפוג זמן החיים של הרשומות.
מי אחראי לאזור אחרי ההעברה?
האזור נשאר בבעלותכם: הגישה לרשם ולפאנל — אצלכם, ואילו התצורה, סכימת הרשומות וסדר השחזור נמסרים בתיעוד. מכאן פועלים לפי נהלים — מי ומתי עורך רשומות והיכן נשמר עותק הגיבוי של האזור.
נדון במשימה ונחזור עם תוכנית עבודה
כדי שתוכנית העבודה תהיה מדויקת ולא "לפי העין", אנחנו צריכים חתך של מערך האזורים הנוכחי. שלחו רשימת דומיינים, ציינו היכן מואצלות רשומות NS ולמי יש גישה לרשם, האם יש אזורים פרטיים לשירותים פנימיים, בדיקות זמינות וכללי ניתוב לפי משקלים או לפי מאפיין גיאוגרפי. לפי החתך הזה נרכיב את שלבי העבודה, חלונות השינויים וסדר הבדיקה — ונחזור עם תוכנית.