# نئے سرور کے لیے ڈومین، DNS اور TLS کٹ اوور رن بک | SwissOctet Insights

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

SwissOctet / بصیرتیں / ویب اور onion ویب اور onion عملی · 4 منٹ کا مطالعہ

نئے سرور کے لیے ڈومین، DNS اور TLS کٹ اوور رن بک

ہوسٹ نام کی روٹنگ، سرٹیفکیٹس اور رول بیک ایک ساتھ تیار کریں تاکہ مائیگریشن سرور کو تبدیل کرے بغیر سائٹ کی شناخت یا محفوظ کنکشنز کو توڑے۔

از SwissOctet ایڈیٹوریل گائیڈ محفوظ کریں لنک کاپی کریں

اس صفحے پر 01 ناموں اور انحصارات کی فہرست بنائیں 02 نئے سرور پر ہوسٹ نام کی روٹنگ تیار کریں 03 سرٹیفکیٹ کی توثیق کا طریقہ منتخب کریں 04 DNS تبدیل کرنے سے پہلے کیش ونڈو کا منصوبہ بنائیں 05 DNS اور TLS کی الگ الگ تصدیق کریں 06 رول بیک کو بھی ڈیٹا کا فیصلہ بنائیں 07 سوئچ کے بعد سائٹ کا مشاہدہ کریں آپ کی عملی چیک لسٹ ذرائع اور مزید مطالعہ لائبریری پر واپس جائیں سیدھا جواب مطلوبہ ہوسٹ نام کے لیے سرور اور سرٹیفکیٹ تیار کریں، عوامی DNS تبدیل کرنے سے پہلے ایپلیکیشن کی جانچ کریں، اور منتقلی کے دوران پرانا ماحول دستیاب رکھیں۔ مستند ریکارڈز، کیش شدہ جوابات اور TLS کی آزادانہ تصدیق کریں۔ صرف DNS اپ ڈیٹ یہ ثابت نہیں کرتا کہ درست ایپلیکیشن اور سرٹیفکیٹ پیش کیے جا رہے ہیں۔

01 ناموں اور انحصارات کی فہرست بنائیں

سائٹ کے استعمال کردہ ہر ہوسٹ نام کی فہرست بنائیں، بشمول مرکزی ڈومین، عرفی نام، API اینڈ پوائنٹس اور ایپلیکیشن کال بیکس۔ ریکارڈ کریں کہ رجسٹریشن اور مستند DNS کو کون کنٹرول کرتا ہے۔ ایپلیکیشن کی میزبانی خود بخود اس کا ڈومین رجسٹر نہیں کرتی یا سرور آپریٹر کو اس کے ریکارڈز کا کنٹرول نہیں دیتی۔ نئے ماحول کی توثیق ہونے تک موجودہ ماحول تک رسائی رکھیں۔

ای میل اور فریق ثالث کی توثیق کے ریکارڈز بھی شناخت کریں جو منتقلی کو محفوظ رکھنے چاہئیں۔ ویب سائٹ کی مائیگریشن کو پورے DNS زون کو بے احتیاطی سے تبدیل نہیں کرنا چاہیے۔ مطلوبہ پتوں اور رول بیک ویلیو کے ساتھ ریکارڈ کی سطح پر تبدیلی کا منصوبہ بنائیں۔ اسناد نجی طور پر محفوظ رکھیں؛ رن بک کو اصل پاس ورڈز یا API ٹوکنز کے بجائے ذمہ داروں اور طریقہ کار کی ضرورت ہے۔

02 نئے سرور پر ہوسٹ نام کی روٹنگ تیار کریں

کنکشن وصول کرنے والی مشین کو اپنے ہوسٹ نام کے لیے مطلوبہ ایپلیکیشن پیش کرنی چاہیے۔ ویب سرور یا ہوسٹنگ پینل کو اسی کے مطابق کنفیگر کریں، عوامی دستاویز روٹ کو نجی کنفیگریشن اور اسناد سے الگ رکھیں۔ تمام مطلوبہ ناموں اور ری ڈائریکٹس کی جانچ کریں، نہ کہ صرف سرور کے پتے سے پہنچنے والے عام خوش آمدید صفحے کی۔

ایک کنٹرول شدہ ٹیسٹ طریقہ استعمال کریں جو عوامی تبدیلی سے پہلے مطلوبہ ہوسٹ نام نئے اینڈ پوائنٹ کو بھیجے۔ جہاں لاگو ہو، لاگ ان، اپ لوڈز اور ایپلیکیشن کے بنائے گئے لنکس چیک کریں۔ جانچ کے دوران ایسے جابز غیر فعال کریں جو پروڈکشن کے اعمال کی نقل کر سکیں۔ ٹیسٹ کو حقیقی میل بھیجے، ادائیگیاں لیے یا پرانے لائیو ڈیٹا بیس میں غیر ارادی تبدیلی کیے بغیر ایپلیکیشن کے رویے کو ثابت کرنا چاہیے۔

03 سرٹیفکیٹ کی توثیق کا طریقہ منتخب کریں

سرٹیفکیٹ جاری کرنے کے لیے درخواست کردہ ناموں پر کنٹرول کا ثبوت درکار ہے۔ Let's Encrypt اپنے توثیقی طریقوں میں HTTP-01 اور DNS-01 کو دستاویز کرتا ہے۔ HTTP توثیق کا انحصار مطلوبہ چیلنج کو درست طریقے سے پیش کرنے پر ہے؛ DNS توثیق متعین کردہ DNS ریکارڈ استعمال کرتی ہے اور وائلڈ کارڈ اجرا کی حمایت کر سکتی ہے۔ ایسا طریقہ منتخب کریں جو حقیقی تعیناتی سے مطابقت رکھتا ہو اور محفوظ طریقے سے برقرار رکھا جا سکے۔

جہاں ممکن ہو توثیقی اسناد کو تنگ دائرے میں رکھیں۔ DNS آٹومیشن خاص طور پر حساس ہے کیونکہ وسیع DNS اسناد ایک سے زیادہ ویب سائٹس پر اثر ڈال سکتی ہیں۔ سرٹیفکیٹ کی تجدید اور تجدید شدہ فائلوں کے سرونگ عمل تک پہنچنے کا منصوبہ بنائیں۔ پہلا کامیاب اجرا مفید ہے، لیکن سائٹ کو کام کرنے والا تجدید کا عمل اور اس کے واقعی پیش کردہ سرٹیفکیٹ کی نگرانی بھی درکار ہے۔

04 DNS تبدیل کرنے سے پہلے کیش ونڈو کا منصوبہ بنائیں

DNS ریکارڈز میں ٹائم ٹو لائیو ہوتا ہے جو ریزولورز جوابات کیش کرتے وقت استعمال کرتے ہیں۔ ریکارڈ کی تبدیلی ہر کیش شدہ نتیجے کو فوری طور پر تبدیل نہیں کرتی۔ اگر منتقلی کو مختصر TTL سے فائدہ ہو، تو ایڈجسٹمنٹ کا منصوبہ اتنی جلدی بنائیں کہ پہلے کیش شدہ جوابات کی میعاد ختم ہو سکے۔ پرانے اور نئے دونوں ماحول کو آپ کے ڈیزائن کردہ انتقال کو سنبھالنے کے قابل رکھیں۔

یہ مثالی ترتیب تیاری کو عوامی کٹ اوور سے الگ کرتی ہے۔ اس کے اوقات کو ڈومین، ریزولور کے رویے اور ایپلیکیشن کے مطابق ڈھالنا ہوگا۔ یہ کوئی عالمگیر پروپیگیشن شیڈول نہیں ہے۔ لائیو تحریروں والی مائیگریشن کے لیے ایپلیکیشن کے مخصوص ڈیٹا کٹ اوور کی بھی ضرورت ہے، ورنہ دو کام کرنے والے ویب سرورز مختلف ڈیٹا سیٹس میں تبدیلیاں قبول کر سکتے ہیں۔

مرحلہ عمل آگے بڑھنے سے پہلے شرط

تیاری ریکارڈز کی فہرست بنائیں اور نیا اینڈ پوائنٹ کنفیگر کریں ایپلیکیشن مطلوبہ ناموں کے لیے کام کرتی ہے

سرٹیفکیٹ سرٹیفکیٹ جاری اور انسٹال کریں درست چین اور ہوسٹ نام کی توثیق

منتقلی صرف منصوبہ بند DNS ریکارڈز اپ ڈیٹ کریں ڈیٹا کٹ اوور اور رول بیک متعین ہیں

مشاہدہ مستند اور کلائنٹ کے نتائج چیک کریں صارف کے سفر نئے اینڈ پوائنٹ سے کامیاب ہوتے ہیں

تکمیل توثیق کے بعد پرانی سروس ریٹائر کریں باقی ٹریفک اور ریکوری کی ضروریات کا جائزہ لیا گیا

05 DNS اور TLS کی الگ الگ تصدیق کریں

پہلے مستند ریکارڈ چیک کریں، پھر منتقلی میں شامل کلائنٹس یا ریزولورز کے جوابات کا موازنہ کریں۔ درست مستند قدر اور پرانی کیش شدہ قدر ساتھ ساتھ موجود ہو سکتی ہیں۔ یہ فرض کرنے کے بجائے کہ ہر کنکشن پہلے سے نیا پتہ استعمال کر رہا ہے، براؤزر کی پہنچنے والی اینڈ پوائنٹ کا معائنہ کریں۔ مشاہدات کو ٹائم اسٹیمپ کے ساتھ رکھیں تاکہ منتقلی قابل فہم ہو۔

TLS کے لیے، حقیقی کلائنٹ کنکشن کے ذریعے مطلوبہ ہوسٹ نام، سرٹیفکیٹ کی درستگی اور چین کی توثیق کریں۔ ہر مطلوبہ عرف اور ری ڈائریکٹ راستے کا معائنہ کریں۔ Mozilla کی TLS دستاویزات سرور کی توثیق اور مخلوط مواد کے خدشات کی وضاحت کرتی ہیں: صفحہ اور اس کے ذیلی وسائل محفوظ طریقے سے فراہم کیے جانے چاہئیں۔ ایک ہوسٹ نام پر سرٹیفکیٹ خود بخود دوسرے ایپلیکیشن اینڈ پوائنٹ کا احاطہ نہیں کرتا۔

06 رول بیک کو بھی ڈیٹا کا فیصلہ بنائیں

DNS رول بیک ٹریفک کو ری ڈائریکٹ کر سکتا ہے، لیکن یہ نئی ایپلیکیشن پر کی گئی تحریروں کو واپس نہیں کرتا۔ کٹ اوور سے پہلے وضاحت کریں کہ اس ڈیٹا کو کیسے سنبھالیں گے۔ جامد اشاعت کے لیے رول بیک سیدھا ہو سکتا ہے؛ اپ لوڈز یا آرڈرز قبول کرنے والی سروس کے لیے ایپلیکیشن کی حالت کے لیے واضح ذمہ دار اور مفاہمت کا طریقہ کار درکار ہے۔

تصور کریں کہ تبصروں والی ایک چھوٹی اشاعتی سائٹ منتقل کی جا رہی ہے۔ آپ حتمی ڈیٹا کاپی ہونے کے دوران دیکھ بھال کا وقفہ یا کنٹرول شدہ صرف پڑھنے کی منتقلی تیار کر سکتے ہیں۔ دوبارہ کھولنے کے طریقہ کار کی جانچ کریں اور پرانی تعیناتی تیار رکھیں۔ DNS تبدیلی کو مستقل مزاجی کی منصوبہ بندی کا متبادل بنانے کے بجائے ایپلیکیشن کے مطابق طریقہ منتخب کریں۔

07 سوئچ کے بعد سائٹ کا مشاہدہ کریں

نئے اینڈ پوائنٹ کو ٹریفک ملنے کے بعد حقیقی صارف کے سفر، غلطی کی شرح، سرٹیفکیٹ کی پیشکش اور پس منظر کے کاموں کی تصدیق کریں۔ تصدیق کریں کہ بیک اپس اب مطلوبہ ایپلیکیشن اور ڈیٹا کا احاطہ کرتے ہیں۔ ریٹائرمنٹ سے پہلے پرانے سرور تک رسائی کا جائزہ لیں اور ریکوری اور رول بیک کی ضروریات حل ہونے پر فرسودہ اسناد ہٹا دیں۔ حتمی DNS اور سرٹیفکیٹ کنفیگریشن ریکارڈ کریں۔

SwissOctet ویب ہوسٹنگ یا کمپیوٹ منتخب کرتے وقت، کنفیگریشن کے لیے اصل ڈومین، سرٹیفکیٹ اور انتظامی ذمہ داریوں کی تصدیق کریں۔ کیٹلاگ ہوسٹنگ کی منزل اور وسائل فراہم کرتا ہے؛ یہ ثابت نہیں کرتا کہ آپ کا ڈومین پہلے سے منسلک ہے یا سرٹیفکیٹ کی تجدید کنفیگر ہو چکی ہے۔ ان مراحل کو تعیناتی کے منصوبے میں ٹھوس اور قابل تصدیق رکھیں۔

اسے عمل میں بدلیں آپ کی عملی چیک لسٹ۔

✓ ہر ہوسٹ نام کی فہرست بنائیں اور غیر متعلقہ DNS ریکارڈز محفوظ رکھیں۔

✓ عوامی کٹ اوور سے پہلے ہوسٹ نام کی روٹنگ کی جانچ کریں۔

✓ موزوں سرٹیفکیٹ چیلنج منتخب کریں اور خودکار بنائیں۔

✓ TTL تبدیلیوں اور ڈیٹا کی منتقلی کا منصوبہ بنائیں۔

✓ الگ الگ جانچوں کے ذریعے DNS اور TLS کی تصدیق کریں۔

✓ واپسی سے پہلے رول بیک رسائی برقرار رکھیں اور نئی تحریریں حل کریں۔

چیک لسٹ ڈاؤن لوڈ کریں

عام سوالات وہ تفصیلات جو اہم ہیں۔

کیا A ریکارڈ تبدیل کرنے سے HTTPS فعال ہو جاتا ہے؟ +

نہیں۔ DNS ایک اینڈ پوائنٹ منتخب کرتا ہے؛ اس اینڈ پوائنٹ کو اب بھی درست ہوسٹ نام کی روٹنگ اور درست، نصب شدہ سرٹیفکیٹ درکار ہے۔

اگر کچھ ٹوٹ جائے تو کیا میں صرف DNS ریکارڈ واپس کر سکتا ہوں؟ +

ٹریفک ری ڈائریکٹ کی جا سکتی ہے، لیکن ایپلیکیشن کی تحریروں کے لیے الگ انتظام درکار ہے۔ مائیگریشن سے پہلے ڈیٹا رول بیک یا مفاہمت کا منصوبہ متعین کریں۔

کیا وائلڈ کارڈ سرٹیفکیٹ ہمیشہ ضروری ہوتا ہے؟ +

نہیں۔ اصل ہوسٹ ناموں کے مطابق سرٹیفکیٹ کے نام اور توثیق منتخب کریں۔ وائلڈ کارڈ کی مخصوص کوریج اور توثیقی ضروریات ہوتی ہیں؛ یہ عالمگیر مائیگریشن کا شارٹ کٹ نہیں ہے۔

بنیادی حوالہ جات ماخذ پر جائیں۔

یہ حوالہ جات اس گائیڈ میں تکنیکی تصورات کی حمایت کرتے ہیں۔ پروڈکشن سسٹم تبدیل کرنے سے پہلے موجودہ دستاویزات کی پیروی کریں۔

Let's Encrypt: چیلنج کی اقسام letsencrypt.org

IETF RFC 1034: DNS کے تصورات اور سہولیات datatracker.ietf.org

Mozilla MDN: ٹرانسپورٹ لیئر سیکیورٹی developer.mozilla.org

SwissOctet کی طرف سے ادارتی رہنمائی۔ مثالیں مثالی ہیں۔ سروس کی تفصیلات، دستیاب اختیارات اور معاہدے کی شرائط الگ سے تصدیق شدہ ہونی چاہئیں۔

علم کو جوڑیں متعلقہ انفراسٹرکچر۔

Canvas Web سوئٹزرلینڈ Vector VPS سوئٹزرلینڈ Pulse NVMe سوئٹزرلینڈ

دھاگہ رکھیں آپ کے اگلے فیلڈ نوٹس۔

ہر گائیڈ دریافت کریں

فیلڈ نوٹ / 01

+

کلاؤڈ اور VPS بنیاد

اندازے کے بغیر VPS کیسے منتخب کریں

ایپلیکیشن کے خیال کو مفید وسائل کے بجٹ میں بدلیں، پھر CPU، میموری، اسٹوریج اور ٹرانسفر کا ایک ساتھ موازنہ کریں۔

4 منٹ کا مطالعہ گائیڈ پڑھیں

فیلڈ نوٹ / 02

+

ویب اور onion بنیاد

ویب ہوسٹنگ یا ایک VPS: وہ کام منتخب کریں جس کی ملکیت آپ چاہتے ہیں

ایپلیکیشن کی ضروریات، کنٹرول اور دیکھ بھال کی ذمہ داریوں کا موازنہ کریں بجائے VPS کو ہر ویب سائٹ کے لیے خودکار اگلا قدم سمجھنے کے۔

6 منٹ پڑھیں گائیڈ پڑھیں

فیلڈ نوٹ / 03

+

ویب اور onion عملی

ایپلیکیشن کو نظر انداز کیے بغیر آنین سروس شائع کریں

کنٹرول شدہ بیک اینڈ نمائش، محتاط مواد کے جائزے، سروس کلید کی ریکوری اور واضح سامعین رسائی ماڈل کے ساتھ جائز آنین اشاعت کا منصوبہ بنائیں۔

4 منٹ کا مطالعہ گائیڈ پڑھیں