عندما يتعذّر على نظام أسماء النطاقات العام من Google حلّ نطاق، غالبًا ما يكون ذلك بسبب مشكلة في ذلك النطاق أو خوادم الأسماء الموثوق بها. يمكن أن تساعد الخطوات التالية في تحديد سبب المشكلة، بحيث يمكن لمشرفي النطاق حلها بأنفسهم.
قبل البدء بهذه الخطوات، تحقّق من النطاق على dns.google كما هو موضّح في صفحة عامة لتحديد المشاكل وحلّها، ما قد يشير إلى خطوة تشخيص معيّنة أدناه. إذا لم يكن الرمز ظاهرًا، يمكنك تجربة كل الخطوات التالية إلى حين العثور على السبب.
الخطوة 1: التحقّق من مشاكل التحقّق من صحة ملحقات أمان نظام أسماء النطاقات (DNSSEC)
في حال كانت عمليات بحث الويب من خلال dns.google للنطاق تعرض "Status": 2 (SERVFAIL) وطلبات البحث بدون ملحقات أمان نظام أسماء النطاقات (DNSSEC)، قد تكون هناك مشكلة DNSSSEC
في خوادم الأسماء للنطاق أو سجلّ نطاق المستوى الأعلى (TLD)
(الذي ينشر سجلّات DS للتحقّق من ملحقات أمان نظام أسماء النطاقات (DNSSEC) للنطاقات المسجّلة).
- التغييرات في جهة التسجيل أو خدمة نظام أسماء النطاقات
يمكن أن تحدث مشاكل ملحقات أمان نظام أسماء النطاقات (DNSSEC) بعد تبديل نطاق من جهة تسجيل أو خدمة نظام أسماء نطاقات تتوافق مع ملحقات أمان نظام أسماء النطاقات (DNSSEC) إلى أخرى لا تتوافق مع DNSSEC. إذا كانت الخدمة السابقة تركت سجلّات
DSقديمة في سجلّ نطاق المستوى الأعلى، ولم تنشئ الخدمة الجديدة سجلّاتDNSKEYجديدة تتضمّن سجلّاتDSمطابقة في سجلّ نطاق المستوى الأعلى، لن يتمكّن التحقّق من صحة برامج التعيين، مثل نظام أسماء النطاقات العام من Google، من حلّ النطاق.وفي هذه الحالة، يمكنك أن تطلب من جهة تسجيل نطاقك إزالة سجلّات DS القديمة من سجلّ نطاق المستوى الأعلى.
- استجابات DNSSEC كبيرة جدًا
ويمكن أن تكون الأسباب المتعلّقة بمشاكل ملحقات أمان نظام أسماء النطاقات (DNSSEC) هي استجابات DNSSEC الكبيرة جدًا والتي لا تتناسب مع حزمة IP الواحدة، ما يؤدي إلى إنشاء استجابات مجزّأة قد يتم تجاهلها. إذا عرض نظام أسماء النطاقات (Visz) عدم وجود استجابة إلى أن تم تقليل حجم حمولة UDP أو "أخطاء"، قد تحدث حالات تعذُّر استجابة ملحقات أمان نظام أسماء النطاقات (DNSSEC) استجابة كبيرة جدًا. يمكن تقليل أحجام الردود بواسطة إجراء واحد أو أكثر من الإجراءات التالية:
- ضبط "الاستجابات البسيطة&للخوادم: خوادم الأسماء الموثوقة
- تقليل عدد سجلّات
DNSKEYالنشطة إلى سجلّين أو ثلاثة - استخدِم سجلّات
DNSKEY1280 أو 2048 بت (RFC 6781 وStackExchange). - التبديل من توقيعات RSA إلى توقيعات ECDSA الأصغر حجمًا (RFC 8624)
اطّلِع أيضًا على أي مشاكل أخرى في ملحقات أمان نظام أسماء النطاقات (DNSSEC) تم الإبلاغ عنها باستخدام الأدوات الواردة في الخطوة 2. وتشمل الأمثلة سجلّات الرفض المتعلقة بمعيار NSEC أو NSEC3 للتأكد من عدم توفّر نطاقات فرعية (قد يحتوي PowerDNS مع المناطق المخزّنة في قواعد البيانات الخارجية على هذه النطاقات) أو توقيعات RRSIG منتهية الصلاحية (مع عمليات توقيع معطّلة يدويًا).
الخطوة 2: التحقّق من خوادم الأسماء الموثوقة
إذا واجه نظام أسماء النطاقات العام من Google (أو أي برنامج تعيين مفتوح) مشكلة في حل نطاق، يعرض DNSViz مشاكل النطاق وخادم الأسماء التي تسبب ذلك. انتقِل إلى صفحة ويب DNSViz وأدخِل اسم النطاق الذي يسبب المشكلة. في حال عدم توفّر بيانات سابقة لنظام أسماء النطاقات ViViz أو مع توفُّر بيانات يعود تاريخها إلى أكثر من يوم واحد (كما هو موضّح في الصفحة هنا)، انقر على الزر تحليل الكبير للكشف عن زر تحليل أقل حجمًا أدناه (إذا لم يكن ظاهرًا من قبل) وانقر عليه. عند اكتمال التحليل، انقر على "متابعة"؛ لعرض النتائج. انقر على الأخطاء الحمراء والتحذيرات الصفراء في الشريط الجانبي الأيمن لعرض التفاصيل، أو اضغط مع الاستمرار على المؤشر في العناصر في الرسم البياني لإبراز تلك المعلومات في السياق.
إذا كانت بيانات التشخيص السابقة تشير إلى مشاكل محتملة في ملحقات أمان نظام أسماء النطاقات (DNSSEC)،
انتقِل إلى صفحة الويب باستخدام أداة تحليل ملحقات أمان نظام أسماء النطاقات (DNSSEC) وأدخِل اسم النطاق. إذا أشارت أداة التحليل هذه إلى أخطاء أو تحذيرات في ملحقات أمان نظام أسماء النطاقات (DNSSEC)،
اضغط مع الاستمرار على المؤشر فوق الرمز
تعرض صفحة الويب intoDNS تقارير حول مشاكل غير DNSSEC في النطاق الذي تم إدخاله على الصفحة الرئيسية وتعرض أيضًا اقتراحات لحلها.
يجب على مشرفي النطاق إصلاح معظم الأخطاء في تقرير هذه الأدوات، لأنها قد تتسبب في حدوث مشاكل ليس فقط لنظام أسماء النطاقات العام من Google، بل برامج تعيين أخرى أيضًا.
الخطوة 3: التحقّق من مشاكل التفويض
إنّ "نظام أسماء النطاقات العام من Google" هو برنامج لتحليل "الوالدَين" و"الوالدَين" ولا يستخدم إلا خوادم الأسماء التي يتم عرضها في الإحالات من النطاق الرئيسي. إذا كانت أسماء خوادم الأسماء والعناوين الملتصقة في نطاق المستوى الأعلى قديمة أو غير صحيحة، يمكن أن يتسبب ذلك في مشاكل في التفويض.
إذا أبلغ نظام أسماء النطاقات (DNSViz) أو رمز نظام أسماء النطاقات (DNS) عن التحذيرات حول التناقضات بين خوادم الأسماء المفوَّضة في نطاق المستوى الأعلى (TLD) والخوادم الموجودة في النطاق الفرعي نفسه، قد تحتاج هذه العناوين إلى معالجتها قبل أن يتمكن نظام أسماء النطاقات العام من Google من حل النطاق. إذا أشارت هذه الأدوات إلى أنّ النطاق المسجّل غير متوفّر (NXDOMAIN)، يُرجى التحقّق من عدم انتهاء صلاحية النطاق أو تعليق التسجيل لأي سبب.
يمكن أن تحدث مشاكل التفويض أيضًا بسبب عدم حلّ أسماء خوادم الأسماء لنطاق معيّن. تحقّق من سجلّي A وAAAA لخوادم الأسماء
على dns.google للاطّلاع على ما إذا كانت هناك مشاكل في خوادم الأسماء#.
الخطوة 4: التحقّق من الردود الكبيرة
يعتمد نظام أسماء النطاقات على UDP لنقل معظم الزيارات. تخضع مخططات بيانات UDP الكبيرة إلى التجزئة، ويعاني UDP المجزأة من تسليم غير موثوق. كان هذا هو محور تركيز يوم الإبلاغ عن نظام أسماء النطاقات لعام 2020، وهو الجهود المبذولة لتحسين موثوقية نظام أسماء النطاقات على مستوى العالم. شارك نظام أسماء النطاقات العام من 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 عندما تكون متاحة. ويمكن أن يؤدي ذلك إلى زيادة حجم النتيجة بشكل كبير. وهذا يحاكي سلوك نظام أسماء النطاقات العامة من Google.
+bufsize=1400- الحدّ الأقصى المسموح به لحجم المخزن المؤقت على UDP وهذا يحاكي سلوك نظام أسماء النطاقات العام من Google، اعتبارًا من يوم الإبلاغ عن نظام أسماء النطاقات (DNS) لعام 2020.
+timeout=1- اضبِط المهلة على ثانية واحدة. وهذا يحاكي سلوك نظام أسماء النطاقات العامة من Google.
@ns1.example.com- الخادم الموثوق به الذي يجب طلب البحث عنه هو الاحتفاظ بعلامة
@ولكن بدلاً من ذلك، يمكنك استبدال الخادم الموثوق به بنطاقك، كما هو موضّح في الأمر الأول.
ملاحظة: هل ترى سطرًا، مثل:
;; Truncated, retrying in TCP mode.- يشير هذا إلى أن الاستجابة كانت أكبر من حجم التخزين المؤقت المطلوب في بروتوكول UDP، لذا تم اقتطاعها واستجابة للعميل إلى بروتوكول TCP. يجب أن تكون الخوادم الموثوق بها قادرة على التعامل مع حركة بيانات نظام أسماء النطاقات عبر منفذ TCP رقم 53. (اطّلِع على RFC 7766 التي تتطلّب أن تكون عمليات التنفيذ "، يجب أن تتوافق مع كل من بروتوكول نقل الملفات UDP وTCP؛) .
;; MSG SIZE rcvd: 2198- بالنسبة إلى أي رقم يزيد عن 1400؟ ويشير ذلك مرة أخرى إلى استجابة كبيرة.
;; Query time: 727 msec- بالنسبة إلى أي رقم يزيد عن 500؟ قد يتجاهل نظام أسماء النطاقات العام من Google الاستجابات البطيئة (خاصةً تلك التي تكون مدتها بالقرب من ثانية واحدة أو أكثر). ويحدث هذا في الغالب إذا تم قضاء بعض الوقت في محاولة بروتوكول UDP، تليها محاولة TCP. يمكن أن يؤثر الموقع الجغرافي للخادم والعميل بشكل كبير في وقت الاستجابة.
;; connection timed out; no servers could be reached- خاصةً إذا كانت بعض طلبات البحث فقط، تشير هذه المشكلة إلى أنّه يتعذّر على خادمك الإجابة عن طلبات بحث نظام أسماء النطاقات في الوقت المناسب.
يمكنك تجربة صيغ طلبات البحث التالية:
- جارٍ إضافة معلَمة
+tcp. - هذا يفرض على
digاستخدام TCP فورًا، يمكنك التحقّق مما إذا كان الخادم الموثوق به يتعامل مع طلبات TCP مباشرةً بهذه الطريقة. - جارٍ إزالة المعلمة
+bufsize=1400. - سيؤدي ذلك إلى استعادة السلوك التلقائي لـ
dig'؛ (وهو 4096). إذا تعذّر إجراء طلبات البحث على هذه الإعدادات، ولكن بدونها، هذا تلميح بأنّ الخادم لا يتعامل مع حالة فائت بروتوكول TCP بشكل جيد. الاعتماد على بروتوكول UDP لنقل الردود الكبيرة فقط يعمل أحيانًا. والإجراء الأفضل هو إتاحة نقل بروتوكول TCP لنظام أسماء النطاقات. - التكرار في كل خادم أسماء
- يحتوي المثال أعلاه على خادمَي أسماء موثوقَين (
ns1وns2). وترجع بعض المشاكل إلى خوادم مختلفة تعرض إجابات مختلفة. تحقّق من أنّ جميع الإجابات تُطابِق بشكل متكرر من خلال تكرار طلبات البحث نفسها في جميع الخوادم الموثوق بها.
إذا كانت جميع طلبات البحث محددة الشكل (مثل 1400 بايت أو أقل)، وسرعة (يُفضّل أن تكون 500 ميلي ثانية)، أو موثوقة، (وتعمل باستمرار على بروتوكول TCP وUDP)، فلا داعي للقلق بشأن حجم الاستجابة، لذا اقرأ الأقسام الأخرى لتحديد المشاكل وحلّها. حتى إذا كانت ردودك سريعة، قد تكون طلبات البحث من مواقع جغرافية بعيدة أبطأ.
إذا تعذّر تنفيذ أي من عمليات التحقّق هذه (كبيرة أو بطيئة أو غير موثوقة؟) سيكون الإجراء الأساسي هو A) في التأكّد من أن الخادم يستجيب لاقتطاع UDP، عند تجاوز الاستجابة لحجم المخزن المؤقت المطلوب لـ UDP وB) أنّه يمكنه معالجة إعادة محاولة طلب TCP التي ستتبعها. يمكن أن تساعدك العديد من الأدوات في تشخيص مشاكل موثوقية نظام أسماء النطاقات:
- نظام أسماء النطاقات (DNS)
- أداة تصحيح أخطاء DNSSEC
- أداة اختبار الامتثال لنظام أسماء النطاقات (EDNS)
- فحص نظام أسماء النطاقات -- احرص على إزالة العلامة من المربّع &"CD" (إيقاف التحقق من ملحقات أمان نظام أسماء النطاقات (DNSSEC))
إذا كشفت هذه الأدوات عن أي أخطاء أو تحذيرات، احرص على معالجتها. احرص أيضًا على قراءة جميع التعليمات الأخرى لتحديد المشاكل وحلّها على هذا الموقع الإلكتروني.
الخطوة 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.'
تستخدم هذه الأوامر برامج تعيين نظام أسماء النطاقات لكل من OpenDNS وQud9 وCloudflare 1.1.1.1. إذا تلقيت أخطاء في الحل من اثنين من هذه الأنظمة بالإضافة إلى نظام أسماء النطاقات العام من Google، من المحتمل أن تكون المشكلة متعلقة بالنطاق أو خوادم الأسماء.
إذا حصلت على نتيجة ناجحة من أكثر من برنامج تعيين عام آخر، قد تكون هناك مشكلة في Google Public DNS. إذا لم يتم الإبلاغ عن أي مشاكل مشابهة للنطاق (أو نطاق المستوى الأعلى الخاص به) على أداة تتبّع المشاكل، عليك الإبلاغ عن المشكلة إلينا، بما في ذلك مخرجات الأمر ونص صفحة التشخيص أو لقطات الشاشة في تقريرك.