למה דומיין לא מתעדכן ב-DNS?

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

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

למה דומיין לא מתעדכן ב-DNS גם אחרי ששמרתם

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

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

יש גם מקרים שבהם הבעיה אינה ב-DNS עצמו אלא בשירות שאליו הדומיין מצביע. לדוגמה, רשומת A עודכנה נכון, אבל שרת היעד לא מאזין ל-hostname, תעודת ה-SSL לא תואמת, reverse proxy לא מזהה את הדומיין, או שה-apex וה-subdomain הוגדרו אחרת. התוצאה נראית כמו propagation תקוע, אבל בפועל ההפניה כבר הגיעה ליעד החדש והיישום שם הוא זה שנופל.

קודם בודקים delegation, אחר כך רשומות

כשמנסים להבין למה דומיין לא מתעדכן ב-DNS, השאלה הראשונה צריכה להיות: מי השרתים הסמכותיים כרגע. לא מה אמור להיות, לא מה הוגדר אצלכם בשבוע שעבר, אלא מה ה-registry מפרסם כ-nameservers הפעילים.

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

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

TTL הוא לא המלצה

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

החלק שפחות זוכרים הוא שהורדת TTL צריכה לקרות לפני השינוי, לא בזמן השינוי. אם הורדתם מ-86400 ל-300 רגע לפני החלפת IP, מי שכבר קאש את הערך הקודם ל-24 שעות לא ישתכנע להתעדכן פתאום. הוא יכבד את ה-TTL הישן עד שיפוג. לכן בסביבות production מסודרות, הורדת TTL היא חלק מה-preparation ולא צעד תגובתי.

גם negative caching משחק תפקיד. אם הדומיין או תת-הדומיין לא היו קיימים קודם, ו-resolver קיבל NXDOMAIN, הוא עשוי לשמור גם את התשובה השלילית לזמן מוגדר. לכן לפעמים מוסיפים רשומה חדשה, בודקים מיד, ומקבלים תחושה ששום דבר לא קרה - כשבעצם נשמרה תשובה של "לא קיים" מהבדיקה הקודמת.

קאש מקומי, דפדפן ו-Resolver ציבורי

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

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

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

לא כל רשומה מתנהגת אותו דבר

רשומות A ו-AAAA פשוטות יחסית, אבל גם כאן אפשר ליפול על dual stack חלקי. אם עדכנתם A ל-IP חדש והשארתם AAAA ישן, משתמשים ברשתות שמעדיפות IPv6 עלולים להגיע עדיין לשרת הישן. מבחינתכם ה-DNS "כן התעדכן". מבחינת חלק מהתעבורה, הוא ממש לא.

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

גם apex domain מוסיף מגבלות. מי שמנסה לשים CNAME ב-root של הדומיין יגלה שזה לא תמיד תקין לפי סוג השרת או ההטמעה. חלק מהמערכות משתמשות ב-ALIAS או ANAME ברמת ספק, וחלק לא. אם עברתם בין פלטפורמות ולא התאמתם את סוג הרשומה, התוצאה עשויה להיות חוסר עקביות שנראה כמו DNS לא מתעדכן.

טעויות שכיחות במעבר בין ספקים

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

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

הטעות השלישית היא לשכוח רשומות לא בולטות - TXT לאימות שירותים, SRV, CAA, הפניות משנה, wildcard, או glue records במקרה של nameserver בתוך אותו דומיין. האתר אולי יעלה, אבל חלקים אחרים במערכת יתנהגו כאילו ה-DNS שבור.

שיטת עבודה קצרה לאבחון מדויק

במקום לבדוק אקראית כל כמה דקות, עבדו בסדר קבוע. קודם מזהים את ה-nameservers הפעילים ברמת ה-registry. אחר כך שואלים ישירות את השרתים הסמכותיים מה הערך הנוכחי. אם שם הערך נכון, בודקים resolver-ים חיצוניים כדי להבין איפה נשאר cache. אם גם ה-authoritative מחזיר ערך שגוי, חוזרים לקובץ האזור או לממשק הניהול ובודקים conflict, typo, או רשומה כפולה.

אחרי זה בודקים אם הבעיה בכלל ברזולוציה או כבר בשכבת השירות. כלומר, האם הדומיין נפתר ל-IP הנכון אבל השרת עצמו מחזיר תוכן ישן, שגיאת host, certificate mismatch או redirect קשיח. הרבה שעות "DNS" נשרפות בכלל על קונפיגורציית web.

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

מתי זו באמת תקלה ולא propagation רגיל

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

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

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

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

בפעם הבאה שדומיין "לא מתעדכן", אל תרעננו שוב את הדפדפן. תבדקו את השרשרת כולה, מה-registry ועד היישום. שם כמעט תמיד נמצאת התשובה.