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

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

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

מה נחשב לקונפליקט רשומות DNS בפועל?

המקרה הקלאסי הוא רשומת `CNAME` לצד רשומה אחרת באותו שם, למשל `A`, `MX` או `TXT`. לפי כללי DNS, שם שמוגדר ככינוי באמצעות `CNAME` לא אמור לשאת סוגי רשומות נוספים. אם `app` מוגדר כ-`CNAME` ליעד חיצוני, ובמקביל נשארת עבורו רשומת `A` ישנה, חלק ממערכות הניהול ימנעו שמירה, אחרות יקבלו את ההגדרה, והתוצאה בפותרי DNS עלולה להיות לא צפויה.

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

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

סימנים שמצביעים על סתירה ולא על תקלה אקראית

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

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

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

תהליך בדיקה שלא מבוסס על ניחושים

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

לאחר מכן, עברו בתהליך הבא:

1. בדקו את שרתי השמות המוגדרים אצל הרשם ואת רשומות `NS` שמוחזרות בבדיקה חיצונית. אם הם אינם תואמים, עצרו כאן. כל שינוי באזור הלא פעיל הוא רעש תפעולי.
2. שלפו את הרשומות מסוגי `A`, `AAAA`, `CNAME`, `MX`, `TXT`, `SRV` ו-`CAA` עבור השמות הרלוונטיים. אל תסתפקו בתצוגה בממשק אחד. בדקו גם מה מחזירים שרתי השמות הסמכותיים.
3. השוו בין התוצאה המפורסמת לבין מפת השירותים שלכם: אתר, הפניות, דוא״ל, אימות בעלות, APIs וסביבות פיתוח. רשומה תקינה טכנית יכולה להיות שגויה עסקית.
4. בדקו ערכי `TTL` ואת זמן השינוי האחרון. רשומה ישנה במטמון אינה הוכחה לקונפליקט, אבל ערך `TTL` חריג או עדכון שבוצע באמצע מעבר שירות מסבירים לעיתים את הפער.
5. תעדו את מקור הבעלות של כל רשומה. אם אין תשובה ברורה לשאלה מי יצר אותה ולמה, היא מועמדת לבדיקה, לא למחיקה אוטומטית.

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

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

`CNAME` מול רשומה קיימת

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

מעבר בין ספקי דוא״ל

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

`AAAA` שנשארה מאחור

אם הוגדרה כתובת IPv6 ישנה לצד רשומת IPv4 תקינה, חלק מהלקוחות יעדיפו IPv6 ויגיעו לשרת שגוי או לא זמין. מבחינת הצוות האתר "עובד", כי הבדיקה בוצעה מרשת שמעדיפה IPv4. מבחינת משתמשים אחרים מדובר בכשל מלא. אם אין תמיכה פעילה ומנוטרת ב-IPv6, אל תשאירו רשומת `AAAA` רק כי היא קיימת.

אימותים כפולים של ספקי שירות

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

איך מתקנים בלי להרחיב את הנזק

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

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

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

מניעה היא חלק מניהול DNS, לא תוספת

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

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

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