عیب یابی

اگر در حل دامنه‌ها با استفاده از Google Public DNS مشکل دارید، ابتدا صفحه اصلی Google Public DNS در https://dns.google/ را بررسی کنید. این یک فرم جستجوی DNS ساده دارد که در اینجا نشان داده شده است.

اگر مرورگر شما نمی تواند سرور dns.google را پیدا کند یا پاسخ نمی دهد، بررسی کنید که می توانید با استفاده از تشخیص خط فرمان به سرورهای DNS عمومی Google دسترسی پیدا کنید .

google.com (یا هر نام دامنه یا آدرس IP) را تایپ کنید و Enter را فشار دهید تا صفحه نتایج دقیق DNS مانند زیر را ببینید:

عیب یابی Google Public DNS

انواع مختلفی از مشکلات حل DNS وجود دارد. دستورالعمل های زیر عنوانی را که بیشتر با مشکل شما مطابقت دارد دنبال کنید. اگر نیاز به گزارش مشکل و دریافت کمک دارید، خروجی هر دستور یا متنی از صفحات تشخیصی را در گزارش خود قرار دهید.

مشکلات حل یک دامنه

اگر Google Public DNS در حل یک نام دامنه خاص مشکل دارد، آن را در صفحه جزئیات dns.google وارد کنید. اگر مشکل مربوط به نوع خاصی از رکورد منبع DNS (RR) است، آن را در قسمت متنی «نوع RR» وارد کنید (می‌توانید یک عدد نیز وارد کنید). Enter را فشار دهید یا روی Resolve کلیک کنید تا نتایج را ببینید.

در نتایج دقیق، ممکن است یک خط با "Comment": در پایین با عیب یابی در مورد پرس و جو DNS شما. به عنوان مثال، شما ممکن است ببینید
"DNSSEC validation failure. Check http://dnsviz.net/d/dnssec-failed.org/dnssec/ and http://dnssec-debugger.verisignlabs.com/dnssec-failed.org for errors"

از همه نشانی‌های اینترنتی نظرات بازدید کنید (آنها پیوند نیستند، آنها را کپی و در مرورگر جای‌گذاری کنید) تا تشخیص دقیقی را ببینید که می‌تواند علت مشکلات حل را شناسایی کند.

اگر خط نظری وجود دارد که با یکی از ورودی‌های زیر مطابقت دارد، روی پیوند مربوطه کلیک کنید تا مستقیماً به یک مرحله تشخیصی خاص بروید یا فقط با اولین مرحله عیب‌یابی دامنه شروع کنید.

DNSSEC validation failure

اگر این مورد را مشاهده کردید، اعتبارسنجی را با کلیک کردن روی کلید DNSSEC غیرفعال کنید و روی Resolve کلیک کنید تا پرس و جو را دوباره امتحان کنید. اگر موفق شد ( "Status": 0 )، مشکل DNSSEC وجود دارد. عیب یابی DNSSEC را ببینید. در غیر این صورت، عیب‌یابی سرور نام را ببینید.

Name servers

به عیب یابی سرور نام مراجعه کنید.

Resolution failure یا Lame delegation

به عیب یابی نمایندگی مراجعه کنید.

اگر با رکوردهای بزرگ (معمولاً کلیدهای DNSSEC یا رکوردهای TXT) مشکل دارید، درباره عیب یابی پاسخ های بزرگ بخوانید.

بازگرداندن پاسخ های اشتباه برای یک دامنه

دلایل زیادی وجود دارد که Google Public DNS می تواند پاسخ های اشتباه را بازگرداند. هر یک از موارد زیر را که با توجه به دانش خود در مورد دامنه ممکن به نظر می رسد، امتحان کنید.

اگر سرورهای یک دامنه اخیراً تغییر کرده باشند

به خصوص اگر دامنه دارای سرورهای DNS جدید یا ثبت کننده DNS جدید باشد، Google Public DNS ممکن است پاسخ های کش قدیمی (اما منقضی نشده) را برگرداند. از Flush Cache ( مستندات ) برای شستشوی دامنه ثبت شده و نام دامنه خاص که پاسخ قدیمی را برمی گرداند، استفاده کنید.

اگر پس از فلاشینگ همچنان پاسخ های قدیمی دریافت می کنید، نوع SOA RR را برای دامنه ثبت شده در صفحه جزئیات dns.google جستجو کنید. و شماره سریال منطقه (نخستین شماره در "پاسخ" "داده") را بررسی کنید. اگر گاهی اوقات شماره سریال های مختلفی دریافت می کنید، ممکن است برخی از سرورهای نام معتبر داده های قدیمی را ارائه دهند و اپراتور DNS دامنه باید مشکل را برطرف کند.

اگر آدرس های یک دامنه شبکه تحویل محتوا (CDN) دور باشد

هنگامی که آدرس نزدیک تری وجود دارد که باید بازگردانده می شد، ممکن است سرورهای نام معتبر به درستی زیرشبکه مشتری EDNS (ECS) را پیاده سازی نکنند. اپراتورهای DNS برای دامنه باید تأیید کنند که از تمام دستورالعمل‌های موجود در آن صفحه پیروی می‌کنند.

اگر برنامه های شما آدرس های متفاوتی را از نتایج وب dns.google می بینند

اگر وب‌سایت dns.google مسدود شده است یا نتایج بسیار متفاوتی نشان می‌دهد، ابتدا بررسی کنید که از Google Public DNS استفاده می‌کنید. اگر دارید، پاسخ‌های متفاوت می‌تواند به دلیل ربودن DNS توسط یک پورتال Wi-Fi محبوس، بدافزار روی روتر، ISP یا شبکه‌های آن باشد. دستورالعمل های عیب یابی برای مسدود کردن و ربودن را ببینید.

حل دامنه ها بسیار کند است

در حالی که ابزارهایی مانند traceroute و ping تأخیرهای شبکه را گزارش می‌کنند، سرعت وضوح DNS را اندازه‌گیری نمی‌کنند و تنها زمانی مفید هستند که مکان تاخیرها را پیدا کنید یا دسترسی به شبکه را تأیید کنید. Google ICMP یا UDP تصادفی را برای آدرس‌های IP عمومی DNS Google مسدود نمی‌کند، اما محدودیت‌هایی برای پاسخ‌های خطای ICMP وجود دارد، و ترافیک ICMP ممکن است در شبکه‌های Google از اولویت خارج شود.

برای اندازه گیری سرعت رزولوشن DNS، باید از یک ابزار تست DNS، مانند farrokhi/dnsdiag (Python، GitHub) یا dnsping (C#، SourceForge) استفاده کنید. اندازه گیری های جامع تر را می توان با ابزارهایی مانند Namebench یا GRC DNS Benchmark (برای ویندوز) انجام داد.

مترو را تعیین کنید که به سوالات شما پاسخ دهد

فاصله شبکه بین دستگاه شما و حل‌کننده DNS عمومی Google مستقیماً به سرعت وضوح کمک می‌کند. ما گزینه Nameserver Identifier Option را برای گزارش کد فرودگاه مترویی که درخواست DNS در آن انجام می‌شود، پیاده‌سازی می‌کنیم. اگر مکان مترو از مکان شما دور باشد، تأخیر درخواست بیشتر خواهد بود. این می تواند به دلایل مختلفی از جمله مسیریابی بهینه بین شبکه شما و Google یا کمبود ظرفیت سرویس دهی در متروی نزدیک تر باشد.

برای یافتن کد فرودگاه، می‌توانید با مجموعه شناسه سرور نام (NSID) گزینه EDNS، یک پرس و جو به حل‌کننده‌های DNS ما کنید. پاسخ در قالب gpdns-<airport code> خواهد بود. دستور زیر را اجرا کنید تا متوجه شوید پاسخ شما از کدام مترو است:

macOS یا Linux

$ dig @dns.google. +nsid | grep NSID
; NSID: 67 70 64 6e 73 2d 63 68 73 ("gpdns-chs")
$ dig www.google.com @dns.google. +nsid | grep NSID
; NSID: 67 70 64 6e 73 2d 63 68 73 ("gpdns-chs")

توجه: مقدار بازگشتی در گزینه NSID در هر زمان بدون اطلاع قبلی ممکن است تغییر کند. برای مصارف تولیدی به این مقدار وابسته نباشید.

وضوح در IPv6 کندتر است

اگر تأخیر وضوح در IPv6 به طور قابل توجهی بیشتر از IPv4 باشد، اتصال IPv6 بین ISP شما و Google ممکن است کمتر از حد مطلوب باشد. ISP هایی که با Google همتا می شوند باید تعداد پرش های بسیار بیشتری را در خروجی IPv6 traceroute بررسی کنند ( به سرورهای DNS عمومی Google مراجعه کنید) یا سایر مشکلات مربوط به مسیریابی BGP نشان داده شده در داشبورد ISP آنها را بررسی کنند و اگر به نظر می رسد مسیریابی IPv6 آنها در حال فرود است به Google NOC ایمیل کنند. مترو متفاوت از IPv4.

پاسخی به (برخی از) سؤالات DNS من داده نشد

طبیعی است که بخش بسیار کوچکی از درخواست‌های UDP DNS حذف شوند، اما اگر کاهش یک درصد یا بیشتر از درخواست‌های خود را مشاهده کردید، از ابزار تست DNS مانند موارد قبل استفاده کنید.

اگر یک ابزار تست DNS سطوح بالایی از پرس و جوهای بدون پاسخ را نشان می دهد (و به خصوص اگر ping و traceroute نرخ افت قابل مقایسه را نشان نمی دهند)، بررسی کنید که آیا آدرس IP شما بیش از 1000 پرس و جو در ثانیه ایجاد می کند، که می تواند باعث محدودیت نرخ شود. اگر چنین است، می‌توانید در ردیاب مشکل ما درخواست افزایش محدودیت نرخ کنید .

مسدود کردن و ربودن DNS

اگر هیچ پاسخی به درخواست‌های DNS دریافت نکردید (اما صفحه dns.google کار می‌کند) ممکن است درخواست‌های UDP و TCP مسدود یا ربوده شوند. برای بررسی اینکه آیا درخواست های UDP و TCP به DNS عمومی Google می رسند، این دستورات را اجرا کنید:

پنجره ها

nslookup -debug -type=TXT test.dns.google.com. dns.google.
nslookup -debug -type=TXT -vc locations.dns.google.com. dns.google.

macOS یا Linux

dig -t TXT test.dns.google.com. '@dns.google.'
dig -t TXT +tcp locations.dns.google.com. '@dns.google.'

اگر خروجی فرمان اول "Thanks for using Google Public DNS." جستارهای UDP شما به DNS عمومی گوگل می رسد. اگر خروجی فرمان دوم شامل locations.publicdns.goog. جستارهای TCP شما به گوگل نیز می رسد.

اگر خروجی NXDOMAIN را نشان می‌دهد، به یک DNS Resolver دیگر می‌رسید. اگر خروجی یک مهلت زمانی را نشان دهد، درخواست‌های DNS به DNS عمومی Google مسدود می‌شوند. از دستورات UDP یا DNS traceroute در بخش زیر استفاده کنید تا ببینید در کجا ممکن است هک کردن یا مسدود کردن اتفاق بیفتد.

بررسی کنید که به سرورهای DNS عمومی Google دسترسی دارید

اگر نمی توانید صفحه اصلی dns.google را باز کنید، ممکن است مشکلی در شبکه یا مسدود شدن وجود داشته باشد که مانع از دسترسی شما به DNS عمومی Google شود.

اگر سیستم شما برای استفاده از Google Public DNS به عنوان حل‌کننده DNS پیکربندی شده است، ممکن است لازم باشد نام dns.google را در دستورات زیر با آدرس‌های IP Google Public DNS جایگزین کنید. ابتدا با نام امتحان کنید و اگر ناموفق بود از 8.8.8.8 یا آدرس دیگری استفاده کنید.

یک پنجره ترمینال را با یک خط فرمان باز کنید و این دستورات traceroute را اجرا کنید:

پنجره ها

ردیابی مسیریابی با درخواست اکو ICMP:

tracert -d -w 2000 dns.google

برای تست اتصال IPv6:

tracert -6 -d -w 2000 dns.google

macOS یا Linux

ردیابی مسیریابی با بسته های UDP غیر DNS:

/usr/sbin/traceroute -n -w 2 -m 30 dns.google

برای تست اتصال IPv6:

/usr/sbin/traceroute6 -n -w 2 -m 30 dns.google

اگر سیستم شما می گوید که شما مجوز اجرای traceroute را ندارید، از دستور sudo برای اجرای آن استفاده کنید:

sudo /usr/sbin/traceroute -n -w 2 -m 30 dns.google

اگر آخرین خط خروجی یک آدرس IP عمومی DNS Google (8.8.8.8، 8.8.4.4، یا یک آدرس IPv6 که با 2001:4860:4860 شروع می‌شود) را نشان نمی‌دهد، ممکن است مشکل شبکه مانع از دسترسی شما به Google شود.

در سیستم های غیر ویندوز، دستورات بالا را با گزینه -I یا -U تکرار کنید تا از بسته های ICMP یا بسته های UDP غیر DNS ارسال شده به پورت DNS استفاده کنید (53). اگر گزینه -I شناسایی نشد، دستور ping را برای ارسال ICMP امتحان کنید:

macOS یا Linux

ping -c 2 dns.google

دستور dnstraceroute ابزارهای آزمایش DNS farrokhi/dnsdiag که در زیر Resolving domains is too slow می توان برای ردیابی مسیر جستجوهای DNS واقعی (حتی در ویندوز) استفاده کرد.

اگر برخی از این دستورات کار می کنند و برخی دیگر خطاهای شبکه یا وقفه های زمانی را نشان می دهند، ممکن است فیلتر شبکه مانع از دسترسی شما به DNS عمومی Google شود. برای تأیید این موضوع با سرپرست شبکه یا پشتیبانی ISP خود تماس بگیرید.

اگر هیچ یک از این دستورات موفقیت آمیز نبود، با ISP (بالادست) خود تماس بگیرید، یا اگر یک ISP هستید که با Google همتا هستید، با Google NOC تماس بگیرید. آخرین خط خروجی traceroute که سه ستاره * * * ندارد (نمایش زمان‌های زمانی ثابت) ممکن است نشان‌دهنده محل وقوع مشکل باشد.