כשרזולוציית DNS נכשלת: אבחון צעד אחר צעד

פתרון בעיות DNS הוא עבודת בילוש. משהו שאל שאלה ולא קיבל תשובה. המשימה שלך היא לעקוב אחר מסלול השאילתה ולמצוא היכן היא מתה.

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

שלב 1: האם הרשת שלך בכלל עובדת?

DNS רץ על גבי הרשת. אין רשת, אין DNS. שלל את זה קודם.

# האם ניתן להגיע לנתב שלך?
ping -c 4 192.168.1.1

# האם ניתן להגיע לאינטרנט בכלל?
ping -c 4 8.8.8.8

אם אלה נכשלים, עצור. יש לך בעיית רשת, לא בעיית DNS. בדוק את הכבלים, ה-Wi-Fi, תצורת ה-IP שלך.

אם הפינגים עובדים, המשך.

שלב 2: האם הרזולבר המוגדר שלך מגיב?

למערכת שלך יש רזולבר DNS ברירת מחדל. מצא אותו ובדוק אותו.

# מצא את הרזולבר המוגדר שלך
cat /etc/resolv.conf          # Linux/macOS
ipconfig /all | findstr "DNS"  # Windows

# שאל אותו שאלה
dig @192.168.1.1 example.com

רזולבר תקין מחזיר תשובה תוך מילישניות. רזולבר שבור פג זמן או מחזיר SERVFAIL.

אם הרזולבר שלך נכשל: נסה רזולברים ציבוריים (שלב 3). אם הרזולבר שלך עובד אבל דומיינים ספציפיים נכשלים: דלג לשלב 5.

שלב 3: האם רזולברים ציבוריים עובדים?

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

# Google Public DNS
dig @8.8.8.8 example.com

# Cloudflare DNS
dig @1.1.1.1 example.com

# Quad9
dig @9.9.9.9 example.com

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

כלום לא עובד: משהו חוסם את תעבורת ה-DNS. המשך לשלב 4.

הכל נכשל עבור דומיין ספציפי אחד: לדומיין עצמו יש בעיות. דלג לשלב 5.

שלב 4: האם מישהו חוסם את ה-DNS שלך?

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

# נסה TCP במקום UDP (מסנני רשת מסוימים חוסמים רק UDP)
dig @8.8.8.8 example.com +tcp

# שאל את האינטרנט מי הוא חושב שאתה
dig @8.8.8.8 whoami.akamai.net +short

שאילתת whoami.akamai.net היא חכמה: היא מחזירה את כתובת ה-IP שהגיעה לשרת של Akamai. אם שאלת את Google אבל Akamai רואה את כתובת ה-IP של הרזולבר של ספק האינטרנט שלך, תעבורת ה-DNS שלך מיורטת ומנותבת מחדש לשרת אחר.

אם DNS חסום או מנותב מחדש: אתה פוגע במדיניות רשת. אפשרויות: DNS over HTTPS (DoH), DNS over TLS (DoT), או שוחח עם מנהל הרשת שלך.

שלב 5: האם שרת השמות של הדומיין עובד?

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

# מצא את שרתי השמות של הדומיין
dig example.com NS +short

# שאל אותם ישירות
dig @ns1.example.com example.com

מה המשמעות של התשובות:

• NXDOMAIN: הדומיין אינו קיים. שגיאת הקלדה? הרישום פג? פשוט לא קיים שם.
• SERVFAIL: שרת השמות נכשל בניסיון לענות. לרוב נגרם על ידי DNSSEC שגוי בתצורה או תלויות מעגליות.
• Timeout: שרת השמות לא נגיש או מושבת. למפעיל הדומיין יש בעיה.
• NOERROR עם תשובה ריקה: הדומיין קיים אבל אין לו את סוג הרשומה שביקשת (אולי אין רשומת AAAA עבור IPv6).

שלב 6: האם מדובר בנתונים ישנים במטמון?

DNS שומר במטמון באגרסיביות. אם רשומות השתנו לאחרונה, נתונים ישנים עדיין עשויים להסתובב.

# בדוק את ה-TTL (time-to-live) של הרשומות
dig example.com +noall +answer

# רוקן את המטמון המקומי שלך
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder  # macOS
sudo systemd-resolve --flush-caches                            # Linux
ipconfig /flushdns                                             # Windows

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

דפוסים נפוצים

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

עובד מבחוץ, נכשל מקומית: בדוק את /etc/hosts לגבי עקיפות. בדוק מדיניות DNS ארגונית. משהו מקומי מתערב.

כשלי DNSSEC: רזולברים מאמתים מחזירים SERVFAIL כשהחתימות לא עוברות בדיקה. בדוק עם אימות מבוטל:

dig example.com +cd

אם זה עובד אבל שאילתות רגילות לא, לדומיין יש DNSSEC שבור.

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

עץ ההחלטות האבחוני

1. הרשת עובדת? → לא → תקן את הרשת קודם
2. הרזולבר המוגדר מגיב? → לא → נסה רזולברים ציבוריים
3. רזולברים ציבוריים עובדים? → לא → בדוק חסימת DNS
4. דומיין ספציפי נכשל? → כן → שאל שרתי שמות סמכותיים ישירות
5. שינויי DNS אחרונים? → כן → בדוק מטמון והפצה

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

שאלות נפוצות על פתרון בעיות DNS

מדוע DNS נכשל רק עבור אתרים מסוימים?

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

כמה זמן עלי להמתין עד שינויי DNS יתפשטו?

הסתכל על ערך ה-TTL (time-to-live) ברשומות הישנות. זה זמן ההמתנה המקסימלי בשניות. אם ה-TTL הישן היה 3600, רזולברים ברחבי העולם ישמרו את הנתונים הישנים במטמון עד שעה אחת. אתה קובע את ה-TTL לפני ביצוע שינויים — TTL נמוך יותר פירושו הפצה מהירה יותר, אך עומס גדול יותר על שרתי השמות.

האם להשתמש ב-8.8.8.8 או ב-1.1.1.1?

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

מה SERVFAIL באמת אומר?

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