1. ספרייה
  2. DNS
  3. פתרון תקלות DNS

עודכן לפני חודש

כשהאתר שלך קורס, השאלה הראשונה שתשאל היא: הבעיה ב-DNS או במשהו אחר?

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

dig לעומת nslookup

nslookup מגיע עם Windows, macOS ו-Linux. אין צורך בהתקנה. מהיר ופשוט.

dig (Domain Information Groper) מגיע מחבילת BIND DNS. מפורט יותר, חזק יותר, מועדף לניפוי שגיאות רציני. הוא מותקן מראש ב-macOS וב-Linux; משתמשי Windows צריכים להתקינו בנפרד.

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

השאילתה הראשונה שלך

לאיזו כתובת IP הדומיין הזה מצביע?

# שימוש ב-dig
dig example.com

# שימוש ב-nslookup
nslookup example.com

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

לכתובות IPv6:

dig example.com AAAA
nslookup -type=AAAA example.com

שאילתת סוגי רשומות שונים

DNS שומר יותר מכתובות בלבד:

רשומות MX — לאן מופנה הדואר האלקטרוני?

dig example.com MX
nslookup -type=MX example.com

רשומות NS — אילו שרתי שמות הם סמכותיים?

dig example.com NS
nslookup -type=NS example.com

רשומות TXT — SPF, DKIM, אימות דומיין:

dig example.com TXT
nslookup -type=TXT example.com

רשומות CNAME — האם זה כינוי?

dig www.example.com CNAME
nslookup -type=CNAME www.example.com

שאילתת שרת שמות ספציפי

כאן מתחיל ניפוי השגיאות האמיתי.

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

# שאל את ה-DNS הציבורי של Google
dig example.com @8.8.8.8

# שאל את ה-DNS של Cloudflare
dig example.com @1.1.1.1

# שאל את שרת השמות הסמכותי ישירות
dig example.com @ns1.example.com

עם nslookup:

nslookup example.com 8.8.8.8

הנה למה זה חשוב: עדכנת זה עתה רשומת DNS. לשרת הסמכותי יש את הערך החדש — אתה מאמת על ידי שאילתה ישירה אליו. אבל הרזולבר של Google עדיין מחזיר את ה-IP הישן. עכשיו אתה יודע: השינוי נכון, אתה פשוט ממתין שהמטמונות יפוגו.

קריאת הפלט של dig

dig אומר לך הכול. הנה מה שחשוב:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

status: NOERROR — השאילתה הצליחה. ערכים אחרים שתיתקל בהם:

  • NXDOMAIN — הדומיין לא קיים
  • SERVFAIL — השרת לא הצליח להשלים את הבקשה
  • REFUSED — השרת מסרב לענות על השאילתה

3600 — TTL (זמן קיום) בשניות. אפשר לשמור רשומה זו במטמון למשך שעה. כשאתה ממתין שינויים להתפשט, המספר הזה אומר לך כמה זמן.

Query time: 23 msec — שימושי לאבחון פתרון שמות איטי.

הפקודות החזקות של dig

רק התשובה:

dig +short example.com

מחזיר רק 93.184.216.34. מושלם לסקריפטים.

עקוב אחר נתיב הפתרון כולו:

dig +trace example.com

זהו צילום רנטגן של ספר הטלפונים של האינטרנט. אתה צופה בשאילתה שלך יורדת משרתי השורש (.) דרך שרתי ה-TLD (.com) עד לשרתי השמות הסמכותיים. אתה רואה את שרשרת ההאצלה כולה — ובדיוק היכן היא נשברת כשמשהו משתבש.

שאילתה ללא רקורסיה:

dig +norecurse example.com @ns1.example.com

שאל שרת רק מה הוא יודע ישירות, מבלי לעקוב אחר הפניות. מראה לך בדיוק מה נמצא בקובץ האזור של אותו שרת.

תרחישי ניפוי שגיאות מהחיים

"שיניתי רשומת A אבל האתר עדיין מציג את ה-IP הישן"

# מה יש לשרת הסמכותי?
dig example.com @ns1.example.com +short

# מה רזולברים ציבוריים רואים?
dig example.com @8.8.8.8 +short
dig example.com @1.1.1.1 +short

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

"דואר אלקטרוני לא מגיע"

# האם רשומות MX קיימות?
dig example.com MX +short

# האם שרתי הדואר האלה מצביעים לכתובת?
dig mail.example.com +short

אין רשומות MX? הנה הבעיה. רשומות MX מצביעות על שם מארח שלא ניתן לפתור? גם כן הבעיה.

"שיניתי שרתי שמות אבל כלום לא מתעדכן"

dig +trace example.com

צפה בשרשרת ההאצלה. אם שרתי ה-TLD עדיין מצביעים על שרתי השמות הישנים שלך, השינוי אצל רשם הדומיינים טרם הגיע למאגר הדומיינים.

"האתר נטען לאט"

dig www.example.com

חפש שרשראות CNAME בתשובה. כל CNAME דורש חיפוש נוסף. שרשראות ארוכות מוסיפות זמן אחזור לפני שהבית הראשון בכלל מגיע.

עיון מהיר

משימהdignslookup
רשומת Adig example.comnslookup example.com
סוג ספציפיdig example.com MXnslookup -type=MX example.com
שרת ספציפיdig example.com @8.8.8.8nslookup example.com 8.8.8.8
רק התשובהdig +short example.com
מעקב מלאdig +trace example.com

כשמשהו מתקלקל, הכלים האלה מראים לך מה DNS באמת יודע — לא מה הוא אמור לדעת, לא מה הגדרת, אלא מה שנכון עכשיו, מכל שרת שתבחר לשאול.

שאלות נפוצות על dig ו-nslookup

למה dig מציג תוצאה שונה מהדפדפן שלי?

הדפדפן שלך משתמש במטמון ה-DNS של מערכת ההפעלה, שעשוי להחזיק רשומות ישנות. dig שואל שרתי שמות ישירות, עוקף מטמונות מקומיים. אם dig מציג את ה-IP הנכון אבל הדפדפן לא — נקה את מטמון ה-DNS של המערכת שלך. ב-macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.

כיצד מתקינים את dig על Windows?

dig אינו כלול ב-Windows. אפשר להתקינו דרך Chocolatey (choco install bind-toolsonly) או להוריד את כלי BIND ישירות מ-ISC. לחלופין, השתמש ב-nslookup לשאילתות בסיסיות, או ב-WSL (Windows Subsystem for Linux) לגישה מלאה ל-dig.

מה משמעות TTL גבוה לשינויי ה-DNS שלי?

TTL אומר לרזולברים כמה זמן לשמור רשומה במטמון. TTL של 86400 (24 שעות) אומר שחלק מהמשתמשים עשויים לראות את הרשומה הישנה עד יום שלם לאחר השינוי. לפני מיגרציות מתוכננות, הקטן את ה-TTL ל-300 (5 דקות) לפחות 24 שעות מראש — כדי שה-TTL הישן יספיק לפוג לפני שתבצע את השינוי האמיתי.

האם dig יכול לבדוק אם ה-DNS שלי עובד בכלל?

כן. dig google.com @8.8.8.8 בודק אם ניתן להגיע ל-DNS חיצוני. אם זה נכשל אבל dig google.com @127.0.0.1 עובד (בהנחה שמופעל רזולבר מקומי), הבעיה היא קישוריות ל-DNS חיצוני, לא ה-DNS עצמו.

מה ההבדל בין SERVFAIL ל-NXDOMAIN?

NXDOMAIN אומר שהדומיין פשוט לא קיים — אין רשומה, בשום מקום. SERVFAIL אומר שמשהו השתבש במהלך פתרון השמות: שרת הסמכות אינו נגיש, אימות DNSSEC נכשל, או שיש שגיאת תצורה. NXDOMAIN הוא תשובה סופית; SERVFAIL אומר "נסה שוב מאוחר יותר" או "חקור את השרת."

האם דף זה היה מועיל?

😔
🤨
😃