دليل سجلات DNS: السجلات الأكثر تأثيراً والتي تعطل المواقع

معظم حالات التوقف التي يُعلن عنها كـ \"الموقع معطل\" تعود في حقيقتها إلى نظام DNS. فالخادم سليم، والموقع سليم، لكن هناك قيمة في سجل نصي تشير إلى المكان الخاطئ — أو لا تزال مخزنة مؤقتاً لتشير إلى الخادم القديم.

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

إليك وظيفة كل نوع من سجلات DNS وأبرز الأخطاء الشائعة في كل منها.

سجلا A و AAAA — مكان استضافة الموقع

يربط سجل A اسم النطاق بعنوان بروتوكول IPv4. بينما يربطه سجل AAAA ببروتوكول IPv6.

example.com.      A      203.0.113.10
example.com.      AAAA   2001:db8::1
www.example.com.  A      203.0.113.10

إذا كان هذان السجلان غير صحيحين أو مفقودين، فلن يعمل أي شيء آخر في هذه الصفحة.

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

حول بروتوكول IPv6: في عدة أسواق، تعمل نسبة عريضة من زيارات الجوال عبر IPv6 حصراً وتصل إلى مواقع IPv4 القديمة من خلال ترجمة الشبكات عبر شركات الاتصالات، مما يضيف تأخيراً زمنياً لكل اتصال. فإذا كانت استضافتك تدعم IPv6، فإن إضافة سجل AAAA مجانية تماماً وتلغي تلك القفزة.

سجل MX — وجهة استلام البريد الإلكتروني

example.com.  MX  10 mx1.provider.com.
example.com.  MX  20 mx2.provider.com.

يسرد الخوادم المسؤولة عن قبول رسائل البريد لنطاقك. ورقم الأولوية الأقل هو الذي يفوز ويُعتمد أولاً؛ بينما تمثل الأرقام الأعلى خوادم بديلة واحتياطية.

أمران يخلط الناس بينهما دائماً:

يتحكم سجل MX في البريد الوارد فقط. فإذا كانت رسائلك الصادرة تنتهي في مجلد الرسائل غير المرغوب فيها (Spam)، فالمشكلة ليست في MX — بل في سجلات SPF و DKIM و DMARC، وتلك تُضبط في سجلات TXT.

يجب أن يشير سجل MX إلى اسم نطاق (Hostname)، وليس إلى عنوان IP مجرد إطلاقاً. فكتابة MX 10 203.0.113.5 غير صالحة برمجياً، وسترفض بعض خوادم البريد العالمية استلام الرسائل من نطاق مضمّن بهذا الشكل.

سجل NS — خوادم الأسماء المعتمدة والموثوقة

example.com.  NS  ns1.provider.com.
example.com.  NS  ns2.provider.com.

خوادم الأسماء الموثوقة التي تقدم إجابات الاستعلام الرسمية لنطاقك. ويجب أن تتطابق هذه السجلات مع ما هو مضبوط لدى مسجل النطاق (Registrar) — فسجلات NS داخل المنطقة وتفويض المسجل أمران مختلفان، وكثيراً ما يحدث تضارب بينهما.

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

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

سجل TXT — الحاوية متعددة الاستخدامات

سجلات نصية حرة، تُستخدم اليوم لمجموعة متزايدة من السياسات وإجراءات التحقق:

• سجل SPF — الخوادم المخولة بإرسال البريد باسمك: v=spf1 include:_spf.google.com ~all
• سجل DMARC — سياسة الحظر والتعامل مع التزييف، عند _dmarc.example.com
• سجل DKIM — المفتاح العام للتشفير، عند selector._domainkey.example.com
• التحقق من ملكية النطاق — Google Search Console و Microsoft 365 و Atlassian و Zoom وغيرها الكثير.

قاعدتان يقع فيهما الكثيرون:

سجل SPF واحد فقط لكل نطاق. وجود سجلين نصيين يبدآن بـ v=spf1 هو خطأ دائم يجعل كلا السجلين معطلين ولاغيين تماماً. يحدث هذا عند التعاقد مع أداة أو مزود جديد يقوم بإضافة سجله الخاص بدلاً من تعديل السجل القائم ودمجه. ادمجهما دائماً في سطر واحد.

تراكم سجلات TXT بمرور الوقت. تحمل معظم النطاقات القديمة سجلات تحقق لخدمات توقفت عن استخدامها منذ سنوات. هي غير ضارة ظاهرياً لكنها تسبب فوضى، وفي وسط هذه الفوضى يختبئ سجل SPF ثانٍ معطل. دقق هذه السجلات سنوياً ونظفها.

سجل CAA — تحديد من يُسمح له بإصدار شهادات SSL لك

أكثر أنواع السجلات إهمالاً في هذه القائمة رغم أهميته الفائقة.

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issuewild ";"
example.com.  CAA  0 iodef "mailto:security@example.com"

يحدد سجل CAA هيئات الشهادات (CAs) المصرح لها بإصدار شهادات أمان لنطاقك. فبدونه، يمكن لأي هيئة عامة حول العالم إصدار شهادة باسمك. ومع وجوده، تقتصر الصلاحية على من تحددهم بالاسم حصراً.

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

نقطتان لضبط السجل بإتقان: أدرج كل هيئة تستخدمها فعلياً — بما في ذلك أي هيئة تعتمدها شبكة CDN أو الاستضافة نيابة عنك — واستخدم issuewild ";" لمنع استخراج شهادات شاملة (Wildcard) إذا كنت لا تستخدمها.

سجل SOA — البيانات الوصفية لمنطقة النطاق

سجل واحد لكل منطقة، ويُنشأ تلقائياً غالباً. والحقل الأهم الذي يجدر بك معرفته هو الرقم التسلسلي (Serial Number): حيث يزداد قيمته في كل مرة يجري فيها تعديل المنطقة. وأثناء نقل المواقع، إذا لم يتغير هذا الرقم، فهذا يعني أن تعديلاتك لم تُنشر بعد. وهذا الفحص بمفرده يحل الكثير من الارتباك حول ما إذا كانت التعديلات قد طُبقت فعلاً.

مدة الصلاحية (TTL): ما يجعل نقل المواقع مؤلماً

يحمل كل سجل قيمة Time To Live — وهي عدد الثواني المسموح لخوادم الإنترنت بتخزين إجابة السجل مؤقتاً في ذاكرتها.

فالسجل المضبوط بـ TTL قدره 24 ساعة قد يستغرق يوماً كاملاً ليتحدث عالمياً. ولا توجد وسيلة لتسريع ذلك بعد وقوع التغيير. فبمجرد أن يخزن خادم الإنترنت الإجابة القديمة، سيستمر في تقديمها حتى انتهاء مدة TTL المحددة.

التقنية الاحترافية التي تجعل نقل المواقع سلساً وسريعاً:

1. قبل 48 ساعة من عملية النقل، خفض قيمة TTL للسجلات التي ستغيرها إلى 300 ثانية.
2. انتظر حتى تنتهي صلاحية مدة TTL القديمة تماماً، ليتأكد التقاط كافة الخوادم للقيمة القصيرة الجديدة.
3. نفذ التغيير الفعلي. سينتشر الآن في غضون خمس دقائق فقط.
4. بعد يوم واحد من استقرار النقل، أعد رفع قيمة TTL إلى 3600 ثانية أو أكثر.

الخطوة الرابعة مهمة للغاية — فبقاء مدة TTL منخفضة بشكل دائم يفرض استعلامات بحث متكررة ويؤدي لبطء طفيف في سرعة أول اتصال لزوار موقعك.

هذا هو الإجراء الأكثر نفعاً على الإطلاق في نظام DNS، ويجب تنفيذه مسبقاً، إذ يستحيل تطبيقه بأثر رجعي.

لماذا تعرض الأدوات المختلفة إجابات متباينة أحياناً؟

لأنها تستعلم من خوادم حل مختلفة، وتلك الخوادم تحتفظ بنسخ مخبأة متباينة استناداً إلى توقيت آخر استعلام لها ومدة TTL المقررة.

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

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

قائمة مراجعة لنقل المواقع بأمان (Migration Checklist)

1. خذ نسخة احتياطية كاملة ومصدرة لكافة سجلات المنطقة الحالية قبل لمس أي شيء.
2. خفض مدد TTL إلى 300 ثانية قبل الموعد بـ 48 ساعة.
3. ابنِ المنطقة بالكامل وسجلاتها لدى المزود الجديد قبل تحويل تفويض النطاق.
4. حول خوادم الأسماء (Nameservers) لدى مسجل النطاق الرسمي.
5. تحقق من عمل سجلات A و AAAA و MX و TXT و CAA بنجاح لدى المزود الجديد.
6. أرسل رسالة بريد إلكتروني تجريبية في كلا الاتجاهين (إرسال واستقبال).
7. أبقِ المنطقة القديمة نشطة لمدة أسبوع كامل — فالخوادم التي خزنت سجلات NS القديمة ستظل تسألها لأيام.
8. أعد رفع مدد TTL للوضع الطبيعي بمجرد استقرار حركة المرور تماماً.

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