איך לשחזר רשומת DNS שנמחקה בלי ליצור תקלה חדשה

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

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

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

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

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

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

הגדירו את היקף הפגיעה

לפני שנוגעים ברשומה, בדקו מה הפסיק לעבוד. אם האתר נגיש בכתובת IP אך לא בשם הדומיין, בדקו רשומות A או AAAA. אם רק תת-דומיין מסוים נשבר, ייתכן שמדובר ב-CNAME או ברשומת יעד ספציפית. אם הבעיה היא בדוא״ל, החקירה חייבת לכלול MX, TXT של SPF ו-DKIM, ולעיתים גם DMARC.

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

איך לשחזר רשומת DNS שנמחקה בצורה מבוקרת

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

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

שחזרו את כל מאפייני הרשומה, לא רק את הערך

רשומת DNS מלאה כוללת שם מארח, סוג, ערך, TTL ולעיתים גם עדיפות. שחזור של כתובת IP נכונה תחת שם שגוי לא יפתור דבר. כך גם רשומת MX ללא ערך Priority תגרום לבעיות במסירת דוא״ל, ורשומת TXT עם מרכאות או פיצול מחרוזת שגויים יכולה לשבור אימות.

ברשומת A או AAAA ודאו שהשם המדויק מתאים לצורך: שורש הדומיין, www או תת-דומיין ייעודי. ב-CNAME, בדקו שאין כבר סוג רשומה אחר באותו שם. CNAME אינו אמור להתקיים לצד A, MX או TXT באותו hostname, למעט מנגנונים ייחודיים שמנוהלים על ידי ספקי DNS מסוימים.

ברשומות MX יש לשחזר את שמות שרתי הדואר ואת סדר העדיפויות, ולא להחליף אותם בכתובות IP. ברשומות TXT, העתיקו את הערך כפי שנמסר על ידי השירות, כולל תחיליות כמו v=spf1 או v=DKIM1. שינוי קטן ברווח, במרכאות או בנקודה מסיימת יכול לשנות את המשמעות התפעולית.

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

בחרו TTL לפי מצב התפעול, לא מתוך הרגל

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

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

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

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

בדיקה טכנית של DNS אינה מחליפה בדיקת שירות. עבור אתר, בדקו HTTP ו-HTTPS, הפניות, תעודת TLS והנתיב הספציפי שנפגע. עבור דוא״ל, בדקו קבלה ושליחה, אימות SPF, חתימת DKIM ותאימות DMARC. עבור שירות אימות, ודאו שהפלטפורמה החיצונית מזהה את הרשומה ולא רק שהיא מופיעה בשאילתה.

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

מצבים שבהם שחזור של רשומה אחת לא מספיק

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

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

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

מניעת המחיקה הבאה היא חלק מהתיקון

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

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

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