نقل DNS مع فصل البريد عن الموقع: تسلسل التحويل الصحيح

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

حدد من يدير النطاق ومن يشغل كل خدمة

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

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

اجمع السجلات من المصدر الفعلي

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

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

صنف السجلات بحسب الوظيفة

نقل TXT يتطلب المحافظة على القيمة الكاملة وفق طريقة تمثيل اللوحة، خصوصاً السجلات الطويلة. لا تنشئ سجل SPF إضافياً متعارضاً عند جمع خدمات الإرسال؛ راجع السياسة ككل. واحتفظ بأسماء DKIM الفعلية المستخدمة بدلاً من افتراض اسم selector موحد لجميع المزودين.

أنشئ المنطقة الجديدة مع الحفاظ على سلوك الخدمات

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

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

خطط لـTTL والتعايش بين المصدر والوجهة

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

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

عالج DNSSEC كتسلسل مستقل

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

يعرض دليل Cloudflare لترحيل DNSSEC مساراً يحافظ على التحقق عند دعم متطلباته. اختر مع المختص تسلسلاً تدعمه المنصتان والمسجل؛ لا تعطّل DNSSEC كإجراء افتراضي أو تنسخ خطوات مزود إلى آخر دون مطابقة. اختبر بمحللات تتحقق من التوقيع قبل التسليم وبعده.

حوّل إدارة DNS ثم اختبر الخدمات منفصلة

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

اختبر الموقع والنطاقات الفرعية والشهادة، واستقبال البريد من الخارج وإرساله والتحقق من التوثيق وفق اختبارات معتمدة. راجع إشعارات التطبيقات والطابعات والتحقق من الخدمات. لا تعني صحة MX أن نموذج الموقع يرسل من خادمه بإعداد صحيح، ولا تعني صحة A أن DNSSEC أو IPv6 يعملان لدى الجميع.

ضع خطة رجوع تحافظ على تطابق المنطقة

في مثال افتراضي، شركة تنقل موقعها وتبقي Microsoft 365 لا تحتاج تغيير MX إلى مزود الموقع الجديد. وفي مثال آخر، نقل nameservers مع ترك سجل DKIM في اللوحة القديمة قد يضعف توثيق الرسائل رغم استمرار استقبالها. لذلك يجب أن يشمل التقرير خدمات الإرسال والاستقبال والتحقق معاً.

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

أسئلة شائعة عن نقل DNS والبريد

هل يجب نقل البريد مع الموقع؟

لا؛ يمكن أن يظلا لدى مزودين مختلفين. حافظ على سجلات البريد والتوثيق الصحيحة، وراجع التوجيه المحلي في خادم الموقع إن كان يرسل للنطاق.

هل يكفي تصدير المنطقة واستيرادها؟

يختصر ذلك العمل، لكنه يحتاج مراجعة خصائص المزود والتفويض وDNSSEC والوكيل واختبارات الخدمات. قد لا يمثل الملف كل إعداد تشغيلي.

متى ألغي DNS القديم؟

بعد تحقق الانتقال والتوقيع والخدمات وانقضاء التداخل المناسب للقيم الفعلية وخطة الرجوع، مع الاحتفاظ بالتصدير وسجل التسليم.

اطلب نقلاً يفصل خدمات النطاق

أرسل مزود DNS والمسجل وخدمات الموقع والبريد وأسماء التطبيقات عبر طلب عرض نقل DNS. اطلب ضمن خدمة إدارة DNS جرداً ومقارنة واختبار DNSSEC وتسلسلاً يحافظ على وجهات البريد والموقع حتى يحين موعد تحويل كل منهما.