# নতুন সার্ভারের জন্য একটি ডোমেইন, DNS এবং TLS কাটওভার রানবুক | SwissOctet Insights

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

SwissOctet / অন্তর্দৃষ্টি / ওয়েব ও অনিয়ন ওয়েব ও অনিয়ন প্রয়োগকৃত · 4 মিনিট পড়া

নতুন সার্ভারের জন্য একটি ডোমেইন, DNS এবং TLS কাটওভার রানবুক

হোস্টনেম রাউটিং, সার্টিফিকেট এবং রোলব্যাক একসাথে প্রস্তুত করুন যাতে মাইগ্রেশন সাইটের পরিচয় বা নিরাপদ সংযোগ না ভেঙে সার্ভার পরিবর্তন করে।

SwissOctet এডিটোরিয়াল দ্বারা গাইড সংরক্ষণ করুন লিঙ্ক কপি করুন

এই পৃষ্ঠায় 01 নাম ও নির্ভরতার ইনভেন্টরি করুন 02 নতুন সার্ভারে হোস্টনেম রাউটিং প্রস্তুত করুন 03 একটি সার্টিফিকেট যাচাই পদ্ধতি বেছে নিন 04 DNS পরিবর্তনের আগে ক্যাশে উইন্ডো পরিকল্পনা করুন 05 DNS এবং TLS আলাদাভাবে যাচাই করুন 06 রোলব্যাককেও ডেটা সিদ্ধান্ত করুন 07 সুইচের পরে সাইট পর্যবেক্ষণ করুন আপনার ব্যবহারিক চেকলিস্ট সূত্র ও আরও পড়া লাইব্রেরিতে ফিরে যান সরাসরি উত্তর উদ্দিষ্ট হোস্টনেমের জন্য সার্ভার ও সার্টিফিকেট প্রস্তুত করুন, পাবলিক DNS পরিবর্তনের আগে অ্যাপ্লিকেশন পরীক্ষা করুন, এবং পরিবর্তনের সময় পুরনো পরিবেশ উপলব্ধ রাখুন। প্রামাণিক রেকর্ড, ক্যাশে করা উত্তর এবং TLS স্বাধীনভাবে যাচাই করুন। শুধু একটি DNS আপডেট প্রমাণ করে না যে সঠিক অ্যাপ্লিকেশন ও সার্টিফিকেট পরিবেশন করা হচ্ছে।

01 নাম ও নির্ভরতার ইনভেন্টরি করুন

সাইট যে প্রতিটি হোস্টনেম ব্যবহার করে তালিকাভুক্ত করুন, প্রধান ডোমেইন, উপনাম, API এন্ডপয়েন্ট এবং অ্যাপ্লিকেশন কলব্যাক সহ। কে নিবন্ধন এবং প্রামাণিক DNS নিয়ন্ত্রণ করে তা রেকর্ড করুন। একটি অ্যাপ্লিকেশন হোস্ট করলে স্বয়ংক্রিয়ভাবে তার ডোমেইন নিবন্ধিত হয় না বা সার্ভার অপারেটরকে তার রেকর্ডের নিয়ন্ত্রণ দেয় না। নতুনটি যাচাই না হওয়া পর্যন্ত বিদ্যমান পরিবেশে অ্যাক্সেস রাখুন।

স্থানান্তরে সংরক্ষণ করা উচিত ইমেইল ও তৃতীয়-পক্ষ যাচাই রেকর্ডও চিহ্নিত করুন। একটি ওয়েবসাইট মাইগ্রেশন সম্পূর্ণ DNS জোন casually প্রতিস্থাপন করা উচিত নয়। উদ্দিষ্ট ঠিকানা ও রোলব্যাক মান সহ রেকর্ড-স্তরের পরিবর্তন পরিকল্পনা তৈরি করুন। ক্রেডেনশিয়াল গোপনে সংরক্ষণ করুন; রানবুকে প্রকৃত পাসওয়ার্ড বা 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

+

ওয়েব ও অনিয়ন ফাউন্ডেশন

ওয়েব হোস্টিং বা একটি VPS: আপনি যে কাজের মালিক হতে চান তা বেছে নিন

প্রতিটি ওয়েবসাইটের জন্য একটি VPS-কে স্বয়ংক্রিয় পরবর্তী ধাপ হিসেবে বিবেচনা না করে অ্যাপ্লিকেশন প্রয়োজনীয়তা, নিয়ন্ত্রণ এবং রক্ষণাবেক্ষণের দায়িত্ব তুলনা করুন।

6 মিনিট পড়া গাইড পড়ুন

ফিল্ড নোট / 03

+

ওয়েব ও অনিয়ন প্রয়োগকৃত

অ্যাপ্লিকেশন উপেক্ষা না করে একটি onion সেবা প্রকাশ করুন

নিয়ন্ত্রিত ব্যাকএন্ড এক্সপোজার, সতর্ক কনটেন্ট পর্যালোচনা, সেবা-কী রিকভারি এবং স্পষ্ট দর্শক-অ্যাক্সেস মডেল সহ একটি বৈধ onion প্রকাশনা পরিকল্পনা করুন।

4 মিনিট পড়া গাইড পড়ুন