الموقع يعمل لبعض الزوار فقط: متى تكون مشكلة DNS؟

عندما يعمل الموقع لبعض الزوار فقط، افصل فشل العثور على عنوانه عن فشل الاتصال بالخادم أو عرض الصفحة. قد تكون المشكلة إجابة DNS قديمة، أو خللاً في DNSSEC، أو عنوان IPv6 غير صالح، وقد تكون قاعدة حماية تمنع شبكة معينة رغم صحة DNS. لا تشترِ سيرفراً أكبر قبل تحديد الطبقة التي يفشل عندها الطلب. ابدأ بمقارنة تجربة ناجحة وأخرى فاشلة في الوقت نفسه وبالاسم نفسه.

اجمع مقارنة قابلة للتحقق

سجل اسم الموقع كاملاً، بما فيه www إن استخدم، ونص الخطأ والتوقيت وشبكة الاتصال ونوع الجهاز. اسأل هل الفشل في النطاق الرئيسي أم نطاق فرعي، وهل يظهر خطأ اسم غير موجود أم مهلة اتصال أم تحذير شهادة أم صفحة رفض. عبارة «لا يفتح» لا تكفي للفصل بين هذه الأسباب.

اجمع عنوان IP الذي أعاده المحلل المستخدم لدى كل حالة، ونتيجة الاتصال بالخدمة بعد ذلك. لا تطلب من الزائر إرسال كلمات مرور أو ملفات جلساته. ويمكن للفريق إجراء فحوص قراءة من نقاط مراقبة مختلفة، مع إبقاء الاختبار متزامناً قدر الإمكان حتى لا تقارن حالتين تغيّر بينهما إعداد الموقع.

حدد أول طبقة تختلف بين الزوار

ليس كل اختلاف في IP خطأ؛ قد توزع خدمة CDN أو DNS جغرافي الزوار على وجهات مختلفة عمداً. قارن النتيجة بسياسة الخدمة ومدى صحة كل وجهة. كما أن وصول رد HTTP من وسيط لا يثبت أن الخادم الأصلي سليم؛ تابع الطلب داخل السلسلة بدلاً من إنهاء التحقيق عند أول استجابة.

قارن المصدر الموثوق بالمحللات والذاكرة المحلية

افحص خوادم NS المفوضة للنطاق، ثم اسأل كل خادم موثوق عن الاسم ونوع السجل المطلوب. إذا كانت الإجابات نفسها خاطئة، أصلح المنطقة الفعالة. وإذا كان المصدر صحيحاً بينما يحتفظ محلل بإجابة سابقة، راجع زمن التغيير وTTL السابق. تعديل لوحة غير مسؤولة عن المنطقة لن يغير ما يراه الزوار.

يشير دليل Google Public DNS لاستكشاف الأعطال إلى مقارنة الإجابات والتحقق من الوصول إلى المحلل المستخدم فعلياً. قد يستخدم المتصفح أو شبكة المؤسسة محللاً مختلفاً عن إعداد النظام. تنظيف ذاكرة جهاز واحد يفيد المقارنة أحياناً، لكنه ليس إصلاحاً عاماً لبقية المستخدمين.

افحص DNSSEC دون تحويل تجاوزه إلى حل دائم

قد يفشل محلل يتحقق من DNSSEC بينما يعمل آخر لا يطبق التحقق بالطريقة نفسها. يوضح دليل Google لتشخيص النطاقات أن بقاء سجل DS قديم بعد تغيير مزود DNS قد يكسر التحقق إذا لم يطابق مفاتيح المنطقة الجديدة. يراجع المختص سلسلة التفويض والتوقيع وتواريخ الصلاحية وأخطاء التحقق التفصيلية.

مقارنة الاستعلام مع التحقق وبدونه أداة تشخيص، وليست دعوة لتعطيل التحقق لدى العملاء. أصلح DS أو المفاتيح والتوقيعات وفق خطة مزود DNS والمسجل. ولا تعتبر كل SERVFAIL دليلاً قطعياً على DNSSEC؛ قد ينشأ عن خادم غير متاح أو مشكلة تفويض أو استجابة لا يستطيع المحلل إكمالها.

اختبر IPv4 وIPv6 كمسارين مستقلين

قد يحمل النطاق A صحيحاً وAAAA قديماً؛ المستخدم الذي يصل عبر IPv4 ينجح، بينما يتأثر مستخدم يسلك IPv6. توضح وثائق أنواع سجلات DNS وظيفة A وAAAA في ربط الاسم بعناوين الإصدارين. صحة السجل تعني أيضاً أن الخدمة والحماية والشهادة معدة على الوجهة المنشورة.

اختبر الاسم على كل مسار مع الحفاظ على اسم المضيف وSNI المطلوبين. فتح عنوان IP مباشرة في المتصفح قد يعرض موقعاً افتراضياً أو شهادة أخرى، فينتج استنتاج خاطئ. وإذا لم تكن الخدمة تدعم IPv6 فعلياً، صحح ما تعلنه سجلاتها وفق خطة واضحة بدلاً من ترك عنوان لا يخدم الموقع.

إذا كانت DNS سليمة، تابع الحماية والشهادة والتطبيق

عندما يعاد العنوان الصحيح ثم يظهر رفض لبعض الشبكات، افحص قواعد WAF وحدود المعدل وسياسات الدول أو الشبكات وسجل معرف الطلب. قد يشترك مستخدمون شرعيون خلف عنوان خروج واحد فتؤثر فيهم قاعدة صارمة. لا تعطل الحماية كلها للاختبار؛ راجع القاعدة المحددة ونطاقها ضمن تغيير محدود قابل للرجوع.

وفي عقد متعددة، قد تحمل إحداها شهادة منتهية أو إعداد موقع قديماً. كذلك قد تختلف نسخة التطبيق أو الاتصال بقاعدة البيانات بين الخوادم. مطابقة نتيجة كل وجهة مع السجل الداخلي تفصل عطل DNS عن عطل وجهة كشفه التوجيه. رفع TTL أو تغييره لا يصلح شهادة غير صحيحة على خادم فعّال.

اختر الإصلاح أو النقل وفق السبب

في مثال افتراضي، شركة غيرت خوادم الأسماء وتركت منطقة ناقصة على أحدها تحتاج توحيد المنطقة والتفويض. متجر نشر AAAA قبل إعداد الخدمة يحتاج تصحيح مسار IPv6. أما خدمة DNS تتكرر أعطال خوادمها ولا يوفر مزودها استجابة مناسبة، فقد تستدعي نقل إدارة DNS بعد توثيق السجلات ومتطلبات DNSSEC.

لا تجعل نقل DNS مشروع نقل موقع وبريد دون حاجة. يساعد دليل نقل الاستضافة على حصر التبعيات، بينما يذكّر مقال أخطاء النسخ الاحتياطي بأهمية وجود بيانات رجوع قابلة للاستخدام. احتفظ بتصدير المنطقة وتاريخ التغييرات، وأدخل تعديلاً محدداً يمكن ربط أثره بنتائج القياس.

متى تدفع مقابل إدارة DNS؟

تزداد القيمة عندما تتعدد النطاقات والتطبيقات والفروع ومزودو الخدمات، أو يتسبب تعديل واحد في أثر تجاري واسع. اطلب جرداً للسجلات ومالكيها، وضبط وصول، وسجل تغييرات، ومراقبة حل الأسماء من مواقع متعددة. قارن زمن الاستجابة ومسؤولية التصعيد وآلية اختبار النقل، دون افتراض أن DNS أعلى سعراً يسرع التطبيق نفسه.

• حدد الأسماء والمسارات التي يجب أن تنجح بعد الإصلاح.
• تحقق من اتساق الخوادم الموثوقة وصحة DNSSEC إن استخدم.
• افحص A وAAAA والشهادة والرد النهائي للخدمة.
• قارن شبكات كانت تفشل وأخرى كانت تعمل.
• راقب النتائج عبر مدة مناسبة لذاكرة السجلات والحادث.
• وثق ما تغير ومن يملك صيانته لاحقاً.

أسئلة شائعة عن الموقع الذي يعمل للبعض

هل أنصح جميع العملاء بتغيير DNS في أجهزتهم؟

قد يفيد تبديل المحلل كتجربة محدودة، لكنه قد يخفي خللاً في نطاقك. أصلح المصدر والتفويض أو المسار المتسبب حتى تعمل الخدمة مع المحللات المتوافقة.

هل فشل ping يثبت أن الموقع متوقف؟

لا؛ قد تحجب الشبكة ICMP بينما تعمل خدمة الويب. اختبر حل الاسم والاتصال بالخدمة المطلوبة واستجابتها بدلاً من الاعتماد على إشارة واحدة.

هل أحتاج ترقية CPU لهذه المشكلة؟

ليس إذا توقف الطلب قبل الوصول إلى التطبيق بسبب الاسم أو المسار. تصبح الموارد موضع تقييم عندما تثبت القياسات وصول الطلبات واختناق تنفيذها.

اطلب تشخيصاً من أكثر من شبكة

أرسل الأسماء المتأثرة ونصوص الأخطاء وأوقات حدوثها وشبكات الاتصال عبر طلب تقييم إتاحة الموقع. اطلب ضمن خدمة إدارة DNS مقارنة التفويض والسجلات والتحقق ومسارات الوصول، مع اختبار يثبت عودة الخدمة للمستخدمين المتأثرين.