ওয়েব অ্যাপসের জন্য কাস্টম ডোমেইন সেটআপ: DNS, SSL, ও কাটওভার

কাস্টম ডোমেইন কী বদলে দেয় (এবং কী ভুল যেতে পারে)

কাস্টম ডোমেইন শুধু সুন্দর একটি URL নয়। আপনি যখন প্ল্যাটফর্ম সাবডোমেইন (উদাহরণ: Koder.ai-এ থাকা একটি অ্যাপ) থেকে আপনার নিজস্ব ডোমেইনে চলে যান, তখন ব্রাউজার ও নেটওয়ার্কগুলো এটিকে ভিন্ন সাইট হিসেবে বিবেচনা করে। এতে রাউটিং, সিকিউরিটি, এবং ব্যবহারকারীর সেশনগুলোতে প্রভাব পড়ে।

কাস্টম ডোমেইনে স্যুইচ করার পরে কিছু জিনিস অবিলম্বে বদলে যায়:

• DNS রাউটিং: ব্যবহারকারীরা পুরানো হোস্টনেমে আর যাবে না এবং আপনার DNS যেখানে ইঙ্গিত করবে ওখানে পৌঁছাবে।
• TLS/SSL: সার্টিফিকেটটি নতুন হোস্টনেমের সাথে মেলাতে হবে, এবং এটি ব্যবহারকারীরা আসার আগেই সক্রিয় থাকা দরকার।
• রিডাইরেক্ট: আপনি সিদ্ধান্ত নেবেন ব্যবহারকারী www-এ নামবে নাকি apex-এ, এবং HTTP থেকে HTTPS-এ কনসিস্টেন্ট নিয়ম থাকা দরকার।
• কুকি ও সেশন: কুকি একটি ডোমেইনের জন্য সীমাবদ্ধ। old-platform.example-এর লগইন কুকি app.yourdomain.com-এ স্বয়ংক্রিয়ভাবে কাজ করবে না।
• ক্যাশিং ও প্রোপাগেশন: DNS রেজলভার ও ব্রাউজার ফলাফলগুলো ক্য়াশ করে, তাই সবাই একসাথে স্যুইচ করে না।

স্বল্প সময়ের আউটেজগুলো সাধারণত টাইমিং থেকে আসে। DNS নতুন হোস্টে ট্রাফিক পাঠানো শুরু করতে পারে তখনই যখন SSL সার্টিফিকেট প্রস্তুত নয়, ফলে ব্রাউজার সতর্কতা দেখা যায়। অথবা উল্টোটি—SSL প্রস্তুত আছে কিন্তু অনেক ব্যবহারকারী এখনও পুরোনো স্থানে থাকে কারণ তাদের DNS ক্য়াশ সময় শেষ হয়নি।

রিডাইরেক্টও কখনও সূক্ষ্মভাবে লগইন ভেঙে দিতে পারে। হোস্টনেম বদলানো রিডাইরেক্ট (apex থেকে www বা উল্টো) কুকি হারিয়ে ফেলতে পারে যদি কুকি অন্য হোস্টের জন্য সেট করা থাকে। অথেনটিকেশন প্রদানকারীরা ব্যর্থ হতে পারে যদি তাদের callback URL এখনও পুরনো ডোমেইন দেখায়।

কম-ঝুঁকির কাটওভার মানে আপনি ওভারল্যাপের জন্য পরিকল্পনা করবেন: পুরোনো URL কাজ করা চালিয়ে রাখুন, নতুন ডোমেইন প্যারালেলে তোলা, পূর্বনির্ধারিত মুহূর্তে ট্রাফিক স্যুইচ, এবং রোলব্যাককে সহজ রাখুন যেন DNS ফেরত দেওয়াই সমাধান হয়।

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 নিয়ন্ত্রণ করে তা জানুন

অনেকেই ডোমেইন একটি রেজিস্ট্রার থেকে কিনে নেয়, কিন্তু DNS কোথাও অন্যত্র হোস্ট হতে পারে। নিশ্চিত করুন কোথায় রেকর্ডগুলো আজ পরিবর্তন করা হয়, কার অ্যাক্সেস আছে, এবং কোনো অটোমেশন পরিবর্তন করছে কি না (কোম্পানির IT, একটি এজেন্সি, বা managed DNS প্রদানকারী)। আপনি যদি লগইন করে বর্তমান রেকর্ড দেখতে না পান, তাহলে আগে সেটি ঠিক করুন।

এছাড়া ডোমেইনটি আগে কী ব্যবহার করে তা অডিট করুন। ইমেইল হলো ক্লাসিক ফাঁদ: রেকর্ড ডিলিট বা ওভাররাইট করলে মেইল ডেলিভারি নষ্ট হতে পারে।

আগে এগুলো নোট করুন:

• প্রাইমারি হোস্টনেম (apex না www) এবং রিডাইরেক্ট দিক
• এখন প্রয়োজনীয় সাবডোমেইন (app, api, admin) বনাম পরে করা আইডিয়া
• DNS কোথায় হোস্ট হচ্ছে এবং কে পাবলিশ করতে পারে
• বিদ্যমান গুরুত্বপূর্ণ রেকর্ড (MX, SPF, DKIM, DMARC, verification TXT)
• কুকি ও অথ প্রত্যাশা (এক হোস্ট বনাম সাবডোমেইন জুড়ে শেয়ার)

যদি মার্কেটিং ইতিমধ্যেই example.com-এ ইমেইল চালায়, তাহলে মেইল-রিলেটেড রেকর্ড অছোঁকা রাখুন এবং কেবল অ্যাপের জন্য প্রয়োজনীয় রেকর্ড যোগ করুন।

আপনি যে DNS রেকর্ডগুলো ব্যবহার করবেন এবং এগুলো কেন জরুরি

কাস্টম ডোমেইন মুভে ঝুঁকির বেশিরভাগই অ্যাপ নয়—একটি ভুল DNS পরিবর্তনই ট্রাফিককে যেখানে না থাকা জায়গায় পাঠাতে পারে, ইমেইল ভেঙে দিতে পারে, বা SSL ভ্যালিডেশন ব্যর্থ করাতে পারে।

মূল রেকর্ডগুলো (A, CNAME, এবং সংশ্লিষ্ট)

A record একটি নামকে একটি IP ঠিকানায় নির্দেশ করে। সরল ভাষায়: “লোককে এই সার্ভারে পাঠাও।” যখন আপনার প্রদানকারী একটি স্থায়ী IP দেয় তখন এটা অ্যাপেক্সের জন্য সাধারণ।

CNAME record একটি নামকে অন্য নামের কাছে নির্দেশ করে। সরল ভাষায়: “এই নামটিকে ওই হোস্টনেমের এলিয়াস হিসেবে মনে করো।” সাধারণত www.example.com কে প্ল্যাটফর্ম হোস্টনেমের দিকে নির্দেশ করতে ব্যবহার করা হয়।

অনেকে DNS প্রদানকারীর কাছ থেকে ALIAS/ANAME অফার পায় অ্যাপেক্সে; এটি CNAME-এর মতো আচরণ করে কিন্তু example.com-এর জন্য কাজ করে। আপনার প্রদানকারী সমর্থন করলে এটি পরিচালনা সহজ করতে পারে কারণ টার্গেট বদলে গেলেও IP তে হাত দিতে হয় না।

সহজ মানসিক মডেল:

• A: নাম → IP (ডাইরেক্ট)
• CNAME: নাম → নাম (এলিয়াস)
• TXT: নাম → টেক্সট (প্রমাণ এবং নীতিমালা)
• MX: নাম → মেইল সার্ভার (চেষ্টা না করলে স্পর্শ করবেন না)

TXT রেকর্ড: ভেরিফিকেশন, SSL, এবং ইমেইল নিরাপত্তা

প্রায়ই আপনি TXT রেকর্ড যোগ করবেন ডোমেইন মালিকানা যাচাই (প্ল্যাটফর্ম ভেরিফিকেশন) এবং SSL সার্টিফিকেট ভ্যালিডেশন (কিছু CA TXT টোকেন চায়)। TXT ইমেইল পলিসি, যেমন SPF, এর জন্যও ব্যবহৃত হয়। ভুল করে বিদ্যমান SPF TXT ডিলিট বা বদলে ফেললে মেইল ডেলিভারি নষ্ট হতে পারে।

TTL: আপনার “চেঞ্জ স্পিড” নিয়ামক

TTL নিয়ন্ত্রণ করে অন্যান্য সিস্টেম আপনার DNS উত্তর কতক্ষণ ক্য়াশ করে রাখে। কাটওভার-এর এক দিন আগে আপনি যে রেকর্ডগুলো পরিবর্তন করবেন সেগুলোর TTL কমান (সাধারণত 300 থেকে 600 সেকেন্ড)। সব স্টেবিল হলে TTL আবার বাড়ান যাতে কিউরি লোড কমে।

বিদ্যমান রেকর্ড মুছে ফেলবেন না, এবং রোলব্যাক ডকুমেন্ট করুন

সম্পাদনের আগে জোন এক্সপোর্ট বা স্ক্রিনশট নিন। আপনি কোন রেকর্ড বদলাবেন, তার পুরানো মান, নতুন মান, এবং TTL লিখে রাখুন। সমস্যা হলে রোলব্যাক মানগুলো পুনরায় বসানো।

বিশেষ করে যখন আপনার ডোমেইনে ইতিমধ্যেই MX, DKIM, বা অন্য TXT রেকর্ড থাকে—তার সময় এইটা বেশি গুরুত্বপূর্ণ।

SSL ইস্যু: ভ্যালিডেশন, সময়, এবং কাভারেজ

SSL (লক আইকন) ব্রাউজার ও আপনার অ্যাপের মধ্যে ট্র্যাফিক এনক্রিপ্ট করে। আধুনিক ব্রাউজার ও অনেক API ডিফল্টভাবে HTTPS আশা করে। ছাড়া থাকলে সতর্কতা, ব্লক করা অনুরোধ, এবং সার্ভিসওয়ার্কার, জিওলোকেশন, কিছু পেমেন্ট ফ্লো কাজ বন্ধ হয়ে যেতে পারে।

সার্টিফিকেট ইস্যু করতে CA-কে ডোমেইনের মালিকানা যাচাই করতে হবে। সাধারণ ভ্যালিডেশন পদ্ধতি হলো HTTP ভ্যালিডেশন এবং DNS TXT ভ্যালিডেশন:

• HTTP validation-এ একটি অস্থায়ী ফাইল বা রেসপন্স আপনার অ্যাপে একটি নির্দিষ্ট URL-এ রাখা হয়।
• DNS TXT validation-এ DNS জোনে একটি TXT রেকর্ড যোগ করা হয়।

আপনি যখন CDN ব্যবহার করছেন বা আপনার অ্যাপ নতুন ডোমেইনে পৌঁছনো যায় না তখন DNS validation প্রায়ই সহজ হয়।

কার কাছে সার্টিফিকেট ইস্যু হয় তা আপনার সেটআপের উপর নির্ভর করে। কেউ কেউ সরাসরি হোস্টিং স্ট্যাকে সার্টিফিকেট ইস্যু করে, কেউ CDN-এ, এবং কিছু প্ল্যাটফর্ম (উদাহরণ: Koder.ai) কাস্টম ডোমেইন সাপোর্টের সময় সার্টিফিকেট পরিচালনা করে। গুরুত্বপূর্ণ হলো কাউকে দায়িত্ব দিতে হবে সার্টিফিকেট লাইফসাইকেল-এর, রিনিউসহ।

সময় ও রিট্রাই

সার্টিফিকেট ইস্যু সবসময় তাত্ক্ষণিক নয়। DNS প্রোপাগেশন, ভ্যালিডেশন চেক, এবং রেট লিমিট ধীর করে দিতে পারে। রিট্রাই-এর জন্য প্ল্যান করুন এবং কাটওভার শেষ মুহূর্তে সমন্বয় করবেন না।

প্রায়োগিক সময়সূচি:

• কাটওভারের এক দিন আগে DNS TTL কমান।
• ভ্যালিডেশন রেকর্ডগুলো আগে যোগ করুন (DNS TXT অথবা HTTP টোকেন)।
• সার্টিফিকেট সব হোস্টনেমের জন্য ইস্যু হয়েছে কি না নিশ্চিত করুন।
• তারপরই নতুন টার্গেটের দিকে ট্রাফিক পয়েন্ট করুন।

কাভারেজ: সঠিক হোস্টনেমগুলো অন্তর্ভুক্ত আছে কি না

সার্টিফিকেটটি ব্যবহারকারীরা যে প্রতিটি হোস্টনেমে যাবে সেগুলো কভার করতে হবে। SAN (Subject Alternative Names) তালিকা চেক করুন। যদি আপনার অ্যাপ example.com এবং www.example.com উভয় স্থানে পাওয়া যাবে, তখন সার্টিফিকেটে উভয় থাকা প্রয়োজন।

ওয়াইল্ডকার্ড (*.example.com) অনেক সাবডোমেইনকে ঢেকে দিতে পারে, কিন্তু এগুলো অ্যাপেক্স ডোমেইন (example.com) ঢেকে না।

কনক্রিট উদাহরণ: যদি আপনি শুধু www.example.com-এর জন্য সার্টিফিকেট ইস্যু করেন, তাহলে যেসব ব্যবহারকারী শুধু example.com টাইপ করে তাদের সাইটে সতর্কতা দেখা দেবে, যদি না আপনি এমন এক লেয়ারে রিডাইরেক্ট করেন যার কাছে example.com-এর বৈধ সার্টিফিকেট আছে।

রিডাইরেক্ট নিয়ম: www, apex, HTTP→HTTPS, এবং নিরাপদ ডিফল্ট

রিডাইরেক্টগুলো সহজ মনে হলেও ডোমেইন সমস্যাগুলোর বেশিরভাগ এখানেই দেখা দেয়: লুপ, মিশ্র কনটেন্ট, এবং ব্যবহারকারীরা হোস্ট বদলানোতে লগআউট হয়ে যাওয়া।

একটি ক্যানোনিক্যাল হোস্ট বেছে নিন এবং সেটার প্রতি অনুবর্তী হন: www.example.com না example.com—অন্যটা ক্যানোনিক্যাল হোস্টের দিকে রিডাইরেক্ট করা উচিত যাতে কুকি, সেশন, এবং SEO সিগন্যাল সঙ্গতিপূর্ণ থাকে।

নিরাপদ ডিফল্ট:

• একটি ক্যানোনিক্যাল হোস্ট, এবং অন্য হোস্ট থেকে একক 301 রিডাইরেক্ট
• প্রতিটি অনুরোধে http:// থেকে https://-এ 301 রিডাইরেক্ট
• রিডাইরেক্টে পূর্ণ পথ ও কুয়েরি স্ট্রিং রাখুন (ডিপ লিঙ্ক কাজ করবে)
• একবারে রিডাইরেক্ট করুন (চেইন এড়ান যেমন http → https → www)

HTTP থেকে HTTPS-এ, এমন নিয়ম এড়ান যা ব্যবহারকারীদের বারবার ফিরিয়ে দেয়। লুপ প্রতিরোধের সহজ উপায় হলো অনুরোধটি আসলেই কেমন ছিল তার ওপর ভিত্তি করে সিদ্ধান্ত নেওয়া। আপনার অ্যাপ যদি প্রক্সি বা CDN-র পেছনে থাকে, তাহলে ফরওয়ার্ডেড হেডারগুলো সম্মান করতে কনফিগার করুন; না হলে অ্যাপ ভাববে প্রতিটি অনুরোধ HTTP এবং অবিরত রিডাইরেক্ট করবে।

মুভ করার সময় পুরোনো পাথগুলো জীবিত রাখুন। আপনি যদি রুট বদলান (যেমন /login থেকে /sign-in), সেগুলোর জন্য স্পষ্ট রিডাইরেক্ট যোগ করুন। একটি সাধারণ রিডাইরেক্ট হোমপেজে পাঠালে বুকমার্ক এবং শেয়ার্ড লিংক ভেঙে যাবে।

প্রথমেই HSTS চালু করবেন না। যদি আপনি খুব আগে এটি চালু করেন এবং পরে HTTP দিয়ে ভ্যালিডেশন বা ট্রাবলশুট করতে হয়, ব্রাউজার HTTP নেবেন না। HTTPS স্থির হয়ে গেলে এবং সাবডোমেইন কভারেজ নিশ্চিত হলে HSTS বিবেচনা করুন।

রিডাইরেক্ট পরীক্ষা করতে একটি অস্থায়ী টেস্ট হোস্টনেম ব্যবহার করুন, কিছু বাস্তব ডিপ লিংক পরীক্ষা করুন (অথেনট পেজসহ), এবং কমান্ড-লাইন অনুরোধ চালিয়ে প্রতিটি রিডাইরেক্ট ধাপ ও চূড়ান্ত গন্তব্য দেখুন।

ধাপে ধাপে কম-ঝুঁকির কাটওভার প্ল্যান (কোনো ডাউনটাইম নয়)

নিরাপদ কাটওভার অনেকটাই টাইমিং। নতুন ডোমেইনটি প্রস্তুত ও পরীক্ষা করা থাকবে আগে থেকেই এবং বাস্তব ব্যবহারকারীরা সেখানে পাঠানোর আগে DNS পরিবর্তনগুলো দ্রুত ছড়িয়ে পড়বে যাতে আপনি ইস্যু সময় আটকা না পড়েন।

1) প্রোডাকশন DNS-এ হাত দেওয়ার আগে প্রস্তুত ও টেস্ট করুন

আপনি পরিবর্তন করার আগে আপনার DNS TTL কমান (যে রেকর্ডগুলো পরিবর্তন করবেন)। সম্ভব হলে এক দিন আগে এটি করুন এবং পুরোনো TTL উইন্ডো শেষ হওয়া পর্যন্ত অপেক্ষা করুন।

এরপর your hosting/provider-এ কাস্টম ডোমেইন যোগ করুন এবং যে ভেরিফিকেশন তারা চায় তা শেষ করুন। Koder.ai-র মতো প্ল্যাটফর্ম ব্যবহার করলে সেখানে আগে ডোমেইন যোগ করুন যেন প্ল্যাটফর্ম মালিকানা নিশ্চিত করে এবং রাউটিং প্রস্তুত করে।

SSL আগে ইস্যু করুন। ভ্যালিডেশন ও রেট লিমিটের কারণে সার্টিফিকেটে সময় লাগতে পারে, এবং আপনি চান না যে কাটওভারের সময় এটি বিলম্ব করুক।

ডোমেইন পাবলিক করার আগে প্রাইভেট টেস্ট করুন: নিজের মেশিনে সাময়িক হোস্ট এন্ট্রি ব্যবহার করে নতুন endpoint-এ যান এবং সঠিক সার্টিফিকেটে HTTPS দিয়ে সাইট লোড হচ্ছে কি না যাচাই করুন।

2) ছোট, পুনরুদ্ধারযোগ্য ধাপে কাটওভার করুন

স্টেজড অ্যাপ্রোচ ব্যবহার করুন যাতে যদি কিছু ভুল দেখেন দ্রুত থামিয়ে দেওয়া যায়:

• আগেভাগে TTL কমান এবং পুরোনো TTL পরিপূর্ণভাবে পেরোয়ার জন্য অপেক্ষা করুন।
• হোস্টে ডোমেইন ভেরিফিকেশন সম্পন্ন করুন এবং অভ্যন্তরীণভাবে ডোমেইনটি সঠিক অ্যাপে পয়েন্ট করছে কি না নিশ্চিত করুন।
• প্রতিটি হোস্টনেমের জন্য SSL সক্রিয় আছে কি না নিশ্চিত করুন (apex এবং/অথবা www)।
• একটি নিয়ন্ত্রিতভাবে DNS পরিবর্তন করুন: প্রথমে একটি সাবডোমেইন, একটি ছোট অঞ্চল, বা সীমিত দর্শক রুট যদি সম্ভব।
• পুরোনো ডোমেইন লিপ্ত রাখুন এবং রিডাইরেক্ট রাখুন যতক্ষণ আপনি ট্র্যাফিক ও এরর রেট স্থিতিশীল না দেখেন।

যদি আপনি DNS স্তরে আসল ক্যানারি করতে না পারেন, তবুও একটি হোস্টনেম প্রথমে স্যুইচ করে স্টেজিং করতে পারেন (যেমন www) এবং অ্যাপেক্স পরে ছেড়ে দিন যতক্ষণ না আস্থা হয়।

3) শান্ত অবস্থায় রোলব্যাক পরিকল্পনা করুন

আপনি কি ফিরিয়ে দেবেন ঠিক লিখে রাখুন (কোন রেকর্ড, কী মান), এবং কে করবে তা ঠিক করুন। রোলব্যাক সাধারণত পূর্বাবস্থায় DNS ফিরিয়ে দেয়ার মতো।

পুরোনো কনফিগারেশনটি (SSL সহ) এখনও বৈধ আছে কিনা নিশ্চিত রাখুন যাতে ব্যবহারকারীরা সিম্পলি ফেরত পেতে পারে।

কাটওভারের পর কুকি, সেশন ও অথ ভাঙা প্রতিরোধ করুন

ডোমেইন পরিবর্তন কেবল DNS পরিবর্তন নয়। অনেক অ্যাপের জন্য “লগ ইন থাকা” নির্ভর করে কুকির উপর যেগুলো ব্রাউজার নির্দিষ্ট হোস্টনেমের সাথে জোরপূর্বক মেলে। যদি আপনি একটি হোস্টনেম থেকে আরেকটাতে স্যুইচ করেন, ব্রাউজার পুরানো কুকি পাঠানো বন্ধ করে দিতে পারে এবং অ্যাপ সবাইকে লগআউট দেখাবে।

কুকি সেটিংস প্রায়শই কারণ:

• Domain সিদ্ধান্ত করে কোন হোস্টনেমগুলো কুকি পাবে। .example.com হিসেবে কুকি সেট করলে app.example.com ও www.example.com উভয়েই পাঠানো যাবে।
• Path কুকি কোথায় পাঠানো হবে সেটা সীমাবদ্ধ করে। যদি খুব সংকীর্ণ হয় (যেমন /api), ওয়েব UI দেখতে পাবে না।
• Secure কুকিটিকে কেবল HTTPS-এ পাঠায়। কাটওভার করে HTTPS-only করলে HTTP অনুরোধে কুকি পাঠানো হবে না।
• SameSite ক্রস-সাইট রিডাইরেক্ট ও এমবেডেড ফ্লোকে প্রভাবিত করে। 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-কে ঢেকে রাখুক, এমনকি আপনি একটিকে অন্যটির দিকে রিডাইরেক্ট করার পরিকল্পনা থাকলেও।

অন্যান্য সাধারণ ভুল:

• TTL কম না করে DNS পরিবর্তন করা, তারপর পুরনো উত্তর শেষ হওয়ার জন্য ঘণ্টা অপেক্ষা করা
• লুপ সৃষ্টি করা এমন রিডাইরেক্ট নিয়ম রাখা (www→apex, তারপর apex→www), অথবা এক জায়গায় HTTP চাপা দিয়ে অন্য জায়গায় HTTPS জোর করা
• হার্ডকোডেড http:// অ্যাসেটগুলো চালু রেখে মিক্সড কনটেন্ট পাঠানো
• নন-ওয়েব DNS রেকর্ড ভুলে যাওয়া, বিশেষ করে MX ও TXT, যা ইমেইল ও ডোমেইন ভেরিফিকেশন ভাঙে
• কেবল এক ব্রাউজারে টেস্ট করে ক্যাশড HSTS বা কুকি কুইর্ক মিস করা

একটি দ্রুত স্যানিটি চেক: উভয় হোস্টনেম (www ও অ্যাপেক্স) HTTPS-এ খুলুন, লগইন করুন, রিফ্রেশ করুন, এবং নিশ্চিত করুন ঠিকানার বার কখনও HTTP-এ ফিরে যায় না।

আপনি যদি Koder.ai-এর মতো প্ল্যাটফর্মে কাজ করে থাকেন, নিশ্চিত করুন কাস্টম ডোমেইন কানেক্টেড এবং SSL ইস্যু হয়েছে প্রোডাকশনে স্পর্শ করার আগে, এবং রোলব্যাক অপশন প্রস্তুত রাখুন যাতে একটা খারাপ রিডাইরেক্ট বা রেকর্ড পরিবর্তন লম্বা সময় ধরে না থাকে।

কাটওভারের আগে, সময়ে, এবং পরে দ্রুত চেকলিস্ট

শান্ত কাটওভার বেশিরভাগই প্রস্তুতির কাজ। লক্ষ্য সহজ: ব্যবহারকারীরা লগইন করে থাকতে পারে, কুকি কাজ করে, এবং সমস্যা হলে দ্রুত রোলব্যাক করতে পারেন।

কাটওভার আগে

এসব করুন যখন ট্রাফিক এখনও পুরোনো ডোমেইনে যাচ্ছে। সম্ভব হলে এক দিন নিন যাতে DNS পরিবর্তনের সময় ক্য়াশ settle হয়।

• DNS TTL কমান (যে রেকর্ডগুলো পরিবর্তন করবেন) এবং বর্তমান মানগুলো লিখে রাখুন যাতে দ্রুত পুনরুদ্ধার করা যায়।
• প্রতিটি হোস্টনেম ডকুমেন্ট করুন (apex, www, api ইত্যাদি) এবং SSL ভ্যালিডেশন পদ্ধতি নির্ধারণ করুন (DNS না HTTP)।
• রিডাইরেক্ট নিয়ম গুলো স্টেজিং-এ প্রস্তুত ও পরীক্ষা করুন: HTTP→HTTPS, www→apex (অথবা উল্টো), এবং একটি ক্যানোনিক্যাল হোস্ট।
• URL নির্ভর auth সেটিংস আপডেট করুন: OAuth callback URLs, allowed origins, কুকি ডোমেইন সেটিংস, এবং SSO কনফিগ।
• সিদ্ধান্ত নিন কে কাটওভার পর্যবেক্ষণ করবে (লগ, uptime checks, সাপোর্ট ইনবক্স) এবং একটি ছোট পরিবর্তন উইন্ডো ঠিক করুন।

কাটওভার সময় ও পরে

DNS ফ্লিপ করার পরে প্রথম এক ঘন্টাকে একটি incident drill হিসেবে দেখুন। শুধুমাত্র status ড্যাশবোর্ড নয়, বাস্তব ব্যবহারকারীর ফ্লো নজর করুন।

• করার সময়: 4xx/5xx spike, রিডাইরেক্ট লুপ, এবং লগইন ত্রুটি (বিশেষ করে “invalid redirect URI” বা হঠাৎ সেশন ড্রপ) পর্যবেক্ষণ করুন।
• পরে: বহু ব্রাউজারে সার্টিফিকেট চেইন বৈধতা যাচাই করুন এবং গুরুত্বপূর্ণ পেজগুলো HTTPS-এ মিক্সড কনটেন্ট ছাড়া লোড হচ্ছে কিনা দেখুন।
• পরে: ক্যানোনিক্যাল হোস্ট আচরণ যাচাই করুন (ফাইনাল ঠিকানায় ঠিক এক হোস্ট) এবং গুরুত্বপূর্ণ কুকিগুলো সেট ও পাঠানো হচ্ছে কি না নিশ্চিত করুন।
• পরে: পুরোনো ডোমেইন কিছু সময় রিডাইরেক্ট করে রাখুন—অনেক ব্যবহারকারী পুরোনো বুকমার্ক বা ইমেইল লিংক থেকে ফিরে আসবে।

Koder.ai (অথবা অন্য কোনো প্ল্যাটফর্ম) কাস্টম ডোমেইন ও SSL হ্যান্ডেল করলেও, এই চেকলিস্টটি প্রযোজ্য—বেশিরভাগ সমস্যা আসে DNS ও রিডাইরেক্ট থেকে, না যে অ্যাপ কোড থেকে।

উদাহরণ পরিস্থিতি: প্ল্যাটফর্ম URL থেকে কাস্টম ডোমেইনে স্থানান্তর

আপনার অ্যাপ আছে একটি অস্থায়ী প্ল্যাটফর্ম ঠিকানায় যেমন 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)। সার্টিফিকেট ইস্যু ও সক্রিয় না হওয়া পর্যন্ত ট্রাফিক স্যুইচ করবেন না—অন্যথায় ব্রাউজার সতর্কতা দেখা দেবে।

কাটওভার টাইমলাইন স্পষ্ট চেকপয়েন্টসহ:

• T-24h: TTL কমান, দ্রুত রোলব্যাক নিশ্চিত করুন
• T-0: অ্যাপ হোস্টে ডোমেইন সক্ষম করুন, SSL প্রস্তুত নিশ্চিত করুন
• T+15m: ইনকগনিটো উইন্ডোতে example.com পরীক্ষা করুন (হোমপেজ, স্ট্যাটিক অ্যাসেট, API কল)
• T+30m: রিডাইরেক্ট সক্রিয় করুন (HTTP→HTTPS, এবং www→apex)
• রোলব্যাক মুহূর্ত: যদি লগইন বা API কল ব্যর্থ হয়, DNS পুরনো টার্গেটে ফিরিয়ে দিন এবং প্ল্যাটফর্ম URL লাইভ রাখুন

মুভের পরে কুকি আচরণ যাচাই করুন। লগইন করুন, রিফ্রেশ করুন, এবং দুটো হোস্টেই লগইন ধরে আছে কিনা পরীক্ষা করুন। সেশন ভাঙলে সাধারণত কুকি ডোমেইন বা SameSite সেটিং ধরে থাকে যা পুরনো হোস্ট ধরে ধরেই বানানো হয়েছিল।

পরবর্তী ধাপ: মনিটর, ডকুমেন্ট, এবং ভবিষ্যৎ পরিবর্তনগুলো নিরাপদ করা

কাটওভারে কাজ হয়ে গেলেও কাজ শেষ হয় না। বেশিরভাগ ডোমেইন মুভ পরে ব্যর্থ হয় কারণ কেউ দেখেনি ধীরভাবে ড্রিফট: একটি সার্টিফিকেট মেয়াদ শেষ হয়ে আসছে, হঠাৎ করা DNS পরিবর্তন, বা রিডাইরেক্ট টুইক যা লগইন ভেঙে দেয়।

একটি ছোট মনিটরিং রুটিন স্থাপন করুন যা আপনি রক্ষণাবেক্ষণ করবেন। এন্টারপ্রাইজ টুল দরকার নেই তবে কিছু নির্ভরযোগ্য সিগন্যাল থাকুক: গুরুত্বপূর্ণ পেজগুলোর (হোম, লগিন, একটি অথেন্টিকেটেড পেজ) availability checks, সার্টিফিকেট মেয়াদ শেষের এ্যালার্ট (উদাহরণ: 30 ও 7 দিন আগে), এরর-রেট ট্র্যাকিং (শুধু uptime নয়, 4xx/5xx স্পাইক দেখুন), এবং মাঝে মাঝে রিডাইরেক্ট ভ্যালিডেশন (HTTP→HTTPS ও পছন্দের হোস্টনেম জিতে আছে কি না) চালান।

একটু শোনা অবস্থা থাকলে দ্রুত রোলব্যাক উইন্ডো রাখা—২৪ থেকে ৭২ ঘণ্টার জন্য পূর্বাবস্থা দ্রুত ফেরত আনার উপায় রাখুন (পুরোনো DNS টার্গেট, পুরোনো হোস্টিং কনফিগ, পুরোনো TLS সেটিং)।

একবার আস্থা হলে DNS TTL আবার বাড়ান। লো TTL পরিবর্তনের সময় উপকারী হলেও এটি রিজল্ভার লোড বাড়ায় এবং ছোট ভুলগুলোতে বড় প্রভাব ফেলে। একটি সাধারণ TTL বেছে নিন যা আপনার পরিবর্তনের আগ্রহের সঙ্গে মেলে (অনেক দল 1 থেকে 4 ঘন্টা রাখে)।

শেষে, চূড়ান্ত অবস্থা ডকুমেন্ট করুন—কোন রেকর্ড আছে (টাইপ, নাম, মান, TTL), কোন হোস্টনেম সাপোর্টেড, এবং ঠিক কোন রিডাইরেক্ট নিয়ম আছে। অন্তর্ভুক্ত করুন কোথায় সার্টিফিকেট ইস্যু হয়, কী কভার করে (apex, www, সাবডোমেইন), এবং কে রিনিউ-এর মালিক।

আপনি যদি একজন প্ল্যাটফর্মে বিল্ড ও ডিপ্লয় করেন, ডোমেইনগুলোকে প্রথম-শ্রেণীর ফিচার হিসেবে ট্রিট করলে সুবিধা হয় এবং কনফিগারেশন পরিবর্তন দ্রুত পূর্বাবস্থায় ফিরিয়ে আনা সহজ হয়। Koder.ai-এ কাস্টম ডোমেইনগুলো স্ন্যাপশট ও রোলব্যাকের পাশে থাকলে ভবিষ্যৎ ডোমেইন ও রিডাইরেক্ট পরিবর্তনগুলো কম চাপযুক্ত হয়।