הגדרת Yandex Cloud DNS: היכן נשבר פתרון השמות
כשל בפתרון שמות לעיתים רחוקות נראה כמו השבתה מלאה: שירות לא מוצא שירות שכן, הנפקת תעודה נתקעת בבדיקת הדומיין, האפליקציה עוברת לצומת גיבוי, וכעבור עשר דקות הכול עובד מעצמו. הלוגים של האפליקציה נקיים — השם נפתר, אבל לא למקום המצופה, ולרוב מגיעים לנקודה הזו רק אחרי ניתוח לילי.
לרוב הסיבה היא באחת מארבע נקודות. רשומות מיושנות וכפולות נשארות מעריכות ידניות בפאנל: כתובת לצומת שהוסר, שתי רשומות לאותו שם עם ערכים שונים, רשומת אימות שנשכחה וחוסמת הנפקת תעודה.
הנקודה השנייה — אזור שגוי: הדומיין תואר בטעות באזור ציבורי במקום באזור פרטי, או שאזור פרטי מכסה שמות חיצוניים בתוך הרשת, והשירותים הפנימיים מתחילים לפנות למקום הלא נכון.
הנקודה השלישית — מטמון תשובות. כל עוד ה-TTL גבוה, לקוחות, רזולברים פנימיים והאפליקציות עצמן מחזיקים כתובות ישנות, והתיקון שהוכנס «לא מיושם» במשך שעות. הרביעית — היעדר היסטוריית שינויים: את הרשומה תיקנו ידנית, אין למה לחזור, והפריסה הבאה מוחקת אותה בשקט.
אנחנו מפרקים כיצד הגדרת DNS בענן מכוסה באמצעות תיאור דקלרטיבי: אזורים ורשומות ב-Yandex Cloud DNS חיים במאגר קוד, עוברים סקירה, מיושמים לפי תוכנית עם TTL מחושב, והמצב נבדק מול התיאור. אז כשל בפתרון שמות מאותר בדקות, ולא בלילה של העלאת השערות.
מה נותן שירות שמות מנוהל: מהירות ויכולת חיזוי
אזור מנוהל הוא משאב של הספק, ולא קובץ במכונה אחת: הרשומות משוכפלות, ופתרון השמות מתבצע מנקודת נוכחות הקרובה ביותר ללקוח. הוצאת שרת שמות מהשירות אינה דורשת תיקונים מצדנו, ולכן עבודות מתוכננות לא הופכות לחלון אי-זמינות. אנחנו מעבירים אזורים ל-Yandex Cloud ומיד מקבעים את הפרמטרים שהתנהגות בעת כשל תלויה בהם.
מהירות התגובה של שמות נקבעת על ידי קרבת הרזולבר וה-TTL שנבחר. בערך סביר, רוב השאילתות מוחזרות מהמטמון, והלקוח לא ממתין למעבר רקורסיבי מלא — האפקט נראה בשיעור התשובות מהמטמון ובזמן יצירת החיבור.
עמידות בפני כשל של פתרון השמות נשענת על מספר שרתי שמות באזורי זמינות שונים. אובדן נקודה אחת אינו מוביל לכשל: השאילתות עוברות לשרתים שנותרו, ושיעור פתרונות השמות הכושלים נשאר ברמת הרקע. אנחנו מודדים אותו לפני ואחרי המעבר ומשווים, ולא מסתמכים על תחושות.
היסטוריית שינויים של רשומות מכסה את סוג השגיאות היקר ביותר — תיקון «ביד» בלי עקבה. כל שינוי שומר את המחבר והזמן, החזרה למצב הקודם אורכת דקות, והרשומות עצמן חיות בתיאור דקלרטיבי (Terraform) עם סקירה לפני יישום. שם גם נפתרת בדיקת הדומיין עבור תעודות שזקוקות לרשומה באותו אזור.
אזורים ציבוריים ופרטיים: השוואת אפשרויות ארגון
ההפרדה לאזורים ציבוריים ופרטיים פותרת לא את השאלה «היכן לשמור רשומות», אלא את שאלת הנראות: אילו שמות נפתרים מהאינטרנט, ואילו — רק בתוך רשת הענן.
אלה שתי ישויות בלתי תלויות עם מחזור חיים נפרד, ואין לשלב אותן באזור אחד: רשומות פרטיות לא צריכות להיות גלויות מבחוץ, וציבוריות — חייבות.
בפועל בוחרים בין ארבע סכמות. להלן תנאי היישום ומה כל אחת מגבילה.
| סכמה | מתי מתאימה | מגבלות |
|---|---|---|
| אזור ציבורי אחד | אתר, API וויטרינה נגישים מהאינטרנט, אין שמות פנימיים | שמות פנימיים עוברים לפתרון ציבורי, אין גבול בין תעבורה חיצונית לפנימית |
| אזור פרטי בתוך הרשת | שירותים פנימיים, בסיסי נתונים, תורים, פנייה לפי שמות | לא נפתר מבחוץ; רשומות גלויות רק מרשתות משויכות, לכל רשת — אזור משלה |
| סכמת אזורים היברידית | מתאר חיצוני ציבורי בתוספת ליבה סגורה — מקרה מוצרי טיפוסי | שמות זהים חיים בשני אזורים: חוסר סנכרון של תצורות יוצר כשלים נדירים וקשים |
| שרתי שמות משלכם | נדרש שליטה מלאה באזור, רשומות לא סטנדרטיות, תשתית שמות משלכם כבר קיימת | זמינות ועמידות בפני כשל — באחריותכם; האצלה, העברת אזור, פתרון תלוי בתשתית שלכם |
היברידי הוא מה שאליו מגיעים כמעט כל המתארים המוצריים: החוצה נמסר מינימום רשומות, שמות פנימיים חיים באזור פרטי המשויך לרשתות מסוימות. האפשרות קובעת לא את הנוחות, אלא את גבולות הכשל: ככל שהאזור ציבורי יותר, כך יקרה יותר שגיאה ברשומה.
סדר היישום: ממיפוי מלאי האזורים ועד למסירה
היישום מחולק לשלבים כך שכל שינוי ניתן לבדוק ולהחזיר אחורה בלי להמתין לפקיעת ה-TTL. תחילה מקבעים את המצב הנוכחי ואת הבעלים של הרשומות, אחר כך מעבירים את האזורים, ורק לאחר מכן מחליפים את התעבורה — בכל שלב יש נקודת חזרה וקריטריון שממנו ברור שאפשר להמשיך הלאה.
-
מיפוי מלאי רשומות. מייצאים את כל הרשומות מהאזורים הפעילים — A, AAAA, CNAME, MX, TXT, SRV, CAA — ומשווים לתעבורה בפועל ולשירותים פעילים. עבור כל רשומה מוצאים בעלים: בלי אחראי על הייעוד, הרשומה לא נכנסת להעברה.
-
סכמת אזורים. מסמנים מה נשאר באזור הציבורי ומה עובר לפרטי — שירותים פנימיים, בסיסי נתונים, שמות שירות. אזורים פרטיים משייכים לרשתות מסוימות, כדי ששמות פנימיים לא יענו החוצה.
-
תיאור תצורה כקוד. אזורים ורשומות מתארים בדקלרטיבי, מצב נשמר מרחוק, שינויים עוברים סקירה. רשומות קיימות מייבאים, כדי שהתיאור יתאים למציאות ולא יסתור אותה.
-
הפחתת TTL והכנת חלון. ברשומות שעתידות להשתנות, מפחיתים מראש את ה-TTL — חלון החזרה מתקצר משעות לדקות. זה נעשה לפני ההחלפה, אחרת את מהירות החזרה קובע המטמון הישן של הרזולברים.
-
החלפה מבוקרת. תחילה מעבירים דומיין בדיקה ומוודאים שהתשובות תואמות את התקן, אחר כך מחליפים את ההאצלה של אזור הייצור. האזור הישן נשאר פעיל — שתי קבוצות שרתי השמות עונות באותה צורה.
-
בדיקה לאחר ההחלפה. שולחים שאילתות לרשומות מרזולברים חיצוניים ומכל רשת, משווים לייצוא המלאי, בודקים רשומות דואר והנפקת תעודות: דומיין האימות ו-CAA צריכים לעבור בלי תיקונים ידניים.
-
החזרה אחורה ומסירה. עד סוף חלון הניטור מחזיקים את האזור הישן במצב מעודכן, החזרה אחורה — החזרת ההאצלה. לתפעול מוסרים גישות, סדר תיקונים דרך קוד, ניטור תשובות ובקרת מועדי חידוש תעודות.
מה מוסרים לידיים: תצורות, סכמות, נהלים
אנחנו מוסרים לא ארכיון קבצים, אלא תצורה עובדת שאפשר לפרוס מאפס ולהמשיך לתחזק בלעדינו. כל הארטיפקטים נמצאים במאגר קוד ועוברים בדיקה לפני יישום, לכן מצב האזורים ב-Yandex Cloud DNS לא סוטה ממה שמתואר בקוד.
- תיאור אזורים ורשומות בצורה דקלרטיבית — קבצים עם אזורים ציבוריים ופרטיים, רשומות, ערכי TTL ושיוך לסביבות. כל תיקון עובר סקירה ובדיקת תוכנית, שינויים ידניים בפאנל הניהול נשללים.
- סכמת רשת וקשרים — כיצד האזורים מתייחסים לרשתות, תת-רשתות ושירותים, היכן פתרון השמות יוצא החוצה והיכן נשאר בתוך המתאר. בנפרד מסומנות הנקודות שבהן לרוב נוצרים קונפליקטים.
- כללי גישה לניהול אזורים — תפקידים למהנדסים, חשבונות שירות נפרדים לאוטומציה, הפרדת הרשאות בין מתאר ייצור למתאר בדיקות.
- הפרדת סביבות — פרמטרים ומצבים לפרודקשן ולסביבות בדיקה מופרדים, לכן ניסויים לא נכנסים לאזורי ייצור ולא שוברים פתרון שמות אצל משתמשים.
- תיעוד — סדר הוספת רשומה, הנפקה וחידוש תעודות, בדיקת התאמת התיאור למצב בפועל.
- נוהל תגובה לאירועים — נקודות בקרה לניטור, סדר החזרה לתצורה הקודמת, קריטריונים להסלמה ותחום אחריות בצד הלקוח.
- סדר מסירה — הרכב הגישות, רצף ההפעלה מאפס ותרחיש בדיקה שלפיו הצוות שלכם משתכנע שהתשתית עובדת בלעדינו.
מקרה בוחן: העברת אזורים ללא זמן השבתה וגידול בתשובות מוצלחות
הלקוח — שירות מוצרי עם כמה עשרות תתי-דומיינים ותשתית פנימית בשתי רשתות. אזורים ציבוריים חיו אצל רשם ישן, פרטיים — בתצורות כתובות ביד על שני שרתים, תעודות חודשו ידנית. תיקון רשומה אחת ארך חצי יום ודרש השוואה ידנית בין סביבות.
חתך לפני המיגרציה: שיעור התשובות המוצלחות החזיק מעמד על 96–97%, לאחר כל תיקון באזור פתרון השם צנח עד 40 שניות, וחלק מהשירותים לא מצאו שמות פנימיים כלל.
לתמיכה הגיעו כשלושים פניות בחודש בניסוח «השירות לא נפתח», וטופלו ידנית — הסיבות могли להיות שלוש: מטמון, רשומה מיושנת או תעודה שנפלה.
מה שינו
אזורים ורשומות הועברו ל-Yandex Cloud DNS ותוארו ב-Terraform: ציבוריים — בדקלרטיבי, פרטיים — בשיוך לרשתות, כדי ששמות פנימיים ייפתרו רק בתוך המתאר. יממה לפני ההחלפה הפחיתו את ה-TTL לדקה, נתנו למטמונים הישנים לפוג, ורק אחר כך החליפו את שרתי השמות אצל הרשם. בדיקת הדומיין עבור תעודות הועברה לרשומות DNS, והחידוש הפך לאוטומטי.
חתך אחרי: שיעור התשובות המוצלחות — 99.9% ומעלה, פתרון שם נכנס לעשרות אלפיות שנייה. ההחלפה עברה ללא זמן השבתה — החלון ארך 40 דקות, וכל אותו זמן השירות ענה כראוי דרך שתי קבוצות שרתי השמות.
פניות «לא נפתח» ירדו לבודדות בחודש, וכמעט כולן — מרשתות חיצוניות, שבהן המטמון של הספק חי חיים משל עצמו.
במה שונה אזור DNS פרטי מאזור ציבורי
אזור ציבורי עונה לשאילתות מהאינטרנט: את הרשומות שלו מחזירים שרתי שמות סמכותיים, והאזור האב מאציל להם את הדומיין. אזור פרטי חי בתוך רשת הענן — רק שאילתות משם רואות אותו, ואין לו האצלה החוצה. לכן דומיין בעל אותו שם יכול להתקיים בשני אזורים בו-זמנית ולא להתנגש ביניהם.
תחום הנראות של הרשומות — ההבדל העיקרי. באזור ציבורי כל רזולבר חיצוני יקבל כתובת, ואי אפשר להסתיר חלק מהרשומות: תתי-דומיינים במוקדם או במאוחר נכנסים לרשימות פתוחות. באזור פרטי השם לא קיים עבור האינטרנט — מבחוץ שאילתה תחזיר סירוב, ומבפנים את הכתובת הנדרשת.
על אזור פרטי נבנים שמות פנימיים של שירותים. שם מהצורה db.prod.internal נוצר לצד הרשת ואינו תלוי בכתובות של מופעים מסוימים: בעת החלפה או הרחבה משתנה רק הרשומה, ותצורות האפליקציות נשארות כשהיו. אותו שם משמש בכללי גישה בין שירותים.
כשמפרידים בין פתרון חיצוני לפנימי, שם אחד יכול להשיב בכתובות שונות — מבחוץ לנקודת כניסה, מבפנים ישירות לשירות. כך תעבורת שירות לא עוברת דרך היקף חיצוני, ובחירת הסביבה נקבעת לפי האזור, ולא לפי תיקון בקוד.
ב-Yandex Cloud DNS שני האזורים מתוארים בדקלרטיבי יחד עם שיוך לרשתות, לכן המצב משוחזר. תעודות לשמות פנימיים מונפקות על ידי מרכז אישורים פרטי, ולשמות ציבוריים — אימות בעלות על הדומיין; גם זה וגם זה פגים לפי לוח זמנים, לכן את החידוש מציבים כמשימה קבועה, ולא כפעולה ידנית.
שאלות נפוצות: זמן חיים של רשומות, מיגרציה, תעודות
הגדרת אזור היא רק ההתחלה: בהמשך חשוב יותר כיצד הוא חי בתפעול. להלן תשובות לארבע שאלות שנשאלות לרוב לפני שלוקחים את התשתית לפעולה.
אזורים, רשומות, תעודות והרשאות מתארים בקוד ושומרים במאגר קוד — תמיד אפשר להשוות את מצב האזור לתיאור ולהחזיר אחורה. זה גם מסיר את הכאב העיקרי של המסירה: מהנדס חדש רואה מדוע הרשומה נראית דווקא כך.
איזה זמן חיים לבחור לרשומות?
לפני החלפה מתוכננת מפחיתים את זמן החיים מראש, כדי שכתובות ישנות יפסיקו לשקוע במטמון הרזולברים, ואחרי התייצבות מחזירים אותו לערך רגיל. אין טעם להשאיר אותו נמוך תמיד: מספר השאילתות לאזור גדל. עבור רשומות סטטיות לוקחים שעות, ועבור רשומות מאחורי מאזן עומסים — דקות.
איך לעבור לתשתית חדשה בלי זמן השבתה?
תחילה מייבאים את הרשומות הנוכחיות לתיאור, משווים אי-התאמות, ורק אחר כך מחליפים את שרתי השמות, תוך בדיקת פתרון ממספר רשתות. את המתאר הישן מחזיקים עד לפקיעת זמן החיים הארוך ביותר של הרשומה, ורק אז מסירים. החזרה אחורה — להחזיר את תיאור האזור הקודם.
איך לא לפספס חידוש דומיינים ותעודות?
הנפקה וחידוש של תעודות מעמידים על אוטומציה עם בדיקת אימות במתאר בדיקות, ולא ביום הפקיעה. עבור דומיינים ואזורים מגדירים התראות כמה שבועות לפני המועד, כדי שהחידוש לא יהפוך לעבודת חירום בסוף השבוע.
מה כוללת מסירת התפעול?
סכמת אזורים, תיאור במאגר קוד, נהלים להנפקת תעודות ולתיקון רשומות, הפרדת גישות והוראות החזרה אחורה. אנחנו עורכים סקירה עם הצוות שלכם ונשארים בקשר בתקופה שבה התורנות עוד לא עברה אליכם.
נדון בסכמת האזורים שלכם ונחזור עם תוכנית עבודה
כדי שהערכת העבודה לא תהיה «בעין», די לנו בתמונת האזורים הנוכחית: אילו דומיינים מטופלים, היכן האזורים ציבוריים והיכן פרטיים בתוך Yandex Cloud. אם התצורה כבר מתוארת בקוד, שלחו מאגר קוד או ייצוא; אם הרשומות מנוהלות ידנית — די ברשימה ובסכמת קשרים.
בשיחה נסקור:
- אילו אזורים ציבוריים, אילו פרטיים והאם הם משכפלים זה את זה;
- כיצד מונפקות תעודות והיכן פגים תוקפיהן;
- היכן נותרו תיקונים ידניים ומה מונע להעביר אותם לתיאור התשתית;
- כיצד מוגדרת ההאצלה ולאן מצביעות רשומות NS;
- אילו שירותים תלויים ב-DNS ומה יקרה בעת אי-זמינות של האזור;
- האם נדרשת הגנה מפני זיוף תשובות ובקרת שלמות;
- כיצד מופרדות הרשאות הגישה לאזורים בתוך הצוות.
מה לשלוח מראש:
- רשימת דומיינים ותתי-דומיינים עם ייעוד;
- סכמת רשתות: היכן חיים השירותים ולמי דרושים שמות פנימיים;
- תצורות נוכחיות או ייצוא אזורים;
- רשימת תעודות והמקומות שבהם הן משמשות.
לאחר מכן נחזור עם הערכה ותוכנית יישום: סדר העברת האזורים, אופן תיאור התצורה, נקודות בדיקה וסדר החזרה אחורה. תארו את המשימה בשתי פסקאות — זה יספיק כדי לנקוב בלוחות זמנים ובהרכב העבודה.