حين يكتب زائر اسم موقعك في المتصفح فيظهر له «لا يمكن الوصول إلى هذا الموقع»، فالمشكلة ليست دائماً في الخادم. كثير من الأعطال التي تبدو «سقوطاً للموقع» هي في الحقيقة أعطال في نظام أسماء النطاقات (DNS): سجلّ ناقص، أو خوادم أسماء لا تردّ، أو تغيير لم ينتشر بعد. يشرح هذا الدليل طريقة منهجية لتشخيص هذه الأعطال خطوة بخطوة، بدءاً من فهم رسائل الخطأ الشائعة مثل NXDOMAIN وSERVFAIL، وانتهاءً بقائمة فحص تستخدمها قبل أي نقل للنطاق أو تغيير في السجلات.
كيف يعمل الاستعلام عن اسم النطاق باختصار
عندما يطلب جهازك عنوان example.com لا يسأل خادم موقعك مباشرة، بل يمرّ الطلب بسلسلة واضحة:
- المحلِّل التكراري (Recursive Resolver): غالباً خادم DNS التابع لمزوّد الإنترنت أو خدمة عامة مثل 1.1.1.1 أو 8.8.8.8. هو من يتولّى البحث نيابةً عنك ويخزّن النتائج مؤقتاً.
- الخوادم الجذرية: تخبر المحلِّل بمكان الخوادم المسؤولة عن الامتداد، مثل
.comأو.tech. - خوادم الامتداد (TLD): تردّ بقائمة خوادم الأسماء (NS) المسجّلة لنطاقك لدى المسجِّل.
- خوادم الأسماء الموثوقة (Authoritative): هي التي تحمل منطقة نطاقك (Zone) وتردّ بالسجلّ المطلوب، مثل سجل A أو AAAA أو CNAME أو MX.
أي خلل في حلقة من هذه الحلقات يظهر للمستخدم بالطريقة نفسها تقريباً: الموقع لا يفتح. لذلك فإن مهمتك الأولى في التشخيص هي تحديد أي حلقة هي المعطّلة، لا القفز مباشرة إلى إعادة تشغيل الخادم.
أدوات التشخيص التي تحتاجها
لا تحتاج إلى برامج مدفوعة. الأدوات الأساسية متاحة على معظم الأنظمة:
- dig: الأداة الأدق، متوفرة افتراضياً على لينكس وmacOS، ويمكن تثبيتها على ويندوز ضمن حزمة BIND أو استخدامها عبر WSL.
- nslookup: متوفرة على ويندوز ولينكس، أبسط لكنها تكفي لفحص سريع.
- Resolve-DnsName: أمر PowerShell على ويندوز، ويعرض نتائج منظّمة.
- أدوات الفحص عبر الويب: مثل خدمات فحص انتشار DNS من مواقع جغرافية متعددة، وهي مفيدة لمعرفة ما يراه المستخدمون في دول أخرى.
أمثلة سريعة للأوامر الأكثر استخداماً:
dig example.com A +short
dig example.com NS
dig @1.1.1.1 example.com A
dig example.com +trace
nslookup -type=MX example.com
Resolve-DnsName example.com -Type NSالخيار +trace مهم جداً لأنه يتجاوز الذاكرة المؤقتة ويتتبّع السلسلة من الجذر حتى الخادم الموثوق، فيكشف لك بدقة أين ينقطع الطريق.
فهم رموز الاستجابة: ماذا تعني كل رسالة؟
في مخرجات dig ستجد سطراً يحتوي على status:. هذه القيمة هي مفتاح التشخيص:
NOERROR مع إجابة
الاستعلام نجح وعاد بسجل. إن كان الموقع لا يفتح رغم ذلك، فالمشكلة غالباً ليست في DNS: تحقّق من أن العنوان الظاهر هو عنوان خادمك الصحيح، ثم افحص الخادم نفسه وجدار الحماية وشهادة SSL.
NOERROR بلا إجابة (NODATA)
النطاق موجود، لكن لا يوجد سجل من النوع الذي طلبته. مثال شائع: أضفت سجل A للنطاق الرئيسي ونسيت سجل www، أو العكس. الحل إضافة السجل الناقص أو CNAME يشير إلى الاسم الصحيح.
NXDOMAIN
معناها أن الخادم الموثوق يؤكّد أن هذا الاسم غير موجود. الأسباب المعتادة:
- خطأ إملائي في اسم النطاق الفرعي أو في السجل نفسه.
- النطاق منتهي الصلاحية أو معلّق لدى المسجِّل؛ تحقّق من حالته عبر WHOIS أو RDAP.
- خوادم الأسماء المسجّلة لدى المسجِّل تشير إلى مزوّد لا يحتوي على منطقة لنطاقك أصلاً.
- أنشأت النطاق الفرعي في لوحة غير اللوحة المستخدمة فعلاً لخدمة DNS.
SERVFAIL
هذه أكثر الرسائل إرباكاً، لأنها تعني أن المحلِّل فشل في الحصول على إجابة موثوقة، وليس أن الاسم غير موجود. أسبابها الشائعة:
- خوادم الأسماء لا تستجيب: مزوّد DNS متوقف، أو الخوادم المذكورة في سجلات NS لم تعد تخدم نطاقك.
- أخطاء DNSSEC: وجود سجل DS لدى المسجِّل لا يطابق مفاتيح التوقيع لدى مزوّد DNS الحالي، وهو سبب متكرر بعد نقل النطاق بين مزوّدين دون تعطيل DNSSEC أولاً.
- تفويض معطوب (Lame Delegation): خوادم الأسماء المسجّلة لدى الامتداد لا تعتبر نفسها موثوقة لنطاقك.
- مشكلة في المحلِّل نفسه: نادرة، ويمكن استبعادها بالاستعلام من محلِّل آخر.
للتفريق بين هذه الأسباب، استعلم مباشرة من كل خادم أسماء على حدة: dig @ns1.provider.com example.com A. إن ردّ الخادم الموثوق بإجابة صحيحة بينما يعطي المحلِّل العام SERVFAIL، فراجع DNSSEC أولاً. ويمكنك تجربة dig example.com +cd (تعطيل التحقق)؛ إن نجح الاستعلام مع هذا الخيار وفشل بدونه، فالمشكلة شبه مؤكدة في توقيعات DNSSEC.
REFUSED وTimeout
REFUSED تعني أن الخادم رفض الإجابة، وتظهر غالباً عندما تسأل خادماً لا يستضيف منطقتك. أما انتهاء المهلة (Timeout) فيشير إلى خادم لا يردّ إطلاقاً أو إلى حجب شبكي للمنفذ 53.
خطة تشخيص منهجية في سبع خطوات
- ثبّت العَرَض: هل المشكلة لدى كل المستخدمين أم لدى شبكة واحدة؟ جرّب من هاتف على بيانات الجوال ومن أداة فحص خارجية.
- اسأل أكثر من محلِّل:
dig @1.1.1.1وdig @8.8.8.8ومحلِّل مزوّد الإنترنت. اختلاف النتائج يشير إلى ذاكرة مؤقتة أو انتشار غير مكتمل. - تحقّق من التفويض:
dig example.com NS +traceوقارن خوادم الأسماء الظاهرة لدى الامتداد بما تتوقعه في لوحة المسجِّل. - اسأل الخوادم الموثوقة مباشرة: إن أجابت بشكل صحيح، فالمشكلة في الطريق إليها أو في الذاكرة المؤقتة، لا في المنطقة نفسها.
- افحص DNSSEC: هل يوجد سجل DS لدى المسجِّل؟ هل مزوّد DNS الحالي يوقّع المنطقة؟ عدم التطابق يعني SERVFAIL لدى المحلِّلات التي تتحقق من التوقيعات.
- راجع السجلات الفردية: A وAAAA للنطاق الرئيسي و
www، وMX وSPF للبريد، وأي CNAME للخدمات الخارجية. - بعد الإصلاح، راقب TTL: لا تتوقع أن يرى الجميع التغيير فوراً؛ ستبقى النسخ القديمة في الذاكرة المؤقتة حتى تنتهي مدتها.
الانتشار وTTL: لماذا يرى بعض الناس الموقع ولا يراه آخرون؟
مصطلح «انتشار DNS» شائع لكنه مضلِّل قليلاً؛ فلا توجد عملية نشر تدفع التغيير إلى العالم. ما يحدث فعلاً أن كل محلِّل يحتفظ بالإجابة القديمة حتى تنتهي مدة صلاحيتها المحددة بقيمة TTL (بالثواني). إذا كان TTL لسجلك 86400 ثانية، فقد يظل بعض المستخدمين يرون العنوان القديم حتى يوم كامل.
نصائح عملية للتعامل مع TTL:
- قبل أي تغيير مخطط له (نقل خادم أو مزوّد)، اخفض TTL إلى 300 ثانية مثلاً قبل التغيير بمدة لا تقل عن قيمة TTL القديمة.
- بعد استقرار التغيير، أعد TTL إلى قيمة أعلى لتقليل عدد الاستعلامات وتحسين الاستقرار.
- تغيير خوادم الأسماء (NS) لدى المسجِّل يخضع لـ TTL خاص بالامتداد نفسه، وقد يستغرق ساعات، ولا يمكنك التحكم فيه من لوحة DNS.
- يمكنك مسح الذاكرة المؤقتة على جهازك (
ipconfig /flushdnsعلى ويندوز)، لكن ذلك لا يؤثر على محلِّلات المستخدمين الآخرين.
سجلات البريد والوكيل العكسي: خطأ شائع عند استخدام شبكات CDN
عند تفعيل خدمة وكيل (Proxy) أو شبكة توزيع محتوى تخفي عنوان خادمك الحقيقي، انتبه إلى أن هذه الخدمات تمرّر عادة حركة الويب فقط (HTTP وHTTPS). إذا جعلت سجل mail.example.com يمرّ عبر الوكيل، فلن يصل البريد إلى خادمك، لأن بروتوكولات SMTP وIMAP لا تمرّ عبره. القاعدة العملية:
- سجلات الويب (النطاق الرئيسي و
www): يمكن تمريرها عبر الوكيل. - سجل خادم البريد المشار إليه في MX: يجب أن يكون «DNS فقط» ويشير مباشرة إلى عنوان الخادم.
- سجلات SPF وDKIM وDMARC نصية (TXT) ولا تتأثر بالوكيل، لكن تحقّق من نقلها كاملة عند تغيير المزوّد.
قائمة فحص قبل نقل النطاق أو تغيير مزوّد DNS
- صدّر نسخة كاملة من المنطقة الحالية (كل السجلات) قبل أي تعديل.
- أنشئ المنطقة لدى المزوّد الجديد وراجع السجلات سجلاً سجلاً، خصوصاً MX وTXT والنطاقات الفرعية.
- اسأل خوادم المزوّد الجديد مباشرة بـ
dig @قبل تغيير NS لدى المسجِّل، وتأكد أنها تجيب بشكل صحيح. - إذا كان DNSSEC مفعّلاً، عطّله واحذف سجل DS لدى المسجِّل وانتظر انتهاء TTL، ثم انقل، ثم أعد التفعيل لدى المزوّد الجديد.
- اخفض TTL مسبقاً كما شرحنا.
- بعد تغيير NS، راقب النتائج من محلِّلات متعددة ومن مواقع جغرافية مختلفة.
- أبقِ المنطقة القديمة فعّالة بضعة أيام حتى تنتهي كل النسخ المؤقتة.
أخطاء شائعة تجنّبها
- إعادة تشغيل الخادم عند كل انقطاع: إن كان الاستعلام يعيد SERVFAIL أو NXDOMAIN، فالخادم ليس المشكلة.
- الاعتماد على متصفحك وحده: المتصفحات ونظام التشغيل تخزّن نتائج DNS، فقد ترى الموقع يعمل بينما هو معطّل لدى غيرك، أو العكس.
- وضع CNAME على النطاق الرئيسي: معايير DNS لا تسمح بسجل CNAME في جذر المنطقة مع سجلات أخرى؛ استخدم A أو ميزة التسطيح (ALIAS/CNAME Flattening) إن كان مزوّدك يدعمها.
- نسيان تجديد النطاق: فعّل التجديد التلقائي وتأكد من صلاحية وسيلة الدفع وبريد التنبيهات لدى المسجِّل.
- الاعتماد على خادم أسماء واحد: يوصي المعيار بخادمين على الأقل، ويفضّل أن يكونا على شبكات منفصلة.
الأسئلة الشائعة
كم يستغرق انتشار DNS فعلاً؟
يعتمد على قيمة TTL للسجلات التي غيّرتها. تغيير سجل A بقيمة TTL تبلغ 300 ثانية يظهر لمعظم المستخدمين خلال دقائق، بينما قد يستغرق تغيير خوادم الأسماء لدى المسجِّل عدة ساعات، ونادراً ما يصل إلى 48 ساعة.
هل استخدام محلِّل عام مثل 1.1.1.1 يحلّ المشكلة؟
يحلّها على جهازك فقط إن كانت المشكلة في محلِّل مزوّد الإنترنت. أما إن كانت في منطقة نطاقك أو في DNSSEC فستظهر لدى الجميع.
كيف أعرف إن كانت المشكلة في DNS أم في الخادم؟
إذا أعاد dig العنوان الصحيح بحالة NOERROR، فجرّب الوصول إلى الخادم مباشرة بالعنوان أو بأداة curl -I. إن فشل ذلك فالمشكلة في الخادم أو الشبكة أو الشهادة، وليست في DNS.
ترتيب الفحص في سطر واحد
رمز الاستجابة أولاً، ثم أكثر من محلِّل، ثم تتبّع التفويض، ثم الخوادم الموثوقة مباشرة، وأخيراً DNSSEC وTTL. احتفظ بهذا الترتيب مع أوامر dig الواردة أعلاه، وابدأ منه في المرة القادمة التي يصلك فيها «الموقع لا يفتح».