تبدأ تقريباً كل تذكرة "الموقع لا يعمل" تعاملت معها بنفس الطريقة: يفترض أحدهم أن المشكلة في الخادم، ويتضح أنها DNS. ليس لأن DNS هش — هو في الواقع أحد الأجزاء الأكثر موثوقية في بنية الإنترنت التحتية — بل لأنه غير مرئي حتى يخطئ، ومعظم الناس (بمن فيهم عدد لا بأس به من المهندسين) يتعلمونه بشكل صحيح فقط بعد أن يُحرقوا مرة واحدة.
هذه هي نسخة DNS التي أتمنى لو قدّمها لي أحد مبكراً في مسيرتي في الاستضافة: ليست التعريف الأكاديمي، بل أي السجلات مهمة فعلياً، وماذا يتعطل حين تكون خاطئة، وكيف تُفكّر في نطاق "لا يعمل" دون تخمين.
ماذا يفعل سجل DNS فعلياً
سجل DNS هو تعليمة واحدة، منشورة من خوادم أسماء نطاقك، تجيب على سؤال محدد واحد: لهذا الاسم، ما القيمة؟ سجل A يجيب "ما عنوان IPv4 الذي يشير إليه هذا المضيف". سجل MX يجيب "أي خادم بريد يجب أن يتعامل مع بريد هذا النطاق". كل نوع سجل ضيق وأحادي الغرض عن قصد — هذا ما يجعل النظام قابلاً للتركيب.
الجزء الذي يُعثر الناس هو الانتشار. سجل DNS ليس "حياً" لحظة حفظه — يُخزَّن مؤقتاً بواسطة أجهزة الحل حول الإنترنت لمدة يحددها TTL الخاص بالسجل (وقت الحياة)، ما يعني أن التغيير قد يستغرق من دقائق إلى 48 ساعة ليصبح مرئياً في كل مكان، حسب TTL الذي كان مضبوطاً قبل تغييرك. إذا كنت تخطط لترحيل، فتخفيض TTL قبل يوم أو يومين هو الفرق بين انتقال نظيف وساعات من "يعمل عندي لكن ليس عند عميلي".
السجلات الأكثر أهمية
A / AAAA — تشير المضيف مباشرة إلى عنوان IPv4 أو IPv6. هذا هو السجل الذي يقصده معظم الناس حين يقولون "وجّه نطاقي إلى خادمي".
CNAME — يشير المضيف إلى مضيف آخر، وليس IP. مفيد للنطاقات الفرعية التي يجب أن تتبع دائماً حيثما يتحلل الهدف، لكن CNAME لا يمكن أن يتعايش مع سجلات أخرى على نفس الاسم — قاعدة تُوقع كثيرين يحاولون إضافة CNAME وMX على نفس المضيف.
MX — يوجّه بريد النطاق إلى خادم بريد محدد، مع قيمة أولوية بحيث يمكنك تحديد أساسي واحتياطي. أخطئ في هذا ولن يرتد البريد بصوت عالٍ — غالباً سيفشل بصمت أو يُوجَّه بشكل خاطئ، وهو أسوأ.
TXT — نص حر، يُستخدم لما هو أبعد بكثير من غرضه الأصلي. هنا تعيش سجلات SPF وDKIM والتحقق من النطاق. سجلات TXT لا تفعل شيئاً بذاتها؛ تُقرأ بواسطة أنظمة أخرى (خوادم بريد، خدمات تحقق) تعرف كيف تفسّر تنسيقات محددة.
NS — يعلن أي خوادم أسماء موثوقة لنطاق أو نطاق فرعي. أخطئ في هذا على مستوى مسجّل النطاق ولن يهم أي شيء آخر تغيّره، لأن لا شيء يعرف أن يسأل مزود DNS الخاص بك أصلاً.
CAA — يحدد أي جهات إصدار شهادات مسموح لها بإصدار شهادات SSL لنطاقك. سجل يسهل تخطيه، ويسهل استخدامه كحاجز حماية خفيف ضد إصدار شهادات غير مصرّح به.
ترتيب تشخيص يوفر وقتاً فعلياً
حين لا "يعمل" نطاق ما، أتحقق من أمور بترتيب محدد، لأن معظم الأدوات ستكذب عليك بسعادة إذا تخطيت خطوة:
- أكّد خوادم أسماء النطاق أولاً، عند المسجّل، وليس عند مزود DNS. إذا كان المسجّل لا يزال يشير إلى خوادم أسماء مضيف سابق، فلا شيء تغيّره في لوحة DNS الحالية مهم بعد.
- استعلم عن السجل مباشرة من خادم أسماء موثوق، وليس عبر أداة الحل المحلية، لاستبعاد مشكلة تخزين مؤقت قبل أن تبدأ تشخيص سجل صحيح بالفعل.
- تحقق من TTL على السجل المعني. إجابة "خاطئة" تطابق ما كان السجل يقوله سابقاً، بعد خمس دقائق من تغييرك، عادة ليست خللاً — إنها تخزين مؤقت.
- بعد ذلك فقط انظر إلى طبقة التطبيق/الخادم، بمجرد تأكيد أن DNS يتحلل حيث تتوقع.
تخطي مباشرة إلى الخطوة 4 هو أكبر مضيعة وقت أراها — إعادة تشغيل خدمات، وفحص قواعد جدار الحماية، وإعادة نشر كود، بينما المشكلة الفعلية كانت تفويض خادم أسماء قديم من نقل نطاق قبل ثلاثة أيام.
البريد هو حيث تؤذي أخطاء DNS أكثر
سوء إعداد DNS لموقع ويب يظهر عادة فوراً ويُصلح بسرعة. سوء إعداد DNS للبريد أكثر خداعاً — قد يستمر البريد في "العمل" لأسابيع بينما يهبط بصمت في مجلدات السبام، لأن SPF وDKIM وDMARC إشارات سمعة، لا فشل صريح. غطيت هذا تحديداً في لماذا تصل رسائلك إلى مجلد السبام: دليل عملي لتحسين وصول البريد، لأنه يستحق تعمقاً خاصاً به بدلاً من فقرة هنا.
العادة التي تستحق البناء
تعامل مع تغييرات DNS بنفس العناية التي تُعامل بها نشر إنتاج: اعرف TTL الحالي قبل أن تلمس أي شيء، غيّر شيئاً واحداً في كل مرة، وتحقق من مصدر موثوق بدلاً من الثقة بأول إجابة مخزّنة مؤقتاً تحصل عليها. نادراً ما يتعطل DNS من تلقاء نفسه — يتعطل حين يُغيَّر بإهمال، ثم يستغرق ساعات ليتعافى بشكل مرئي بسبب التخزين المؤقت، ما يجعل الخطأ يبدو أسوأ بكثير مما كان يجب أن يكون.