ওয়েব অ্যাপের কাস্টম ডোমেইন সেটআপ: স্পষ্ট DNS রেকর্ড ধাপ, SSL ইস্যু, রিডাইরেক্ট এবং ডাউনটাইম-শূন্য কাটওভার প্ল্যান যাতে ডাউনটাইম ও কুকি সমস্যা এড়ানো যায়।
কাস্টম ডোমেইন শুধু সুন্দর একটি URL নয়। আপনি যখন প্ল্যাটফর্ম সাবডোমেইন (উদাহরণ: Koder.ai-এ থাকা একটি অ্যাপ) থেকে আপনার নিজস্ব ডোমেইনে চলে যান, তখন ব্রাউজার ও নেটওয়ার্কগুলো এটিকে ভিন্ন সাইট হিসেবে বিবেচনা করে। এতে রাউটিং, সিকিউরিটি, এবং ব্যবহারকারীর সেশনগুলোতে প্রভাব পড়ে।
কাস্টম ডোমেইনে স্যুইচ করার পরে কিছু জিনিস অবিলম্বে বদলে যায়:
www-এ নামবে নাকি apex-এ, এবং HTTP থেকে HTTPS-এ কনসিস্টেন্ট নিয়ম থাকা দরকার।old-platform.example-এর লগইন কুকি app.yourdomain.com-এ স্বয়ংক্রিয়ভাবে কাজ করবে না।স্বল্প সময়ের আউটেজগুলো সাধারণত টাইমিং থেকে আসে। DNS নতুন হোস্টে ট্রাফিক পাঠানো শুরু করতে পারে তখনই যখন SSL সার্টিফিকেট প্রস্তুত নয়, ফলে ব্রাউজার সতর্কতা দেখা যায়। অথবা উল্টোটি—SSL প্রস্তুত আছে কিন্তু অনেক ব্যবহারকারী এখনও পুরোনো স্থানে থাকে কারণ তাদের DNS ক্য়াশ সময় শেষ হয়নি।
রিডাইরেক্টও কখনও সূক্ষ্মভাবে লগইন ভেঙে দিতে পারে। হোস্টনেম বদলানো রিডাইরেক্ট (apex থেকে www বা উল্টো) কুকি হারিয়ে ফেলতে পারে যদি কুকি অন্য হোস্টের জন্য সেট করা থাকে। অথেনটিকেশন প্রদানকারীরা ব্যর্থ হতে পারে যদি তাদের callback URL এখনও পুরনো ডোমেইন দেখায়।
কম-ঝুঁকির কাটওভার মানে আপনি ওভারল্যাপের জন্য পরিকল্পনা করবেন: পুরোনো URL কাজ করা চালিয়ে রাখুন, নতুন ডোমেইন প্যারালেলে তোলা, পূর্বনির্ধারিত মুহূর্তে ট্রাফিক স্যুইচ, এবং রোলব্যাককে সহজ রাখুন যেন DNS ফেরত দেওয়াই সমাধান হয়।
কিছুই পরিবর্তন করার আগে ঠিক লিখে রাখুন কোন নামগুলো আপনি চান ব্যবহারকারী টাইপ করুক, এবং কোন নামগুলো নীরবে রিডাইরেক্ট করবে। “অর্ধেক কাজ করছে কেন?”—এর বেশিরভাগ সৃষ্টি হয় যখন দল কোনো একটিকেই সারা হোস্টনেম হিসেবে চিহ্নিত করে না।
শুরু করুন বড় সিদ্ধান্ত থেকে: প্রাইমারি কি হবে—apex (example.com) না www (www.example.com)? উভয়ই কাজ করবে, কিন্তু একটি বেছে নিন এবং অন্যটাকে রিডাইরেক্ট হিসেবে দেখুন। এটি পরে কুকির জন্যও গুরুত্বপূর্ণ: সেশনগুলো সাধারণত সবচেয়ে সহজ থাকে যখন অ্যাপ একটি কনসিস্টেন্ট হোস্টে থাকে।
পরবর্তী, সিদ্ধান্ত নিন কোন সাবডোমেইনগুলো এখন লাগবে এবং কোনগুলো পরে করা যাবে। সাধারণ প্যাটার্ন হলো app.example.com ওয়েব অ্যাপের জন্য এবং api.example.com API গুলোর জন্য, সাথে পরে admin.example.com বা assets.example.com যোগ করা যেতে পারে। Koder.ai-এর মতো প্ল্যাটফর্মে কাস্টম ডোমেইন সেট করলে এই পছন্দগুলো সরাসরি SSL ভেরিফিকেশন ও DNS পয়েন্টিংয়ের সাথে মিলে যায়।
অনেকেই ডোমেইন একটি রেজিস্ট্রার থেকে কিনে নেয়, কিন্তু DNS কোথাও অন্যত্র হোস্ট হতে পারে। নিশ্চিত করুন কোথায় রেকর্ডগুলো আজ পরিবর্তন করা হয়, কার অ্যাক্সেস আছে, এবং কোনো অটোমেশন পরিবর্তন করছে কি না (কোম্পানির IT, একটি এজেন্সি, বা managed DNS প্রদানকারী)। আপনি যদি লগইন করে বর্তমান রেকর্ড দেখতে না পান, তাহলে আগে সেটি ঠিক করুন।
এছাড়া ডোমেইনটি আগে কী ব্যবহার করে তা অডিট করুন। ইমেইল হলো ক্লাসিক ফাঁদ: রেকর্ড ডিলিট বা ওভাররাইট করলে মেইল ডেলিভারি নষ্ট হতে পারে।
আগে এগুলো নোট করুন:
www) এবং রিডাইরেক্ট দিকযদি মার্কেটিং ইতিমধ্যেই example.com-এ ইমেইল চালায়, তাহলে মেইল-রিলেটেড রেকর্ড অছোঁকা রাখুন এবং কেবল অ্যাপের জন্য প্রয়োজনীয় রেকর্ড যোগ করুন।
কাস্টম ডোমেইন মুভে ঝুঁকির বেশিরভাগই অ্যাপ নয়—একটি ভুল DNS পরিবর্তনই ট্রাফিককে যেখানে না থাকা জায়গায় পাঠাতে পারে, ইমেইল ভেঙে দিতে পারে, বা SSL ভ্যালিডেশন ব্যর্থ করাতে পারে।
A record একটি নামকে একটি IP ঠিকানায় নির্দেশ করে। সরল ভাষায়: “লোককে এই সার্ভারে পাঠাও।” যখন আপনার প্রদানকারী একটি স্থায়ী IP দেয় তখন এটা অ্যাপেক্সের জন্য সাধারণ।
CNAME record একটি নামকে অন্য নামের কাছে নির্দেশ করে। সরল ভাষায়: “এই নামটিকে ওই হোস্টনেমের এলিয়াস হিসেবে মনে করো।” সাধারণত www.example.com কে প্ল্যাটফর্ম হোস্টনেমের দিকে নির্দেশ করতে ব্যবহার করা হয়।
অনেকে DNS প্রদানকারীর কাছ থেকে ALIAS/ANAME অফার পায় অ্যাপেক্সে; এটি CNAME-এর মতো আচরণ করে কিন্তু example.com-এর জন্য কাজ করে। আপনার প্রদানকারী সমর্থন করলে এটি পরিচালনা সহজ করতে পারে কারণ টার্গেট বদলে গেলেও IP তে হাত দিতে হয় না।
সহজ মানসিক মডেল:
প্রায়ই আপনি TXT রেকর্ড যোগ করবেন ডোমেইন মালিকানা যাচাই (প্ল্যাটফর্ম ভেরিফিকেশন) এবং SSL সার্টিফিকেট ভ্যালিডেশন (কিছু CA TXT টোকেন চায়)। TXT ইমেইল পলিসি, যেমন SPF, এর জন্যও ব্যবহৃত হয়। ভুল করে বিদ্যমান SPF TXT ডিলিট বা বদলে ফেললে মেইল ডেলিভারি নষ্ট হতে পারে।
TTL নিয়ন্ত্রণ করে অন্যান্য সিস্টেম আপনার DNS উত্তর কতক্ষণ ক্য়াশ করে রাখে। কাটওভার-এর এক দিন আগে আপনি যে রেকর্ডগুলো পরিবর্তন করবেন সেগুলোর TTL কমান (সাধারণত 300 থেকে 600 সেকেন্ড)। সব স্টেবিল হলে TTL আবার বাড়ান যাতে কিউরি লোড কমে।
সম্পাদনের আগে জোন এক্সপোর্ট বা স্ক্রিনশট নিন। আপনি কোন রেকর্ড বদলাবেন, তার পুরানো মান, নতুন মান, এবং TTL লিখে রাখুন। সমস্যা হলে রোলব্যাক মানগুলো পুনরায় বসানো।
বিশেষ করে যখন আপনার ডোমেইনে ইতিমধ্যেই MX, DKIM, বা অন্য TXT রেকর্ড থাকে—তার সময় এইটা বেশি গুরুত্বপূর্ণ।
SSL (লক আইকন) ব্রাউজার ও আপনার অ্যাপের মধ্যে ট্র্যাফিক এনক্রিপ্ট করে। আধুনিক ব্রাউজার ও অনেক API ডিফল্টভাবে HTTPS আশা করে। ছাড়া থাকলে সতর্কতা, ব্লক করা অনুরোধ, এবং সার্ভিসওয়ার্কার, জিওলোকেশন, কিছু পেমেন্ট ফ্লো কাজ বন্ধ হয়ে যেতে পারে।
সার্টিফিকেট ইস্যু করতে CA-কে ডোমেইনের মালিকানা যাচাই করতে হবে। সাধারণ ভ্যালিডেশন পদ্ধতি হলো HTTP ভ্যালিডেশন এবং DNS TXT ভ্যালিডেশন:
আপনি যখন CDN ব্যবহার করছেন বা আপনার অ্যাপ নতুন ডোমেইনে পৌঁছনো যায় না তখন DNS validation প্রায়ই সহজ হয়।
কার কাছে সার্টিফিকেট ইস্যু হয় তা আপনার সেটআপের উপর নির্ভর করে। কেউ কেউ সরাসরি হোস্টিং স্ট্যাকে সার্টিফিকেট ইস্যু করে, কেউ CDN-এ, এবং কিছু প্ল্যাটফর্ম (উদাহরণ: Koder.ai) কাস্টম ডোমেইন সাপোর্টের সময় সার্টিফিকেট পরিচালনা করে। গুরুত্বপূর্ণ হলো কাউকে দায়িত্ব দিতে হবে সার্টিফিকেট লাইফসাইকেল-এর, রিনিউসহ।
সার্টিফিকেট ইস্যু সবসময় তাত্ক্ষণিক নয়। DNS প্রোপাগেশন, ভ্যালিডেশন চেক, এবং রেট লিমিট ধীর করে দিতে পারে। রিট্রাই-এর জন্য প্ল্যান করুন এবং কাটওভার শেষ মুহূর্তে সমন্বয় করবেন না।
প্রায়োগিক সময়সূচি:
সার্টিফিকেটটি ব্যবহারকারীরা যে প্রতিটি হোস্টনেমে যাবে সেগুলো কভার করতে হবে। SAN (Subject Alternative Names) তালিকা চেক করুন। যদি আপনার অ্যাপ example.com এবং www.example.com উভয় স্থানে পাওয়া যাবে, তখন সার্টিফিকেটে উভয় থাকা প্রয়োজন।
ওয়াইল্ডকার্ড (*.example.com) অনেক সাবডোমেইনকে ঢেকে দিতে পারে, কিন্তু এগুলো অ্যাপেক্স ডোমেইন (example.com) ঢেকে না।
কনক্রিট উদাহরণ: যদি আপনি শুধু www.example.com-এর জন্য সার্টিফিকেট ইস্যু করেন, তাহলে যেসব ব্যবহারকারী শুধু example.com টাইপ করে তাদের সাইটে সতর্কতা দেখা দেবে, যদি না আপনি এমন এক লেয়ারে রিডাইরেক্ট করেন যার কাছে example.com-এর বৈধ সার্টিফিকেট আছে।
রিডাইরেক্টগুলো সহজ মনে হলেও ডোমেইন সমস্যাগুলোর বেশিরভাগ এখানেই দেখা দেয়: লুপ, মিশ্র কনটেন্ট, এবং ব্যবহারকারীরা হোস্ট বদলানোতে লগআউট হয়ে যাওয়া।
একটি ক্যানোনিক্যাল হোস্ট বেছে নিন এবং সেটার প্রতি অনুবর্তী হন: www.example.com না example.com—অন্যটা ক্যানোনিক্যাল হোস্টের দিকে রিডাইরেক্ট করা উচিত যাতে কুকি, সেশন, এবং SEO সিগন্যাল সঙ্গতিপূর্ণ থাকে।
নিরাপদ ডিফল্ট:
http:// থেকে https://-এ 301 রিডাইরেক্টHTTP থেকে HTTPS-এ, এমন নিয়ম এড়ান যা ব্যবহারকারীদের বারবার ফিরিয়ে দেয়। লুপ প্রতিরোধের সহজ উপায় হলো অনুরোধটি আসলেই কেমন ছিল তার ওপর ভিত্তি করে সিদ্ধান্ত নেওয়া। আপনার অ্যাপ যদি প্রক্সি বা CDN-র পেছনে থাকে, তাহলে ফরওয়ার্ডেড হেডারগুলো সম্মান করতে কনফিগার করুন; না হলে অ্যাপ ভাববে প্রতিটি অনুরোধ HTTP এবং অবিরত রিডাইরেক্ট করবে।
মুভ করার সময় পুরোনো পাথগুলো জীবিত রাখুন। আপনি যদি রুট বদলান (যেমন /login থেকে /sign-in), সেগুলোর জন্য স্পষ্ট রিডাইরেক্ট যোগ করুন। একটি সাধারণ রিডাইরেক্ট হোমপেজে পাঠালে বুকমার্ক এবং শেয়ার্ড লিংক ভেঙে যাবে।
প্রথমেই HSTS চালু করবেন না। যদি আপনি খুব আগে এটি চালু করেন এবং পরে HTTP দিয়ে ভ্যালিডেশন বা ট্রাবলশুট করতে হয়, ব্রাউজার HTTP নেবেন না। HTTPS স্থির হয়ে গেলে এবং সাবডোমেইন কভারেজ নিশ্চিত হলে HSTS বিবেচনা করুন।
রিডাইরেক্ট পরীক্ষা করতে একটি অস্থায়ী টেস্ট হোস্টনেম ব্যবহার করুন, কিছু বাস্তব ডিপ লিংক পরীক্ষা করুন (অথেনট পেজসহ), এবং কমান্ড-লাইন অনুরোধ চালিয়ে প্রতিটি রিডাইরেক্ট ধাপ ও চূড়ান্ত গন্তব্য দেখুন।
নিরাপদ কাটওভার অনেকটাই টাইমিং। নতুন ডোমেইনটি প্রস্তুত ও পরীক্ষা করা থাকবে আগে থেকেই এবং বাস্তব ব্যবহারকারীরা সেখানে পাঠানোর আগে DNS পরিবর্তনগুলো দ্রুত ছড়িয়ে পড়বে যাতে আপনি ইস্যু সময় আটকা না পড়েন।
আপনি পরিবর্তন করার আগে আপনার DNS TTL কমান (যে রেকর্ডগুলো পরিবর্তন করবেন)। সম্ভব হলে এক দিন আগে এটি করুন এবং পুরোনো TTL উইন্ডো শেষ হওয়া পর্যন্ত অপেক্ষা করুন।
এরপর your hosting/provider-এ কাস্টম ডোমেইন যোগ করুন এবং যে ভেরিফিকেশন তারা চায় তা শেষ করুন। Koder.ai-র মতো প্ল্যাটফর্ম ব্যবহার করলে সেখানে আগে ডোমেইন যোগ করুন যেন প্ল্যাটফর্ম মালিকানা নিশ্চিত করে এবং রাউটিং প্রস্তুত করে।
SSL আগে ইস্যু করুন। ভ্যালিডেশন ও রেট লিমিটের কারণে সার্টিফিকেটে সময় লাগতে পারে, এবং আপনি চান না যে কাটওভারের সময় এটি বিলম্ব করুক।
ডোমেইন পাবলিক করার আগে প্রাইভেট টেস্ট করুন: নিজের মেশিনে সাময়িক হোস্ট এন্ট্রি ব্যবহার করে নতুন endpoint-এ যান এবং সঠিক সার্টিফিকেটে HTTPS দিয়ে সাইট লোড হচ্ছে কি না যাচাই করুন।
স্টেজড অ্যাপ্রোচ ব্যবহার করুন যাতে যদি কিছু ভুল দেখেন দ্রুত থামিয়ে দেওয়া যায়:
www)।যদি আপনি DNS স্তরে আসল ক্যানারি করতে না পারেন, তবুও একটি হোস্টনেম প্রথমে স্যুইচ করে স্টেজিং করতে পারেন (যেমন www) এবং অ্যাপেক্স পরে ছেড়ে দিন যতক্ষণ না আস্থা হয়।
আপনি কি ফিরিয়ে দেবেন ঠিক লিখে রাখুন (কোন রেকর্ড, কী মান), এবং কে করবে তা ঠিক করুন। রোলব্যাক সাধারণত পূর্বাবস্থায় DNS ফিরিয়ে দেয়ার মতো।
পুরোনো কনফিগারেশনটি (SSL সহ) এখনও বৈধ আছে কিনা নিশ্চিত রাখুন যাতে ব্যবহারকারীরা সিম্পলি ফেরত পেতে পারে।
ডোমেইন পরিবর্তন কেবল DNS পরিবর্তন নয়। অনেক অ্যাপের জন্য “লগ ইন থাকা” নির্ভর করে কুকির উপর যেগুলো ব্রাউজার নির্দিষ্ট হোস্টনেমের সাথে জোরপূর্বক মেলে। যদি আপনি একটি হোস্টনেম থেকে আরেকটাতে স্যুইচ করেন, ব্রাউজার পুরানো কুকি পাঠানো বন্ধ করে দিতে পারে এবং অ্যাপ সবাইকে লগআউট দেখাবে।
কুকি সেটিংস প্রায়শই কারণ:
.example.com হিসেবে কুকি সেট করলে app.example.com ও www.example.com উভয়েই পাঠানো যাবে।/api), ওয়েব UI দেখতে পাবে না।Lax সাধারণত ঠিক থাকে, কিন্তু কিছু SSO বা পেমেন্ট রিডাইরেক্টের জন্য None + Secure লাগতে পারে।ঝুঁকি কমাতে, একটি সংক্ষিপ্ত ট্রানজিশন পরিকল্পনা করুন যেখানে উভয় ডোমেইন কাজ করে। পুরোনো হোস্টনেমটি উত্তর দিচ্ছে এবং সাবধানে রিডাইরেক্ট করা হচ্ছে, কিন্তু সেশনগুলো নতুন ডোমেইনে রিফ্রেশ করার সুযোগ দিন। সম্ভব হলে শেয়ার্ড সেশন স্টোর ব্যবহার করুন যাতে যিনি যেখানেই মার্ডিবস, সনাক্ত করা যায়।
SSO বা OAuth ব্যবহার করলে কাটওভারের আগে সেটিংগুলো আপডেট করুন: callback URLs, allowed origins, এবং যে কোনো allowlist। না হলে লগইন প্রোভাইডারে সফল হলেও অ্যাপে ফেরত আসা ব্যর্থ হবে।
প্রথমে ভাঙে এমন ফ্লোগুলো টেস্ট করুন: সাইন আপ (ইমেইল ভেরিফিকেশন সহ), লগইন/লগআউট, পাসওয়ার্ড রিসেট, চেকআউট বা পেমেন্ট রিটার্ন, এবং মাল্টি-ট্যাব সেশন।
উদাহরণ: যদি আপনি www.example.com থেকে example.com-এ রিডাইরেক্ট করেন, নিশ্চিত করুন কুকি .example.com হিসেবে সেট করা আছে (অথবা সবসময় একটি হোস্ট ব্যবহার করুন)। না হলে ব্যবহারকারীরা হোস্টের মধ্যে ঘুরে সেশন হারাবে।
বেশিরভাগ ডোমেইন সমস্যা “রহস্যজনক ইন্টারনেট সমস্যা” নয়—এগুলো DNS, সার্টিফিকেট, এবং রিডাইরেক্ট নিয়মের ছোট মিলের ফলে ঘটে, যা কেবল বাস্তব ব্যবহারকারীরা এড়িয়ে দেয়।
সহজ একটি ফাঁদ হল অ্যাপেক্স (example.com)। অনেক DNS প্রদানকারী প্রকৃত CNAME অ্যাপেক্সে অনুমোদন করে না। যদি অ্যাপেক্সে CNAME বলেই পয়েন্ট করার চেষ্টা করেন, তা নিঃশব্দে ব্যর্থ হতে পারে, অনিয়মিতভাবে রেজলভ করতে পারে, বা কিছু নেটওয়ার্কে ভেঙে পড়ে। আপনার DNS হোস্ট যা সমর্থন করে তা ব্যবহার করুন (সাধারণত A/AAAA রেকর্ড, বা ALIAS/ANAME ধরনের রেকর্ড)।
আরেকটি সাধারণ কারণ হলো SSL প্রস্তুত না থাকার আগেই DNS ফ্লিপ করা। ব্যবহারকারীরা আসে, অ্যাপ লোড হয়, কিন্তু ব্রাউজার ব্লক করে কারণ সার্টিফিকেট নেই বা কেবল আংশিক হোস্ট কাভার করে। বাস্তবে, সাধারণত আপনি চান সার্টিফিকেট উভয় example.com এবং www.example.com-কে ঢেকে রাখুক, এমনকি আপনি একটিকে অন্যটির দিকে রিডাইরেক্ট করার পরিকল্পনা থাকলেও।
অন্যান্য সাধারণ ভুল:
www→apex, তারপর apex→www), অথবা এক জায়গায় HTTP চাপা দিয়ে অন্য জায়গায় HTTPS জোর করাhttp:// অ্যাসেটগুলো চালু রেখে মিক্সড কনটেন্ট পাঠানোএকটি দ্রুত স্যানিটি চেক: উভয় হোস্টনেম (www ও অ্যাপেক্স) HTTPS-এ খুলুন, লগইন করুন, রিফ্রেশ করুন, এবং নিশ্চিত করুন ঠিকানার বার কখনও HTTP-এ ফিরে যায় না।
আপনি যদি Koder.ai-এর মতো প্ল্যাটফর্মে কাজ করে থাকেন, নিশ্চিত করুন কাস্টম ডোমেইন কানেক্টেড এবং SSL ইস্যু হয়েছে প্রোডাকশনে স্পর্শ করার আগে, এবং রোলব্যাক অপশন প্রস্তুত রাখুন যাতে একটা খারাপ রিডাইরেক্ট বা রেকর্ড পরিবর্তন লম্বা সময় ধরে না থাকে।
শান্ত কাটওভার বেশিরভাগই প্রস্তুতির কাজ। লক্ষ্য সহজ: ব্যবহারকারীরা লগইন করে থাকতে পারে, কুকি কাজ করে, এবং সমস্যা হলে দ্রুত রোলব্যাক করতে পারেন।
এসব করুন যখন ট্রাফিক এখনও পুরোনো ডোমেইনে যাচ্ছে। সম্ভব হলে এক দিন নিন যাতে DNS পরিবর্তনের সময় ক্য়াশ settle হয়।
www, api ইত্যাদি) এবং SSL ভ্যালিডেশন পদ্ধতি নির্ধারণ করুন (DNS না HTTP)।www→apex (অথবা উল্টো), এবং একটি ক্যানোনিক্যাল হোস্ট।DNS ফ্লিপ করার পরে প্রথম এক ঘন্টাকে একটি incident drill হিসেবে দেখুন। শুধুমাত্র status ড্যাশবোর্ড নয়, বাস্তব ব্যবহারকারীর ফ্লো নজর করুন।
Koder.ai (অথবা অন্য কোনো প্ল্যাটফর্ম) কাস্টম ডোমেইন ও SSL হ্যান্ডেল করলেও, এই চেকলিস্টটি প্রযোজ্য—বেশিরভাগ সমস্যা আসে DNS ও রিডাইরেক্ট থেকে, না যে অ্যাপ কোড থেকে।
আপনার অ্যাপ আছে একটি অস্থায়ী প্ল্যাটফর্ম ঠিকানায় যেমন myapp.koder.ai। কাজ করে, কিন্তু আপনি চান গ্রাহকরা example.com ব্যবহার করুন, www.example.com অ্যাপেক্সে রিডাইরেক্ট করবে, এবং সবকিছু HTTPS-এ কড়া করা হবে।
একটি সহজ DNS পরিকল্পনা ঝুঁকি ন্যূনতম রাখে। কিছুই পরিবর্তন করার আগে বর্তমান কাজ করা অবস্থা নোট করুন (প্ল্যাটফর্ম যদি স্ন্যাপশট সমর্থন করে যেমন Koder.ai করে তাহলে একটি নিন) এবং কাটওভারের এক দিন আগে DNS TTL কমান।
বিদ্যমান প্ল্যাটফর্ম URL অটুট রেখে নতুন রেকর্ডগুলো যোগ করুন:
example.com: আপনার প্ল্যাটফর্ম প্রদত্ত হোস্টিং টার্গেটকে নির্দেশ করে A/ALIAS রেকর্ডwww.example.com: CNAME যা example.com-এর দিকে অথবা প্ল্যাটফর্ম টার্গেটের দিকে নির্দেশ করবে (প্রোভাইডারের উপর নির্ভর করে)myapp.koder.ai অপরিবর্তিত রাখুন যাতে একটি জানা-ভালো fallback থাকেDNS স্থাপন হলে, উভয় হোস্টনেমের জন্য SSL অনুরোধ করুন (example.com এবং www.example.com)। সার্টিফিকেট ইস্যু ও সক্রিয় না হওয়া পর্যন্ত ট্রাফিক স্যুইচ করবেন না—অন্যথায় ব্রাউজার সতর্কতা দেখা দেবে।
কাটওভার টাইমলাইন স্পষ্ট চেকপয়েন্টসহ:
example.com পরীক্ষা করুন (হোমপেজ, স্ট্যাটিক অ্যাসেট, API কল)www→apex)মুভের পরে কুকি আচরণ যাচাই করুন। লগইন করুন, রিফ্রেশ করুন, এবং দুটো হোস্টেই লগইন ধরে আছে কিনা পরীক্ষা করুন। সেশন ভাঙলে সাধারণত কুকি ডোমেইন বা SameSite সেটিং ধরে থাকে যা পুরনো হোস্ট ধরে ধরেই বানানো হয়েছিল।
কাটওভারে কাজ হয়ে গেলেও কাজ শেষ হয় না। বেশিরভাগ ডোমেইন মুভ পরে ব্যর্থ হয় কারণ কেউ দেখেনি ধীরভাবে ড্রিফট: একটি সার্টিফিকেট মেয়াদ শেষ হয়ে আসছে, হঠাৎ করা DNS পরিবর্তন, বা রিডাইরেক্ট টুইক যা লগইন ভেঙে দেয়।
একটি ছোট মনিটরিং রুটিন স্থাপন করুন যা আপনি রক্ষণাবেক্ষণ করবেন। এন্টারপ্রাইজ টুল দরকার নেই তবে কিছু নির্ভরযোগ্য সিগন্যাল থাকুক: গুরুত্বপূর্ণ পেজগুলোর (হোম, লগিন, একটি অথেন্টিকেটেড পেজ) availability checks, সার্টিফিকেট মেয়াদ শেষের এ্যালার্ট (উদাহরণ: 30 ও 7 দিন আগে), এরর-রেট ট্র্যাকিং (শুধু uptime নয়, 4xx/5xx স্পাইক দেখুন), এবং মাঝে মাঝে রিডাইরেক্ট ভ্যালিডেশন (HTTP→HTTPS ও পছন্দের হোস্টনেম জিতে আছে কি না) চালান।
একটু শোনা অবস্থা থাকলে দ্রুত রোলব্যাক উইন্ডো রাখা—২৪ থেকে ৭২ ঘণ্টার জন্য পূর্বাবস্থা দ্রুত ফেরত আনার উপায় রাখুন (পুরোনো DNS টার্গেট, পুরোনো হোস্টিং কনফিগ, পুরোনো TLS সেটিং)।
একবার আস্থা হলে DNS TTL আবার বাড়ান। লো TTL পরিবর্তনের সময় উপকারী হলেও এটি রিজল্ভার লোড বাড়ায় এবং ছোট ভুলগুলোতে বড় প্রভাব ফেলে। একটি সাধারণ TTL বেছে নিন যা আপনার পরিবর্তনের আগ্রহের সঙ্গে মেলে (অনেক দল 1 থেকে 4 ঘন্টা রাখে)।
শেষে, চূড়ান্ত অবস্থা ডকুমেন্ট করুন—কোন রেকর্ড আছে (টাইপ, নাম, মান, TTL), কোন হোস্টনেম সাপোর্টেড, এবং ঠিক কোন রিডাইরেক্ট নিয়ম আছে। অন্তর্ভুক্ত করুন কোথায় সার্টিফিকেট ইস্যু হয়, কী কভার করে (apex, www, সাবডোমেইন), এবং কে রিনিউ-এর মালিক।
আপনি যদি একজন প্ল্যাটফর্মে বিল্ড ও ডিপ্লয় করেন, ডোমেইনগুলোকে প্রথম-শ্রেণীর ফিচার হিসেবে ট্রিট করলে সুবিধা হয় এবং কনফিগারেশন পরিবর্তন দ্রুত পূর্বাবস্থায় ফিরিয়ে আনা সহজ হয়। Koder.ai-এ কাস্টম ডোমেইনগুলো স্ন্যাপশট ও রোলব্যাকের পাশে থাকলে ভবিষ্যৎ ডোমেইন ও রিডাইরেক্ট পরিবর্তনগুলো কম চাপযুক্ত হয়।
ডিফল্ট হিসেবে একটি ক্যানোনিক্যাল হোস্টনেম বেছে নিন এবং সবকিছু অন্যটির দিকে রিডাইরেক্ট করুন।
example.com (apex) অথবা www.example.com-এর মধ্যে একটি “রিয়াল” হোস্ট চয়ন করুন।এতে কুকি, সেশন, এবং বুকমার্কগুলো সঙ্গতিপূর্ণ থাকে এবং অর্ধেক-চলমান আচরণ রোধ হয়।
কাটওভারের আগে এক দিন আগে TTL কমান এবং পরে পুরোনো TTL লাইফস্প্যানটি শেষ হওয়া পর্যন্ত অপেক্ষা করুন।
শুধুমাত্র সেই রেকর্ডগুলোর TTL কমান যেগুলো আপনি পরিবর্তন করতে যাচ্ছেন।
অনেক অ্যাপ সেটআপের জন্য:
www.example.com বা app.example.com, যখন আপনি একটি প্রদানকারীর হোস্টনেমের দিকে নির্দেশ করছেন তখন CNAME ব্যবহার করুন।example.com-এর জন্য (অথবা আপনার DNS সমর্থন করলে ) ব্যবহার করুন।নতুন হোস্টনেমগুলোর জন্য HTTPS বৈধ না হওয়া পর্যন্ত ব্যবহারকারীদের সেখানে পাঠাবেন না।
প্রায়োগিক অনুক্রমঃ
এতে কাটওভারে ব্রাউজার সতর্কতা ও ব্লক হওয়া এড়ানো যায়।
অনেক সময় ইমেইল ব্রেক হয়ে যায় যখন কেউ MX বা গুরুত্বপূর্ণ TXT রেকর্ড ডিলিট বা ওভাররাইট করে।
কোনো কিছু বদলানোর আগে:
রিডাইরেক্ট লুপ সাধারণত CDN/প্রক্সি এবং আপনার অ্যাপের মধ্যে বিরোধী নিয়ম থেকে হয়।
নিম্নলিখিত সেফ ডিফল্ট অনুসরণ করুন:
http:// → https://: একক রিডাইরেক্টআপনি যদি প্রক্সির পেছনে থাকেন, নিশ্চিত করুন অ্যাপ ফরওয়ার্ডেড স্কিম হেডারগুলোকে সম্মান করে; না হলে অ্যাপ ভাববে প্রতিটি অনুরোধ HTTP এবং ধারাবাহিকভাবে রিডাইরেক্ট করবে।
হ্যাঁ, যদি কুকিগুলো পুরনো হোস্টনেমে সীমাবদ্ধ হয়ে থাকে তবে সাধারণত ব্যবহারকারীরা লগআউট হিসেবে দেখেন।
যা চেক করবেন:
কাটওভারের আগে identity সেটিংগুলো আপডেট করে রাখুন।
সাধারণত যেগুলো মিলতে হবে নতুন ডোমেইনের সাথে ঠিকঠাক:
যদি এগুলো পুরনো ডোমেইনে থাকে, তাহলে identity provider-এ সাইন-ইন সফল হলেও অ্যাপে ফিরে আসা ব্যর্থ হতে পারে।
রোলব্যাক প্রায়শই পুরনো DNS মানগুলো পুনরায় বসানোই।
সহজ রাখুন:
যদি আপনার প্ল্যাটফর্ম স্ন্যাপশট/রোলব্যাক সমর্থন করে (Koder.ai করে), তাহলে কাটওভার আগে এক নিন যাতে কনফিগারেশন দ্রুত পূর্বাবস্থায় ফিরিয়ে আনা যায়।
হোমপেজ নয়—বাস্তবই ব্যবহারকারীর পথগুলো পরীক্ষা করুন:
নিম্নলিখিতগুলো উভয় ক্যানোনিকাল ও রিডাইরেক্টিং হোস্টে পরীক্ষা করুন:
এছাড়া নিশ্চিত করুন ঠিক এক হোস্টই ঠিকানায় দেখা যাচ্ছে এবং সবসময় HTTPS, কোনো mixed-content সতর্কতা নেই।
আপনার DNS হোস্ট যদি অ্যাপেক্সে CNAME চাইল্ডকে সমর্থন না করে, তাহলে আনফোর্স করলেই সমস্যা হতে পারে।
দ্রুত নিরাপত্তা: বর্তমান জোনের স্ক্রিনশট বা এক্সপোর্ট নিন যাতে দ্রুত পুনরুদ্ধার করা যায়।
old-host-এর জন্য সেট করা কুকি new-host-এ পাঠানো হবে না।None+Secure লাগতে পারে।ঝুঁকি কমাতে, একটি সংক্ষিপ্ত ট্রানজিশন পরিকল্পনা রাখুন যেখানে উভয় ডোমেইন কাজ করে এবং সেশন নতুন ডোমেইনে রিফ্রেশ করা যায়।