تكاد كل مشكلة موقع أو بريد تتصل بنا الشركات بسببها تنتهي إلى DNS. انتقل الموقع إلى استضافة جديدة وما زال نصف العالم يرى القديمة. أو البريد الصادر من نطاقك يسقط في مجلد السبام. أو نطاق فرعي لا يتذكّر أحد إنشاءه يشير إلى خادم أُوقِف قبل سنتين. وفي كل حالة يكون السبب الجذري حفنةَ سجلّات نصّية صغيرة لم ينظر إليها أحد منذ تسجيل النطاق.
وDNS ليس معقّداً، بل غير مألوف — وهذا شيء آخر. في هذا الدليل: السجلّات التي تهمّ نطاق أعمال فعلاً، وماذا يفعل كلٌّ منها، والأخطاء المحدَّدة التي تسبّب أكبر ضرر، وكيف تفحص نطاقك في عشر دقائق.
الخلاصة السريعة
DNS يترجم اسم نطاقك إلى العناوين التي تستعملها الأجهزة. ولنطاق أعمال عادي تهمّك سبعة أنواع: A (يوجّه النطاق إلى عنوان IPv4 لخادم)، وAAAA (نظيره لـIPv6)، وCNAME (يوجّه اسماً إلى اسم آخر)، وMX (يحدّد الخادم الذي يستقبل بريدك)، وTXT (يحمل سلاسل التحقّق وتوثيق البريد)، وNS (يحدّد خوادم الأسماء المخوَّلة لنطاقك)، وCAA (يحدّد جهات إصدار شهادات SSL المسموح لها). والثلاثة التي تسبّب أكبر ضرر عند الخطأ هي MX وTXT (SPF وDKIM وDMARC) وNS.
ماذا يفعل DNS فعلاً
الأجهزة تجد بعضها بعناوين رقمية، والناس يتذكّرون الأسماء. وDNS هو النظام الذي يحوّل أحدهما إلى الآخر، وهو يعمل سلسلةَ إحالات لا استعلاماً واحداً.
فحين يكتب أحدهم نطاقك، يسأل حاسوبه محلِّلاً، فيسأل المحلِّلُ الخوادمَ الجذرية عن خوادم الأسماء التي تتولّى .ae، فتجيب بخوادم أسماء نطاقك، فتُعيد هذه أخيراً السجلَّ الفعلي. ثم يُخزَّن الجواب مؤقّتاً — في المحلِّل، وفي نظام التشغيل، وفي المتصفّح — لمدّة تحدّدها سجلّاتك.
وهذا التخزين المؤقّت مصدرُ أغلب الالتباس في DNS. فحين تغيّر سجلّاً يكون التغيير فورياً عند خوادم أسمائك وتدريجياً في كل مكان آخر: بعض الزوّار يرى القيمة الجديدة خلال ثوانٍ، وبعضهم يبقى على القديمة حتى تنتهي صلاحية نسخته المخزَّنة. ولهذا فإن «غيّرتُه وما زال يُظهر الموقع القديم» أمر طبيعي لا عطل.
السجلّات التي تهمّ
سجلّ A — النطاق يشير إلى خادم
يربط سجلّ A اسماً بعنوان IPv4: its.ae ← 116.202.222.249. وهذا ما يجعل موقعك يُحمَّل. ولأغلب النطاقات اثنان على الأقل: واحد للنطاق المجرَّد وواحد لـwww.
الخطأ: تغيير الاستضافة وتحديث سجلّ A للنطاق المجرَّد دون www، أو العكس. فيصل نصف زوّارك إلى الموقع الجديد ونصفهم إلى القديم، ويتوقّف ذلك على كيفية كتابتهم للعنوان. افحص الاثنين دائماً.
سجلّ AAAA — الشيء نفسه لـIPv6
مطابق في الغرض لصيغة العناوين الأحدث. فإن كانت استضافتك توفّر IPv6، فوجود سجلّ AAAA صحيح أمر جيّد. أما وجود سجلّ قديم متروك فأسوأ من عدمه، لأن الأجهزة على شبكات IPv6 ستفضّله فتصل إلى الخادم الخطأ. وعند نقل الاستضافة إمّا أن تحدّث سجلّ AAAA أو تحذفه.
سجلّ CNAME — اسم يشير إلى اسم
يقول CNAME إن «هذا الاسم كنية لذاك»: www.its.ae ← its.ae. وبه تُوجَّه النطاقات الفرعية إلى خدمات خارجية — صفحة حالة، أو نظام دعم، أو منصّة تسويق.
قاعدتان توقعان الناس: لا يجتمع CNAME مع سجلّات أخرى على الاسم نفسه، ولهذا لا تستطيع عادةً وضع CNAME على نطاقك المجرَّد — فالنطاق يحتاج MX وسجلّات أخرى هناك. وسجلّ CNAME يشير إلى اسم لم يعد موجوداً يُنتج عطلاً محيّراً في التشخيص، لأن السجلّ نفسه يبدو سليماً تماماً.
سجلّ MX — أين يُسلَّم بريدك
تخبر سجلّات MX خوادمَ البريد الأخرى أي جهاز يقبل البريد لنطاقك. وتحمل رقم أولوية، والأقلّ هو المفضَّل: خادم بأولوية 10 يُجرَّب قبل خادم بأولوية 20.
وأغلى خطأ ممكن: تغيير مزوّد الاستضافة وترك المزوّد الجديد ينشئ سجلّات MX افتراضية تشير إلى نفسه، بينما بريدك يعيش فعلاً على Microsoft 365 أو Google Workspace. فيُحوَّل البريد الوارد بصمت إلى صندوق لا يراقبه أحد على الخادم الجديد. لا يرتدّ، ولا يعطي خطأً، بل يتوقّف عن الوصول ببساطة — وتكتشف ذلك بعد أيام حين يسأل عميل لماذا لم تردّ عليه.
قبل أي نقل استضافة، دوِّن سجلّات MX الحالية. وبعد النقل، افحصها ثانيةً. هذه العادة وحدها تمنع أشدّ حوادث DNS ضرراً على الشركات.
سجلّات TXT — التحقّق وتوثيق البريد
تحمل سجلّات TXT نصّاً حرّاً، ولها استعمالان مهمّان.
التحقّق من ملكية النطاق. تطلب جوجل ومايكروسوفت وغيرهما إضافة سلسلة محدَّدة لإثبات سيطرتك على النطاق. غير ضارّة، ويمكن تركها بعد إضافتها.
توثيق البريد — SPF وDKIM وDMARC. هذه السجلّات هي التي تقرّر هل يصل بريدك إلى صناديق الوارد أم إلى مجلدات السبام. فـSPF يعدّد الخوادم المسموح لها بالإرسال باسم نطاقك، وDKIM يضيف توقيعاً تشفيرياً يثبت أن الرسالة لم تُعدَّل، وDMARC يخبر الخوادم المستقبِلة بما تفعله حين تفشل تلك الفحوص، وإلى أين ترسل التقارير.
ومنذ 2024 يشترط كبار مزوّدي البريد التوثيقَ على المرسِلين بكثافة، ويعاقبون غيابه بصورة متزايدة على الجميع. فإن كان بريد شركتك يسقط في السبام ولم تنظر في هذه السجلّات الثلاثة، فهناك تبدأ.
وخطأ SPF الكلاسيكي: أكثر من سجلّ SPF على النطاق الواحد. فالمواصفة تسمح بواحد فقط، ووجود اثنين يعني فشل الفحص — وغالباً ما يحدث حين يضيف أحدهم سجلّاً ثانياً لأداة تسويق جديدة بدل دمجه في السجلّ القائم.
سجلّات NS — من يتولّى DNS نطاقك
تسمّي سجلّات NS الخوادمَ التي تحمل الأجوبة المخوَّلة لنطاقك. وتُضبَط عند المسجِّل، وهي التي تحدّد أي لوحة تحكّم تتحكّم بنطاقك فعلاً.
وهذا السجلّ أكثر ما يهدر الساعات. تعدّل شركةٌ سجلّات DNS في لوحة استضافتها، فلا ترى تغييراً، فتستنتج أن DNS معطوب — بينما خوادم أسماء النطاق تشير إلى مكان آخر تماماً، عند المسجِّل عادةً أو عند شبكة توصيل محتوى أُضيفت قبل سنوات. والسجلّات التي تُعدَّل حقيقية، لكنها ببساطة مُهمَلة، لأن لا أحد يسأل ذلك الخادم.
قبل تعديل أي سجلّ DNS، تأكّد إلى أين تشير خوادم أسمائك. فالتعديل في المكان الخطأ لا أثر له إطلاقاً.
سجلّات CAA — من يجوز له إصدار شهادات SSL لنطاقك
يقيّد سجلّ CAA جهاتِ إصدار الشهادات المسموح لها بإصدار شهادات لنطاقك. اختياري وهادئ وتحسينٌ أمني حقيقي: يمنع إصدار شهادة لنطاقك من جهة لم تقصد استعمالها قطّ. ويستحقّ الإضافة متى عرفت أي جهة يستعملها مزوّدك.
TTL: لماذا تستغرق التغييرات وقتاً
لكل سجلّ مدّة بقاء (TTL) — كم يجوز للمحلِّلات تخزين الجواب. فقيمة 3600 تعني ساعة واحدة.
والأسلوب العملي يهمّ عند التخطيط لنقل: اخفض الـTTL قبل النقل لا أثناءه. أنزله إلى 300 ثانية قبل يوم على الأقل، ثم نفّذ النقل، وتأكّد أن كل شيء يعمل، ثم أعده. أما خفض الـTTL في اللحظة نفسها التي تُجري فيها التغيير فلا يفيد، لأن القيمة الطويلة القديمة مخزَّنة سلفاً ويظلّ التغيير يستغرق ساعات.
ويجدر أن تعرف أيضاً: «الانتشار» ليس عملية تجري. لا شيء يُدفَع إلى أي مكان. بل الأجوبة القديمة المخزَّنة تنتهي صلاحيتها في أوقات مختلفة وأماكن مختلفة.
افحص نطاقك في عشر دقائق
افعل هذا الآن لأي نطاق يعتمد عليه عملك:
١. تأكّد من خوادم أسمائك. افحص عند المسجِّل أي خوادم أسماء يستعملها النطاق، وتأكّد أنها المكان الذي كنت تعدّل فيه السجلّات.
٢. افحص سجلّي A معاً. النطاق المجرَّد وwww يجب أن يشيرا إلى الخادم الصحيح. حمّل الاثنين في المتصفّح.
٣. دوِّن سجلّات MX. وتأكّد أنها تشير إلى المزوّد الذي يحمل صناديقك فعلاً. واحتفظ بهذه الملاحظة في مكان تجده قبل نقلك التالي.
٤. تأكّد من وجود سجلّ SPF واحد بالضبط. واحد، لا صفر ولا اثنان، ويجب أن يعدّد كل خدمة ترسل باسمك — مزوّد بريدك، ونموذج التواصل في موقعك، وأداة نشرتك، ونظام فوترتك.
٥. افحص هل يوجد DMARC أصلاً. كثير من نطاقات الأعمال بلا أي سجلّ. وسجلّ DMARC بوضع المراقبة فقط آمنُ الإضافة ويخبرك من يرسل باسم نطاقك.
٦. اسرد كل سجلّ نطاق فرعي. وابحث عن مدخلات تشير إلى خدمات لم تعد تستعملها. فالنطاق الفرعي الذي يشير إلى خادم مهجور انكشافٌ أمني حقيقي لا مجرّد فوضى.
وأي فحص من هذه يعطيك جواباً لا تستطيع تفسيره يستحقّ المعالجة قبل أن يتحوّل إلى حادث.
أين موقعنا
تدير «بيغ بانغ لحلول تقنية المعلومات» النطاقات وDNS والاستضافة وبريد الأعمال لشركات في أنحاء الإمارات — وهذا يعني عملياً أننا نقضي وقتاً طويلاً في إصلاح إعدادات DNS ضُبطت مرّة واحدة قبل سنوات على يد شخص انتقل منذ زمن.
فإن كان بريدك يسقط في السبام، أو موقعك يتصرّف تصرّفات مختلفة مع أشخاص مختلفين، أو كنت ببساطة لا تعرف من يتحكّم بـDNS نطاقك — فهذه كلها أسئلة لها أجوبة. تواصل معنا ونفحصها معك.
