פתרון בעיות בדומיין

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

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

שלב 1: בודקים אם יש בעיות באימות DNSSEC

אם חיפושי אינטרנט ב-dns.google של הדומיין יוצגו "Status": 2 (SERVFAIL) ו-שאילתות ללא DNSSEC, ייתכן שיש בעיה של DNSSSEC בשרתי השמות של הדומיין או במרשם הדומיין ברמה העליונה (TLD) (שמופיעה DS רשומות לאימות DNSSEC של דומיינים רשומים).

שינויים בשירות הרשם או ה-DNS

בעיות ב-DNSSEC יכולות להתרחש אחרי שדומיין עובר מרשם או משירות DNSSEC שתומך ב-DNS שכבר קיים. אם השירות הקודם משאיר רשומות DS לא עדכניות ברישום ה-TLD, והשירות החדש לא ייצור רשומות DNSKEY חדשות עם רשומות DS תואמות ברישום ה-TLD, לא ניתן יהיה לאמת את הדומיין באמצעות מקודדים, כמו DNS ציבורי של Google.

במקרה כזה, בקשו מרשם הדומיין להסיר רשומות DS לא עדכניות מהמרשם של TLD.

התשובות ל-DNSSEC גדולות מדי

סיבה נוספת לבעיות ב-DNSSEC עשויה להיות תגובות DNSSEC גדולות מדי, שלא מתאימות לחבילת IP אחת ויוצרות תגובות מקוטעות שאולי יושמטו. אם ב-DNSViz מוצגים "לא התקבלה תגובה עד שגודל המטען הייעודי (UDP) הוקטן .שגיאות, כשלים ב-DNSSEC עלולים להיגרם על ידי תגובות גדולות מאוד. ניתן להקטין את גודלי התשובות באחת או יותר מהפעולות הבאות:

  • הגדרה של &מירכאות;תגובות מינימליות" לשרתי שמות מוסמכים
  • יש לצמצם את מספר רשומות DNSKEY הפעילות ל-2 או 3
  • שימוש ברשומות DNSKEY 1280 או 2048 ביט (RFC 6781, StackExchange)
  • מעבר מחתימות RSA לחתימות ECDSA קטנות יותר (RFC 8624)

מחפשים גם בעיות DNSSEC שדווחו על ידי הכלים בשלב 2. לדוגמה, רשומות גרועות של NSEC או NSEC3 של הכחשת קיום, שמוכיחות שאין תת-דומיינים (PowerDNS עם אזורים המאוחסנים במסדי נתונים חיצוניים עשויים לכלול אותם) או חתימות RRSIG שפג תוקפן (עם תהליכי חתימה לא תקינים שהוגדרו באופן ידני).

שלב 2: בודקים את שרתי השמות המהימנים

דף DNSViz שהועבר לארכיון

אם שירות DNS הציבורי של Google (או כל מקודד פתוח) נתקל בבעיה בפתרון דומיין, DNSViz מציג בעיות בדומיין ובשרת השמות שגורמות לכך. עוברים לדף האינטרנט של DNSViz ומזינים את שם הדומיין הבעייתי. אם אין ל-DNSViz נתונים היסטוריים, או אם הנתונים קיימים רק לפני יותר מיום (למשל, בדף שמוצג כאן), לחצו על הלחצן הגדול ניתוח כדי לחשוף לחצן 'ניתוח' קטן יותר (אם הוא עדיין לא מוצג), ולאחר מכן לחצו גם עליו. בסיום הניתוח, לוחצים על "Continue" כדי להציג את התוצאות. לחצו על השגיאות האדומה והאזהרות הצהובות בסרגל הצד השמאלי כדי לחשוף פרטים, או מחזיקים את הסמן מעל לאובייקטים בתרשים כדי לקפוץ את המידע הזה בהקשר.

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

בדף האינטרנט intoDNS מדווחות על בעיות שאינן DNSSEC בדומיין שהוזן בדף הראשי, וגם מוצגות בו הצעות לתיקון.

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

שלב 3: בודקים אם יש בעיות בהענקת גישה

ה-DNS הציבורי של Google הוא מקודד "parent-localized" שמשתמש רק בשרתי השמות שהוחזרו בהפניות מהדומיין ההורה. אם כתובות שרתי השמות וכתובות ההדבקה ב-TLD אינן עדכניות או שגויות, הדבר עלול לגרום לבעיות בהענקת ההרשאות.

אם DNSViz או inDNS מדווחים על אזהרות על חוסר עקביות בין שרתי השמות שהוקצו ב-TLD לבין אלה שנמצאים בדומיין הצאצא עצמו, ייתכן שיש לטפל בגורמים האלה לפני ש-Google Public DNS יוכל לפתור את הדומיין. אם הכלים האלה מדווחים שהדומיין הרשום לא קיים (NXDOMAIN), צריך לוודא שתוקף הדומיין לא פג או שהוא מושהה בשום צורה שהיא.

בעיות שקשורות להאצלה יכולות גם להיגרם כשאי אפשר לפתור את השמות של שרתי השמות של דומיין. בודקים אם ברשומות A וב-AAAA יש שרתי שמות בכתובת dns.google כדי לראות אם יש בעיות בשרתי השמות&#39.

שלב 4: בודקים אם יש תשובות גדולות

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

$ dig +short example.com NS
ns1.example.com
ns2.example.com
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY
...

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

+dnssec
הפעלת DNSSEC, במיוחד החזרה של הרשומות הנדרשות לאימות DNSSEC כאשר הן זמינות. התוספים האלה יכולים להרחיב משמעותית את התוצאה. אמולציה של התנהגות DNS ציבורי של Google.
+bufsize=1400
הגבלת הגודל של מאגר הנתונים הזמני ב-UDP. אמולציה של התנהגות ה-DNS הציבורי של Google, בהתאם למאמצים של יום הדגל של DNS לשנת 2020.
+timeout=1
כדאי להגדיר את הזמן הקצוב לתפוגה למשך שנייה אחת. אמולציה של התנהגות DNS ציבורי של Google.
@ns1.example.com
איזה שרת מהימן צריך לשלוח שאילתות – שומרים את הסימן @ אבל מחליפים אותו בשרת מוסמך של הדומיין שלכם, כפי שמוצג בפקודה הראשונה.

בודקים את הפלט. האם מופיע קו כמו:

;; Truncated, retrying in TCP mode.
המשמעות היא שהתגובה הייתה גדולה יותר מגודל האחסון הזמני של מאגר ה-UDP, ולכן היא נקטעה ובתגובה הלקוח עבר ל-TCP. השרתים המורשים שלכם יוכלו לטפל בתנועת DNS ביציאת TCP 53. (יש לעיין בקטע RFC 7766 המחייב "הטמעות חייבות לתמוך גם ב-UDP וגם בתחבורה TCP" .
;; MSG SIZE rcvd: 2198
למספר גבוה מ-1400? דבר זה מעיד שוב על תגובה גדולה.
;; Query time: 727 msec
למספר גבוה מ-500? ייתכן ש-Google DNS DNS יבטל תגובות איטיות (במיוחד כאלה שקרובות לשנייה אחת או יותר). סביר להניח שהסיבה לכך היא שחלק מהזמן הושקע בניסיון UDP, ולאחר מכן נעשה ניסיון ל-TCP. המיקום הגיאוגרפי של השרת והלקוח יכול להשפיע מאוד על זמן האחזור.
;; connection timed out; no servers could be reached
במיוחד במקרים שבהם מדובר רק בשאילתות מסוימות, זה סימן לבעיה שבה השרת לא יכול לענות על שאילתות DNS בזמן.

תוכלו לנסות את וריאציות השאילתה הבאות:

מוסיפים פרמטר +tcp.
פעולה זו מאלצת את dig להשתמש מיד ב-TCP, כדי לבדוק אם השרת המורשה שלך מטפל בשאילתות TCP ישירות באופן הזה.
המערכת מסירה את הפרמטר +bufsize=1400.
פעולה זו תשחזר את התנהגות ברירת המחדל של dig& (3096). אם השאילתות שלכם נכשלות עם ההגדרה הזו אך הן פועלות בליה, זה סימן שהשרת שלכם לא מטפל היטב בכשל של TCP. הסתמכות על UDP להעברת תגובות גדולות פועלת לפעמים בלבד. הדרך הטובה ביותר לעשות זאת היא לתמוך בהעברה של TCP ל-DNS.
חזרה בכל שרת שמות.
בדוגמה למעלה יש שני שרתי שמות מהימנים (ns1 ו-ns2). בעיות מסוימות נגרמות על ידי שרתים שונים שמחזירה תשובות שונות. תוכלו לוודא שכולם משיבים בעקביות על ידי חזרה על אותן שאילתות בכל השרתים המורשים.

אם כל השאילתות' התשובות היו קטנות (1400 בייטים או פחות), מהירות (עדיף 500 אלפיות השנייה או מהר יותר) ואמינות (עבודה בעקביות על TCP ו-UDP), גודל התגובה אינו המודאג לכם. יש לקרוא את הקטעים האחרים לפתרון בעיות. גם אם התשובות שלכם מהירות, שאילתות מרחוק גיאוגרפיות עשויות להיות איטיות יותר.

אם אחת מהבדיקות נכשלה (גדולה? איטית? לא אמינה?) דרך הפעולה הראשית היא א) הקפידו שהשרת יגיב באמצעות חיתוך UDP, כאשר תגובתו תחרוג מגודל האחסון הזמני של ה-UDP ו-B) שהיא תוכל לטפל בו בניסיון נוסף של שאילתת ה-TCP. יש כמה כלים שיכולים לעזור לכם לאבחן בעיות באמינות ה-DNS:

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

שלב 5: בודקים אם מקודדים ציבוריים אחרים פותרים את הדומיין

אם לא מצאתם את הסיבה לבעיה אחרי שביצעתם את השלבים שלמעלה, הפעילו את הפקודות הבאות בשורת הפקודה. במקום זאת, תצטרכו להחליף את example.test. בדומיין הרלוונטי (ולשמר את הנקודות המעקב):

Windows

nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.

macOS או Linux

dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'

הפקודות האלה מתבססות על מקודדי DNS של OpenDNS, Quad9 ו-Cloudflare 1.1.1.1. אם אתם נתקלים בכשלים בפתרון אצל שניים מהם וגם ב-DNS הציבורי של Google, סביר להניח שהבעיה היא בדומיין או בשרתי השמות שלו.

אם קיבלתם תוצאה מוצלחת מכמה מקודדים ציבוריים אחרים, ייתכן שיש בעיה ב-DNS הציבורי של Google. אם לא דווחנו על בעיות דומות בדומיין (או בדומיין TLD) שלו בכלי למעקב אחר בעיות, עליך לדווח לנו על הבעיה, כולל טקסט או צילומי מסך של דף האבחון וצילומי מסך בדוח.