كلاود
بنية تحتية

إدارة DNS باحتراف: TTL والسجلّات وتفادي الأعطال

كلاود|٨ أكتوبر ٢٠٢٦|6 دقائق قراءة|١٣٨ مشاهدة

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

نظام أسماء النطاقات DNS هو الطبقة التي تحوّل اسم نطاقك المقروء مثل example.sa إلى عنوان IP الرقمي لسيرفرك، فبدونه لا يصل أحد إلى موقعك ولا بريدك. إدارة DNS باحتراف تقوم على أربعة أعمدة: فهم السجلّات الأساسية ووظيفة كل نوع، ضبط قيمة TTL التي تحدد كم يُخزَّن الجواب مؤقتاً قبل إعادة السؤال، خفض TTL مسبقاً قبل أي نقل لتسريع الانتشار، والتأكد من اكتمال سجلّات البريد (MX وSPF وDKIM وDMARC) حتى تصل رسائلك صندوق الوارد لا مجلد المهملات. أغلب أعطال المواقع والبريد التي تبدو غامضة سببها خطأ بسيط في هذه الطبقة.

القاعدة العملية المختصرة: اعرف سجلّاتك (A للعنوان، MX للبريد، TXT لسجلّات التحقق)، أبقِ TTL معتدلاً في الوضع الطبيعي (ساعة مثلاً) واخفضه إلى خمس دقائق قبل أي تغيير مخطط له بيوم، ولا تنشئ نطاقاً للبريد دون SPF وDKIM صحيحين. بقية الدليل يشرح كل نوع سجلّ ومتى تستعمله، وكيف يعمل TTL فعلياً في الانتشار والتخزين المؤقت، وأشهر الأخطاء التي ترسل بريدك بعيداً، وحدود بروكسي الحافة على سجلّاتك.

السجلّات الأساسية ووظيفة كل نوع

ملف منطقة DNS لنطاقك مجموعة سجلّات، كل نوع يخدم غرضاً. معرفة الأنواع الستة الأكثر استعمالاً تكفي لإدارة أغلب النطاقات:

النوعالوظيفةمثال الاستعمال
Aيربط الاسم بعنوان IPv4توجيه النطاق لسيرفرك
AAAAيربط الاسم بعنوان IPv6دعم الجيل السادس من العناوين
CNAMEاسم مستعار يشير لاسم آخرربط www بالنطاق الجذر
MXيحدد خوادم استقبال البريدتوجيه بريد نطاقك
TXTنص حر للتحقق والسياساتSPF وDKIM وDMARC وملكية النطاق
NSيحدد خوادم الأسماء المسؤولةتفويض إدارة النطاق

سجلّ A هو الأكثر شيوعاً، فهو الذي يقول للعالم أين يسكن موقعك. CNAME مفيد لكن بقيد مهم: لا يُوضع على النطاق الجذر عادة، ولا يجتمع مع سجلّات أخرى لنفس الاسم. سجلّات MX ترتّب خوادم البريد بأولوية، فالرقم الأصغر أعلى أولوية. أما TXT فصار عمود منظومة البريد الحديثة لأنه يحمل سياسات التحقق التي تمنع انتحال نطاقك.

TTL: كيف يعمل الانتشار والتخزين المؤقت

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

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

سجلّات البريد: لماذا تصل رسائلك بعيداً عن صندوق الوارد

أكثر مشكلة DNS إيلاماً للشركات أن بريدها المؤسسي لا يصل صندوق الوارد للجهات الحكومية أو العملاء. السبب غالباً نقص في سجلّات التحقق الثلاثة التي صارت الأنظمة الحديثة تشترطها:

  • SPF: سجلّ TXT يعلن أي الخوادم يحق لها إرسال بريد باسم نطاقك. بدونه تُعامَل رسائلك بريبة.
  • DKIM: توقيع تشفيري يُضاف لكل رسالة ويُتحقق منه عبر مفتاح عام في سجلّ TXT، فيثبت أن الرسالة لم تُعدّل ولم تُنتحل.
  • DMARC: سجلّ TXT يربط SPF وDKIM ويخبر الخوادم المستقبلة ماذا تفعل بالرسائل التي تفشل التحقق، ويرسل لك تقارير.

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

حدود بروكسي الحافة على سجلّاتك

حين تضع نطاقك خلف بروكسي حافة يمرّر الزيارات عبر شبكته، يتغيّر سلوك سجلّاتك. سجلّ A لموقعك يشير حينها إلى عنوان الحافة لا إلى أصلك مباشرة، فتخفي عنوان سيرفرك الحقيقي وتكسب طبقة حماية، لكنك تفقد بعض التحكم المباشر. مهم أن تفهم أن سجلّات البريد MX يجب ألا تمرّ عبر بروكسي الويب، فالبريد بروتوكول مختلف، وتمريره خطأ شائع يعطّل الاستقبال.

القاعدة: مرّر سجلّات الويب (النطاق الجذر وwww) عبر الحافة إن أردت حمايتها وتسريعها، واترك سجلّات البريد وأي خدمة غير HTTP تشير مباشرة لأصلك دون تمرير. راقب أيضاً أن خفض TTL قبل النقل قد لا يعمل كما تتوقع إن كانت الحافة تدير جوابها بمنطقها الخاص، فتحقق من الانتشار من عدة مواقع قبل أن تثق أن التغيير وصل الجميع.

أخطاء شائعة تعطّل الموقع

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

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

خوادم الأسماء والتفويض

سجلّات NS هي التي تقول للعالم أي خوادم أسماء مسؤولة عن نطاقك، فهي أعلى نقطة في سلسلة الثقة. حين تسجّل نطاقك يشير المسجّل إلى خوادم أسماء معيّنة، وهذه الخوادم هي التي تحمل ملف منطقتك وتجيب على كل الاستعلامات. تغيير خوادم الأسماء نقلة كبرى لأنها تنقل مسؤولية كل السجلّات دفعة واحدة، لذلك حين تنقل نطاقك لمزوّد جديد تأكد أن ملف المنطقة كامل عند المزوّد الجديد قبل أن تبدّل NS، لا بعده.

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

أدوات فحص DNS قبل أن تثق

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

قائمة تحقق عملية

قبل أي تغيير DNS، امشِ على هذه الخطوات: صدّر ملف المنطقة الحالي واحفظه نسخة احتياطية، اخفض TTL للسجلّات المتأثرة قبل يوم من التغيير، طبّق التغيير وتحقق من انتشاره من عدة مواقع جغرافية لا من جهازك وحده، راقب البريد والموقع لبضع ساعات بعد التغيير، ثم أعد رفع TTL بعد استقرار الوضع. لسجلّات البريد تحديداً، تأكد أن SPF وDKIM وDMARC موجودة وصحيحة قبل أن ترسل أي حملة، واختبر بإرسال رسالة لعنوان خارجي وافحص ترويستها. DNS المُدار بانضباط طبقة صامتة لا تسمع عنها أبداً، وهذا بالضبط علامة أنها تعمل كما يجب.

مشاركة