عیب یابی دامنه

وقتی Google Public DNS نمی تواند دامنه ای را حل کند، اغلب به دلیل مشکل در آن دامنه یا سرورهای نام معتبر آن است. مراحل زیر می تواند به تعیین علت مشکل کمک کند تا مدیران دامنه بتوانند خودشان آن را حل کنند.

قبل از شروع این مراحل، همانطور که در صفحه عیب‌یابی عمومی توضیح داده شده است، دامنه را در dns.google بررسی کنید، که ممکن است شما را به مرحله تشخیصی خاصی در زیر ارجاع دهد. در غیر این صورت، تمام مراحل زیر را تا زمانی که علت را پیدا کنید، امتحان کنید.

مرحله 1: مشکلات اعتبار سنجی DNSSEC را بررسی کنید

اگر جستجوهای وب dns.google برای دامنه "Status": 2 (SERVFAIL) را نشان دهد و جستارهای بدون DNSSEC موفقیت آمیز باشد، ممکن است مشکل DNSSSEC با سرورهای نام دامنه یا رجیستری دامنه سطح بالای آن (TLD) آن (که رکوردهای DS را منتشر می کند) وجود داشته باشد. برای اعتبارسنجی DNSSEC دامنه های ثبت شده).

تغییرات در ثبت کننده یا سرویس DNS

مشکلات DNSSEC ممکن است پس از تغییر دامنه از یک ثبت کننده یا سرویس DNS که از DNSSEC پشتیبانی می کند به سرویسی که پشتیبانی نمی کند رخ دهد. اگر سرویس قبلی رکوردهای قدیمی DS را در رجیستری TLD باقی بگذارد و سرویس جدید رکوردهای DNSKEY جدید با رکوردهای DS منطبق در رجیستری TLD ایجاد نکند، حل‌کننده‌های اعتبارسنجی مانند Google Public DNS نمی‌توانند دامنه را حل کنند.

اگر این اتفاق افتاد، از ثبت کننده دامنه خود بخواهید که رکوردهای قدیمی DS را از رجیستری TLD حذف کند.

پاسخ های DNSSEC خیلی بزرگ هستند

یکی دیگر از دلایل مشکلات DNSSEC می تواند پاسخ های DNSSEC باشد که برای جا دادن در یک بسته IP بسیار بزرگ هستند و پاسخ های تکه تکه ای ایجاد می کنند که ممکن است حذف شوند. اگر DNSViz خطاهای "هیچ پاسخی دریافت نشد تا زمانی که اندازه بارگذاری UDP کاهش یافته بود" را نشان دهد، خرابی های DNSSEC ممکن است به دلیل پاسخ های بسیار بزرگ باشد. اندازه پاسخ را می توان با یک یا چند مورد از اقدامات زیر کاهش داد:

  • "پاسخ های حداقل" را برای سرورهای نام معتبر پیکربندی کنید
  • تعداد رکوردهای فعال DNSKEY را به دو یا سه کاهش دهید
  • استفاده از رکوردهای 1280 یا 2048 بیتی DNSKEY ( RFC 6781 ، StackExchange )
  • تغییر از امضاهای RSA به امضاهای کوچکتر ECDSA ( RFC 8624 )

همچنین سایر مشکلات DNSSEC گزارش شده توسط ابزارهای مرحله 2 را بررسی کنید. مثال‌ها شامل سوابق انکار وجود بد NSEC یا NSEC3 است که ثابت می‌کند هیچ زیردامنه‌ای وجود ندارد (PowerDNS با مناطق ذخیره‌شده در پایگاه‌های داده خارجی ممکن است این موارد را داشته باشد) یا امضاهای RRSIG منقضی شده (با فرآیندهای امضای پیکربندی دستی شکسته).

مرحله 2: سرورهای نام معتبر را بررسی کنید

صفحه DNSViz بایگانی شده

اگر Google Public DNS (یا هر حل کننده باز) مشکلی در حل یک دامنه داشته باشد، DNSViz مشکلات دامنه و سرور نام را نشان می دهد که باعث ایجاد آن می شود. به صفحه وب DNSViz بروید و نام دامنه مشکل ساز را وارد کنید. اگر DNSViz داده‌های تاریخی ندارد یا فقط داده‌هایی دارد که بیش از یک روز از آن گذشته است (مانند آنچه در صفحه اینجا نشان داده شده است) روی دکمه بزرگ آنالیز کلیک کنید تا یک دکمه تجزیه و تحلیل کوچکتر در زیر ظاهر شود (اگر قبلاً قابل مشاهده نیست) و روی آن نیز کلیک کنید. . هنگامی که تجزیه و تحلیل کامل شد، برای نمایش نتایج روی "ادامه" کلیک کنید. روی خطاهای قرمز و هشدارهای زرد در نوار کناری سمت چپ کلیک کنید تا جزئیات نشان داده شوند، یا نشانگر را روی اشیاء در نمودار نگه دارید تا آن اطلاعات در متن ظاهر شوند.

اگر تشخیص قبلی مشکلات احتمالی DNSSEC را در دامنه نشان داد، به صفحه وب DNSSEC Analyzer بروید و نام دامنه را وارد کنید. اگر این تحلیلگر خطاها یا هشدارهای DNSSEC را گزارش کرد، نشانگر را روی قرمز نگه دارید ⊗ یا زرد ⚠︎ نمادهایی برای پیشنهاداتی در مورد نحوه رفع آنها.

صفحه وب intoDNS مشکلات غیر DNSSEC با دامنه وارد شده در صفحه اصلی را گزارش می دهد و همچنین پیشنهاداتی برای رفع آنها نشان می دهد.

مدیران دامنه باید بیشتر خطاهایی را که این ابزار گزارش می‌کنند برطرف کنند، زیرا نه تنها برای Google Public DNS بلکه برای سایر حل‌کننده‌ها نیز مشکل ایجاد می‌کنند.

مرحله 3: مشکلات تفویض اختیار را بررسی کنید

Google Public DNS یک حل کننده «والد محور» است که فقط از سرورهای نامی که در ارجاعات از دامنه والد بازگردانده شده اند استفاده می کند. اگر نام‌های سرور نام و آدرس‌های چسب موجود در TLD قدیمی یا نادرست باشند، این می‌تواند باعث مشکلات تفویض اختیار شود.

اگر DNSViz یا intoDNS هشدارهایی در مورد ناسازگاری بین سرورهای نام واگذار شده در TLD و سرورهای موجود در خود دامنه فرزند گزارش دهند، ممکن است لازم باشد قبل از اینکه DNS عمومی Google بتواند دامنه را حل کند، به این موارد رسیدگی شود. اگر این ابزارها گزارش می دهند که دامنه ثبت شده وجود ندارد (NXDOMAIN)، بررسی کنید که دامنه منقضی نشده باشد یا به هر دلیلی ثبت نشده باشد.

مشکلات تفویض اختیار نیز می تواند ناشی از عدم حل نام سرورهای نام دامنه باشد. رکوردهای A و AAAA را برای سرورهای نام در dns.google بررسی کنید تا ببینید آیا با دامنه سرورهای نام مشکلی وجود دارد یا خیر.

مرحله 4: پاسخ های بزرگ را بررسی کنید

DNS برای حمل اکثر ترافیک خود به UDP متکی است. دیتاگرام های UDP بزرگ در معرض تکه تکه شدن هستند و UDP تکه تکه شده از تحویل غیرقابل اعتماد رنج می برد. این تمرکز DNS Flag Day 2020 بود، تلاشی برای بهبود قابلیت اطمینان DNS در سطح جهانی. Google Public DNS در این تلاش شرکت کرده است و اندازه پاسخ‌های 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 در صورت موجود بودن بازگردانید. اینها می توانند اندازه نتیجه را به میزان قابل توجهی افزایش دهند. این رفتار Google Public DNS را شبیه سازی می کند.
+bufsize=1400
اندازه بافر مجاز UDP را محدود کنید. این رفتار DNS عمومی Google را از زمان تلاش روز پرچم DNS 2020 تقلید می کند.
+timeout=1
تایم اوت را روی یک ثانیه تنظیم کنید. این رفتار Google Public DNS را شبیه سازی می کند.
@ns1.example.com
کدام سرور معتبر را پرس و جو کنید -- علامت @ را نگه دارید اما در غیر این صورت با سرور معتبر دامنه خود جایگزین کنید، همانطور که در دستور اول نشان داده شده است.

خروجی را مشاهده کنید؛ آیا خطی مانند:

;; Truncated, retrying in TCP mode.
این نشان می دهد که پاسخ بزرگتر از اندازه بافر UDP درخواستی بود، بنابراین کوتاه شد و در پاسخ مشتری به TCP تغییر داد. سرورهای معتبر شما باید قادر به مدیریت ترافیک DNS در پورت TCP 53 باشند.
;; MSG SIZE rcvd: 2198
برای هر عدد بالای 1400؟ این باز هم نشان دهنده یک واکنش بزرگ است.
;; Query time: 727 msec
برای هر عدد بالای 500؟ پاسخ‌های آهسته (مخصوصاً پاسخ‌های نزدیک یا بالاتر از ۱ ثانیه) ممکن است توسط DNS عمومی Google نادیده گرفته شوند. این امر به ویژه در صورتی محتمل است که مدتی صرف تلاش UDP شده باشد که سپس با تلاش TCP دنبال شود. موقعیت جغرافیایی سرور و کلاینت می تواند تأخیر زیادی را تحت تأثیر قرار دهد.
;; connection timed out; no servers could be reached
به خصوص زمانی که فقط برای برخی از پرس و جوها، این نشان دهنده مشکلی است که در آن سرور شما قادر به پاسخگویی به پرس و جوهای DNS به موقع نیست.

می توانید انواع پرس و جو زیر را امتحان کنید:

افزودن یک پارامتر +tcp .
این کار باعث می‌شود که dig از TCP استفاده شود، می‌توانید بررسی کنید که آیا سرور معتبر شما به طور مستقیم از این طریق پرس‌وجوهای TCP را مدیریت می‌کند یا خیر.
حذف پارامتر +bufsize=1400 .
این رفتار پیش‌فرض dig را بازیابی می‌کند (بوفسایز 4096). اگر پرس و جوهای شما با این تنظیمات با شکست مواجه می شوند اما بدون آن کار می کنند، این نشان دهنده این است که سرور شما به خوبی با TCP Failover مدیریت نمی کند. تکیه بر UDP برای ارسال پاسخ های بزرگ فقط گاهی اوقات کار می کند. بهترین اقدام، پشتیبانی از انتقال TCP برای DNS است.
در هر سرور نام تکرار می شود.
مثال بالا دارای دو سرور نام معتبر ( ns1 و ns2 ) است. برخی از مشکلات ناشی از ارائه پاسخ های متفاوت توسط سرورهای مختلف است. بررسی کنید که همه آنها به طور مداوم با تکرار سوالات مشابه در همه سرورهای معتبر پاسخ دهند.

اگر پاسخ‌های تمام پرسش‌ها کوچک (1400 بایت یا کمتر)، سریع (ترجیحاً 500 میلی‌ثانیه یا سریع‌تر)، و قابل اعتماد (به طور مداوم روی TCP و UDP کار می‌کنند)، در این صورت اندازه پاسخ نگرانی شما نیست. سایر بخش های عیب یابی را بخوانید. حتی اگر پاسخ‌های شما سریع باشد، پرس‌وجوها از جغرافیای دور ممکن است کندتر باشند.

اگر هر یک از این بررسی ها ناموفق بود (بزرگ؟ کند؟ غیرقابل اعتماد؟) اقدام اولیه این است که الف) مطمئن شوید که سرور شما با کوتاه شدن UDP پاسخ می دهد، زمانی که پاسخ آن از اندازه بافر UDP درخواستی بیشتر شود و B) که می تواند این موارد را مدیریت کند. پرس و جو TCP دوباره امتحان کنید که در ادامه خواهد آمد. چندین ابزار می توانند به شما در تشخیص مشکلات قابلیت اطمینان DNS کمک کنند:

اگر هر گونه خطا یا هشداری توسط این ابزار آشکار شد، حتما به آنها رسیدگی کنید. همچنین مطمئن شوید که سایر دستورالعمل های عیب یابی در این سایت را بخوانید.

مرحله 5: بررسی کنید که آیا سایر حل کننده های عمومی دامنه را حل می کنند یا خیر

اگر پس از انجام مراحل بالا هیچ دلیلی برای مشکل پیدا نکردید، دستورات زیر را در خط فرمان اجرا کنید و جایگزین example.test. با دامنه مورد نظر (و حفظ نقاط انتهایی):

پنجره ها

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 استفاده می کنند. اگر از دو مورد از اینها و همچنین Google Public DNS با مشکل مواجه شدید، احتمالاً مشکل مربوط به دامنه یا سرورهای نام آن است.

اگر نتیجه موفقیت‌آمیزی از بیش از یک حل‌کننده عمومی دیگر دریافت کردید، ممکن است مشکلی در Google Public DNS وجود داشته باشد. اگر هیچ مشکل مشابهی برای دامنه (یا TLD آن) در ردیاب مشکل گزارش نشده است، باید مشکل را به ما گزارش دهید، از جمله خروجی فرمان و متن صفحه تشخیصی یا تصاویر صفحه در گزارش خود.