הגדרת DNS דרך Cloudflare: העברה, DNSSEC, אוטומציה עם Terraform

הגדרת DNS ב-Cloudflare: מה נשבר בעת העברת אזורים

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

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

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

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

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

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

מה נותן אזור מנוהל: מהירות תגובה ופחות כשלים

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

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

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

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

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

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

דרכים לניהול אזור Cloudflare: פאנל, תבניות, שרת עצמאי

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

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

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

שלבי העברת האזור: ביקורת, סכמה, עריכות, בדיקה

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

1. ביקורת רשומות. מייצאים את האזור הנוכחי במלואו, משווים לתעבורה בפועל: אילו שמות באמת מגיבים, היכן תלויים כפילויות ושרשראות CNAME ארוכות, באילו רשומות ה-TTL מוגזם. רשומות מתות מסמנים — חלקן מתגלה רק דרך יומני הרזולברים.
2. סכמת האזור. מרכיבים את המבנה היעד: דלגציה של תת-דומיינים, רשומות דואר, שמות תפעוליים ושמות אימות. הסכמה מאושרת לפני העריכות — אחר כך יקר יותר לשנות אותה.
3. הכנת אזור היעד. פותחים אזור ב-Cloudflare, מעבירים את הרשומות לפי הסכמה, מתארים את המצב בקונפיגורציה כדי שהשינויים יעברו דרך ביקורת ולא ידנית בפאנל. את DNSSEC מגדירים, אך לא מפעילים לפני הדלגציה.
4. בדיקה בקונטור ניסוי. מעבירים את השמות דרך רזולברים בלתי תלויים, בודקים תשובות עבור הדואר והשירותים הפנימיים, ומשווים את מכלול הרשומות לביקורת.
5. החלפה ובדיקת הדלגציה. מורידים את ה-TTL מראש, מחליפים את רשומות ה-NS אצל הרשם ומאשרים את הדלגציה מנקודות חיצוניות. בנפרד בודקים את שרשרת החתימה של DNSSEC — טעות כאן שוברת את פתרון השמות כולו.
6. תוכנית חזרה לאחור. שומרים עותק של האזור המקורי ואת רשומות ה-NS הקודמות: החזרה אורכת דקות ואינה דורשת שחזור מגיבוי.
7. מסירה לתמיכה שוטפת. מוסרים מאגר עם תיאור האזור, הרשאות גישה, נוהל שינויים וניטור כשלים בפתרון השמות.

מה מוסרים לידיים: קונפיגורציות של האזור ונוהלים

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

• סכמת האזור — מפה של דומיינים ותת-דומיינים עם ציון היכן האזור מקבל שירות, אילו רשומות נמסרו לספק חיצוני ואילו חיות על שרתים עצמאיים, וכיצד עוברת הדלגציה.
• מטריצת רשומות — טבלה לפי כל סוג (A, AAAA, CNAME, MX, TXT, CAA, SRV): ייעוד, אחראי, זמן חיים, סימן „משתנה רק דרך המאגר”.
• תיאור הקונפיגורציה כקוד — אילו רשומות הוצהרו באופן דקלרטיבי, מה יובא מהאזור הקיים, היכן נשמר המצב, וכיצד מופעלת בדיקת התוכנית לפני היישום.
• תפקידי גישה ומפתחות — הפרדה בין הרשאות קריאה לשינוי, הגבלת טוקנים לאזורים מסוימים, סדר החלפת מפתחות, חשבון נפרד לאוטומציה במקום חשבונות משותפים.
• נוהל עבודה עם DNSSEC — היכן נמצאים מפתחות החתימה, כיצד מתפרסמת רשומת הדלגציה אצל הרשם, מה עושים בעת החלפת מפתחות וכיצד מסירים חתימה אם השרשרת נשברה.
• נוהל שינויים — בקשה, בדיקה באזור ניסוי, תוכנית יישום, חלון עבודה, נקודת חזרה לאחור ורשימת המאשרים את העריכה.
• הוראות לצוות — פירוט משימות טיפוסיות, אבחון התפשטות הרשומות, הסרת חסימה, ולאן להסתכל כשיש סטייה בין המאגר לאזור החי.

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

מקרה בוחן: העברת ארבעים אזורים בלי השבתת שירותים

נקודת מוצא

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

מה שינו ומה קיבלו

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

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

במה אזור מנוהל שונה משרת עצמאי

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

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

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

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

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

ספקות טכניים: דלגציה, DNSSEC, חזרה לאחור

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

מה נותן DNSSEC והאם הוא ישבור את הדומיין?

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

האם יישארו גיבויים של האזור?

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

כיצד בנויה החזרה לאחור של שינויים?

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

נדון במשימה שלכם: ממה נתחיל

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

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

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