# دليل تحويل دومين وDNS وTLS لسيرفر جديد | SwissOctet Insights

https://swissoctet.com/arz/insights/dns-tls-cutover-runbook/

SwissOctet / رؤى / الويب و onion الويب و onion تطبيقي · قراءة 4 دقيقة

دليل تحويل دومين وDNS وTLS لسيرفر جديد

جهّز توجيه اسم المضيف والشهادات والرجوع مع بعض عشان الترحيل يغيّر السيرفر من غير ما يكسر هوية الموقع أو الاتصالات الآمنة.

بقلم SwissOctet Editorial احفظ الدليل انسخ الرابط

في هذه الصفحة 01 احصر الأسماء والاعتماديات 02 جهّز توجيه اسم المضيف على السيرفر الجديد 03 اختر طريقة تحقق للشهادة 04 خطط نافذة الكاش قبل تغيير DNS 05 تحقق من DNS وTLS بشكل منفصل 06 خلي الرجوع قرار بيانات كمان 07 راقب الموقع بعد التحويل قائمتك العملية المصادر وقراءات إضافية العودة إلى المكتبة الإجابة المباشرة جهّز السيرفر والشهادة لاسم المضيف المقصود، واختبر التطبيق قبل تغيير DNS العام، وخلي البيئة القديمة متاحة خلال الانتقال. تحقق من السجلات الموثوقة والإجابات المخزنة وTLS بشكل مستقل. تحديث DNS لوحده مش بيثبت إن التطبيق والشهادة الصحيحين بيتم تقديمهم.

01 احصر الأسماء والاعتماديات

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

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

02 جهّز توجيه اسم المضيف على السيرفر الجديد

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

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

03 اختر طريقة تحقق للشهادة

إصدار الشهادة محتاج إثبات التحكم في الأسماء المطلوبة. Let's Encrypt بتوثق HTTP-01 وDNS-01 ضمن طرق التحقق بتاعتها. تحقق HTTP بيعتمد على تقديم التحدي المطلوب بشكل صحيح؛ تحقق DNS بيستخدم سجل DNS محدد وممكن يدعم إصدار wildcard. اختر طريقة تناسب النشر الفعلي وتقدر تتحافظ عليها بأمان.

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

04 خطط نافذة الكاش قبل تغيير DNS

سجلات DNS بتحمل time-to-live بيستخدمه الـ resolvers لما يخزنوا الإجابات مؤقتًا. تغيير السجل مش بيستبدل كل نتيجة مخزنة فورًا. لو الانتقال بيستفيد من TTL أقصر، خطط للتعديل بدري كفاية عشان الإجابات المخزنة قبل كده تنتهي. خلي البيئتين القديمة والجديدة قادرين على التعامل مع الانتقال اللي صممته.

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

المرحلة الإجراء الشرط قبل التقدم

التحضير احصر السجلات واضبط نقطة النهاية الجديدة التطبيق شغال للأسماء المقصودة

الشهادة أصدر وثبّت الشهادة السلسلة الصحيحة واسم المضيف يتحققوا

الانتقال حدّث سجلات DNS المخططة بس تحويل البيانات والرجوع متحددين

المراقبة افحص النتائج الموثوقة ونتائج العملاء رحلات المستخدم تنجح من خلال نقطة النهاية الجديدة

الإكمال اسحب الخدمة القديمة بعد التحقق الترافيك المتبقي واحتياجات الاسترداد اتراجعوا

05 تحقق من DNS وTLS بشكل منفصل

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

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

06 خلي الرجوع قرار بيانات كمان

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

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

07 راقب الموقع بعد التحويل

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

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

حوّله إلى إجراء قائمتك العملية.

✓ احصر كل اسم مضيف واحتفظ بسجلات DNS غير المتعلقة.

✓ اختبر توجيه اسم المضيف قبل التحويل العام.

✓ اختر وأتمت تحدي شهادة مناسب.

✓ خطط لتغييرات TTL وانتقال البيانات.

✓ تحقق من DNS وTLS من خلال فحوصات منفصلة.

✓ احتفظ بوصول الرجوع وحل الكتابات الجديدة قبل الرجوع.

نزّل القائمة

أسئلة شائعة التفاصيل اللي تفرق.

تغيير سجل A بيفعّل HTTPS؟ +

لأ. DNS بيختار نقطة نهاية؛ نقطة النهاية دي لسه محتاجة توجيه اسم المضيف الصحيح وشهادة سارية ومثبتة.

أقدر أرجع سجل DNS بس لو حاجة باظت؟ +

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

شهادة wildcard ضرورية دايمًا؟ +

لأ. اختر أسماء الشهادة والتحقق حسب أسماء المضيف الفعلية. الـ wildcard ليه تغطية محددة ومتطلبات تحقق؛ مش اختصار ترحيل عالمي.

المراجع الأساسية اذهب إلى المصدر.

تدعم هذه المراجع المفاهيم التقنية في هذا الدليل. اتبع الوثائق الحالية قبل تغيير نظام إنتاجي.

Let's Encrypt: أنواع التحديات letsencrypt.org

IETF RFC 1034: مفاهيم ومرافق DNS datatracker.ietf.org

Mozilla MDN: Transport Layer Security developer.mozilla.org

إرشاد تحريري من SwissOctet. الأمثلة توضيحية. يجب التحقق من مواصفات الخدمة والخيارات المتاحة والشروط التعاقدية بشكل منفصل.

اربط المعرفة بنية تحتية ذات صلة.

Canvas Web سويسرا Vector VPS سويسرا Pulse NVMe سويسرا

احتفظ بالخيط ملاحظاتك الميدانية التالية.

استكشف كل الأدلة

ملاحظة ميدانية / 01

+

السحابة وVPS الأساس

كيف تختار VPS دون تخمين

حوّل فكرة تطبيق إلى ميزانية موارد مفيدة، ثم قارن CPU والذاكرة والتخزين والنقل معاً.

قراءة 4 دقيقة اقرأ الدليل

ملاحظة ميدانية / 02

+

الويب و onion الأساس

استضافة الويب أو VPS: اختر العمل الذي تريد توليه

قارن متطلبات التطبيق والتحكم ومسؤوليات الصيانة بدلًا من اعتبار VPS الخطوة التالية التلقائية لكل موقع.

6 دقيقة قراءة اقرأ الدليل

ملاحظة ميدانية / 03

+

الويب و onion تطبيقي

انشر خدمة onion من غير ما تغفل عن التطبيق

خطط لنشر onion شرعي مع تعريض خلفي مضبوط ومراجعة محتوى دقيقة واسترداد مفتاح الخدمة ونموذج وصول صريح للجمهور.

قراءة 4 دقيقة اقرأ الدليل