עודכן לפני חודש
האתר שלך לא נטען. האימייל שלך הפסיק לעבוד. האינסטינקט הראשון של כולם: להאשים את ה-DNS.
לפעמים הם צודקים. DNS יושב בתחילת כל חיבור — אם הוא נכשל, שום דבר אחר לא משנה. השרתים שלך יכולים לפעול בצורה מושלמת, אבל אם משתמשים לא יכולים לתרגם את שם הדומיין שלך לכתובת IP, הם לעולם לא יגיעו לאותם שרתים.
אבל DNS גם מואשם בבעיות שלא גרם להן. האתגר הוא לא רק לתקן בעיות DNS — אלא להבין האם DNS הוא בכלל הגורם.
כאשר דומיינים לא מתורגמים כלל
כשל ה-DNS הברור ביותר: כשל תרגום מוחלט. המשתמשים רואים "DNS_PROBE_FINISHED_NXDOMAIN" או "Server not found". הדומיין פשוט לא קיים מבחינת המחשב שלהם.
זה קורה כאשר:
- רישום הדומיין פג תוקפו (נפוץ יותר ממה שחושבים)
- רשומות שרתי שמות מצביעות לשרתים שכבר לא קיימים
- קבצי zone מכילים שגיאות תחביר שמשבשות הכל
- שינויי שרתי שמות נמצאים באמצע הפצה
התחל עם הברור: האם הדומיין בכלל רשום? בדוק בלוח הבקרה של הרשם שלך. דומיין עם סטטוס "פג תוקף" או "בהמתנה למחיקה" לא יתורגם, לא משנה מה תעשה.
לאחר מכן, ודא את שרתי השמות. שרתי השמות הרשומים אצל הרשם חייבים להתאים לשרתי ספק אחסון ה-DNS שלך. אם הרשם מצביע ל-ns1.olddnsprovider.com אבל רשומות ה-DNS שלך נמצאות ב-ns1.newdnsprovider.com, שום דבר לא יעבוד.
כעת שלח שאילתה ישירות לשרתי השמות הסמכותיים שלך:
פקודה זו עוקפת את כל המטמון ומציגה בדיוק מה שרתי השמות שלך מגישים. אם שאילתה זו מצליחה אבל שאילתות ל-DNS ציבורי נכשלות, אתה באמצע הפצה — המתן. אם גם כאן היא נכשלת, הבעיה היא בשרתי הסמכות שלך או בתצורת ה-zone.
תיקון: חדש דומיינים שפג תוקפם מיד — צפה ל-24-48 שעות עד שהרישום ישחזר את השירות. לאי-התאמות בשרתי שמות, עדכן רשומות אצל הרשם שלך, לא אצל ספק ה-DNS. לשגיאות בקובץ zone, רוב הספקים שומרים יומני שינויים; חזור לתצורה האחרונה שידעת שעובדת בזמן שאתה מאתר את הבעיה.
כאשר DNS איטי
האתר שלך נטען, אבל משתמשים מתלוננים שהוא "לוקח נצח". לפעמים הסיבה היא זמן תגובה ארוך של DNS — כל שאילתה מוסיפה זמן אחזור לפני שהדפדפן מוריד דבר.
מדוד את זה:
ערך "Query time" מציג את זמן הפתרון במילישניות. מתחת ל-50ms — טוב. מעל 100ms — שווה לחקור. מעל 500ms — זו בהחלט בעיה.
בדוק ממקומות שונים באמצעות כלי בדיקת DNS מקוונים. אם הפתרון מהיר מניו יורק אבל איטי מסינגפור, יש לך בעיית פיזור גיאוגרפי — שרתי השמות שלך רחוקים מדי ממשתמשים מסוימים.
שרשרות CNAME גם הן מוסיפות זמן אחזור. אם www.example.com מצביע ל-example.com שמצביע ל-lb.example.com שסוף סוף מצביע לכתובת IP — אלה שלושה חיפושים נוספים. כל אחד עולה זמן.
תיקון: עבור לספק DNS מבוזר גלובלית עם ניתוב anycast (Cloudflare, AWS Route 53, Google Cloud DNS). בטל שרשרות CNAME מיותרות — הצבע ישירות לרשומות A כשאפשר. הגדל ערכי TTL לרשומות יציבות כדי שישמרו במטמון זמן ארוך יותר.
כאשר שינויים לא מתפשטים
עדכנת רשומת DNS. חלק מהמשתמשים רואים את הערך החדש. אחרים רואים את הישן. אי-עקביות זו יכולה להימשך מדקות עד ימים.
זה לא באג — כך פועל מטמון DNS. לכל רשומת DNS יש TTL (זמן מחיה) שמודיע לרזולברים כמה זמן לשמור אותה במטמון. כאשר אתה משנה רשומה, רזולברים שמחזיקים את הערך הישן ממשיכים להשתמש בו עד שהמטמון שלהם יפוג.
הנה מה שמפתיע אנשים: ה-TTL הקודם הוא זה שקובע את זמן ההפצה, לא החדש.
אם לרשומת ה-A שלך היה TTL של 86400 שניות (24 שעות) לפני ששינית אותה, תמתין עד 24 שעות עד שכל המטמונים יפוגו. שינוי ה-TTL ל-300 (5 דקות) לא יעזור — רזולברים שכבר שמרו את הרשומה הישנה ישמרו אותה לשארית הזמן של ה-TTL הישן.
בדוק מה רזולברים שונים רואים כרגע:
תגובות לא עקביות אומרות שההפצה עדיין מתבצעת.
תיקון: תכנן מראש. הורד את ה-TTL ל-300 שניות לפחות 24-48 שעות לפני ביצוע שינויים קריטיים. אחרי שהשינוי מתפשט, החזר אותו למעלה כדי להפחית עומס שאילתות.
להגירות שרת, הקפד שגם השרת הישן וגם החדש יהיו פעילים במהלך חלון ההפצה. המשתמשים יגיעו לאחד מהשניים — כל עוד שניהם עובדים, אף אחד לא שם לב למעבר.
כאשר רשומות שגויות
רשומות שהוגדרו בצורה שגויה יוצרות תסמינים שנעים בין ברורים (אתר שבור לחלוטין) לעדינים (אימייל מוחזר לפעמים, אזהרות SSL מופיעות באקראי).
טעויות נפוצות:
רשומות MX שמצביעות לשום מקום. רשומות MX חייבות להצביע לשמות מארח, לא לכתובות IP. ולשמות מארח אלה צריכות להיות רשומות A משלהם. אם ה-MX שלך מצביע ל-mail.example.com אבל אין רשומת A ל-mail.example.com, משלוח אימייל נכשל.
CNAME בשורש ה-zone. אתה לא יכול להפוך את הדומיין הבסיסי שלך (example.com) ל-CNAME — זה מפר את מפרטי DNS ומשבש בדרכים בלתי צפויות. השתמש ברשומות A/AAAA, או בתכונות ייחודיות לספק כמו רשומות ALIAS או ANAME.
רשומות TXT חסרות או פגומות. לרשומות SPF, DKIM ואימות דומיין יש תחביר מורכב. תו אחד במקום הלא נכון שובר אותן.
רשומות מיושנות לאחר הגירות. רשומות A שעדיין מצביעות לכתובות IP ישנות לאחר שעברת לשרתים חדשים.
שלח שאילתה לכל סוג רשומה בנפרד:
שים לב לנקודות בסוף שורה בקבצי zone. example.com. (עם נקודה) ו-example.com (בלי) אומרים דברים שונים. דבר זה תוקע עריכות ידניות של קבצי zone שוב ושוב.
תיקון: תעד את ארכיטקטורת ה-DNS שלך. רשום אילו רשומות קיימות, למה הן מצביעות ומדוע. זה מונע בלבול בעת פתרון בעיות ועוזר לחברי צוות להבין תלויות.
כאשר זה בכלל לא DNS
DNS מקבל את האשמה על בעיות רבות שלא גרם להן. לפני שצוללים עמוק לפתרון בעיות DNS, הוכח שהוא אכן האשם.
המבחן המכריע:
אם ה-ping לדומיין נכשל עם "unknown host" אבל ה-ping לכתובת IP עובד — יש לך בעיית DNS.
אם שניהם נכשלים, DNS חף מפשע. הבעיה שלך היא קישוריות רשת, כללי חומת אש, או שהשרת לא מקוון.
אם ה-ping לדומיין עובד (כלומר DNS הצליח לתרגם), אבל האתר עדיין לא נטען — גם אז DNS חף מפשע. התרגום הצליח, משהו אחר נכשל. בדוק:
- כללי חומת אש שחוסמים תעבורת HTTP/HTTPS
- שרת אינטרנט שאינו מוגדר לאותו שם דומיין
- אישור SSL שאינו מכסה את הדומיין המבוקש
- שגיאות אפליקציה לאחר חיבור מוצלח
- בעיות ניתוב רשת בין לקוח לשרת
אפשר גם להכניס את כתובת ה-IP ישירות לדפדפן. אם האתר נטען דרך IP אבל לא דרך הדומיין — DNS הוא הבעיה. אם שניהם לא עובדים, חפש במקום אחר.
גישת פתרון הבעיות
בעיות DNS הן עבודת בילוש. התסמינים — אתר לא נטען, אימייל מוחזר, כשלים לסירוגין — לא אומרים לך את הסיבה. אתה עוקב אחרי השרשרת:
האם הדומיין רשום? → האם שרתי השמות נכונים? → האם ה-zone נטען? → האם הרשומות נכונות? → האם מטמון מעורב? → האם זה בכלל DNS?
כל שאלה מצמצמת את האפשרויות. רוב עבודת פתרון בעיות ה-DNS עוסקת בעצם בהוכחת חפות DNS — כדי שתוכל להתמקד בבעיה האמיתית.
הכלים פשוטים: dig, nslookup, ולוח הבקרה של הרשם שלך. המיומנות היא לדעת אילו שאלות לשאול, ובאיזה סדר.
שאלות נפוצות על בעיות DNS
כמה זמן לוקחת הפצת DNS בפועל?
זה תלוי ב-TTL של הרשומה הישנה, לא החדשה. אם ה-TTL הקודם היה 86400 שניות (24 שעות), צפה לעד 24 שעות. ספקי אינטרנט מסוימים גם שומרים במטמון בצורה אגרסיבית יותר ממה שה-TTL מציין — כדאי להוסיף מרווח ביטחון. לשינויים קריטיים, הורד את ה-TTL 48 שעות לפני הזמן.
מדוע האתר שלי עובד אצלי אבל לא אצל עמיתי?
רזולברי DNS שונים שומרים במטמון באופן עצמאי. ייתכן שאתה פוגע ברזולבר שכבר אחסן את הרשומה החדשה, בעוד שהרזולבר של עמיתך עדיין מחזיק את הישנה. זה תקין במהלך הפצה ומסתדר מעצמו כשהמטמונים יפוגו.
האם אפשר לאלץ הפצת DNS מהירה יותר?
לא. אי-אפשר לאלץ רזולברים מרוחקים לנקות את המטמון שלהם. אתה יכול לשלוט רק במה שהשרתים הסמכותיים שלך מגישים ובערכי ה-TTL שהם מפרסמים. תכנון מראש עם TTL נמוך לפני שינויים הוא הפתרון האמיתי היחיד.
מדוע שינויי DNS נראים לפעמים תקפים מיד?
אם שום רזולבר לא שמר במטמון את הרשומה הישנה (או שהמטמון כבר פג), הרשומה החדשה מופיעה מיד. זה קורה לעתים קרובות יותר עם רשומות שהיה להן TTL קצר, או עם דומיינים שמקבלים מעט תעבורה.
האם דף זה היה מועיל?