১৯ নভে, ২০২৫·7 মিনিট
DNS ও SSL সমস্যার জন্য কাস্টম ডোমেন ট্রাবলশুটিং চেকলিস্ট
এই কাস্টম ডোমেন ট্রাবলশুটিং চেকলিস্টটি ব্যবহার করে সহজ ভেরিফিকেশন ধাপ নিয়ে DNS রেকর্ড সমস্যা, প্রোপাগেশন বিলম্ব এবং SSL সময়গত সমস্যাগুলো নির্ণয় করুন।
এই কাস্টম ডোমেন ট্রাবলশুটিং চেকলিস্টটি ব্যবহার করে সহজ ভেরিফিকেশন ধাপ নিয়ে DNS রেকর্ড সমস্যা, প্রোপাগেশন বিলম্ব এবং SSL সময়গত সমস্যাগুলো নির্ণয় করুন।
“কাস্টম ডোমেন কাজ করছে না” বলতে অনেক ভিন্ন ধরনের ত্রুটি বোঝানো হতে পারে। আপনার ব্রাউজার লক্ষণ দেখায়, কারণ জানায় না। কিছুই বদলানোর আগে প্রথমে লিখে নিন আপনি ঠিক কী দেখছেন।
সাধারণ লক্ষণগুলো:
বেশিরভাগ ক্ষেত্রে, সমস্যা একটির মধ্যে সীমাবদ্ধ:
ট্রাবলশুটিং শুরু করার আগে নিশ্চিত করুন আপনার কাছে দুটি জায়গার অ্যাক্সেস আছে: যেখানে আপনি DNS রেকর্ড এডিট করেন (রেজিস্ট্রার বা DNS প্রদানকারী) এবং যেখানে আপনি ডোমেনটি হোস্টিং দিকে জোড়া করছেন। উদাহরণস্বরূপ, যদি আপনি Koder.ai-তে ডেপ্লয় করা অ্যাপকে কাস্টম ডোমেন যুক্ত করেন, আপনার ডোমেনের DNS অ্যাক্সেস এবং অ্যাপের হোস্টিং/ডেপ্লয়মেন্ট সেটআপে ডোমেন সেটিংস, উভয়ের অ্যাক্সেস চাই।
কিছু সমাধান তাৎক্ষণিক (যেমন টাইপো ঠিক করা)। অন্যগুলো সময় নেয়। DNS পরিবর্তন দেখাতে সময় পর্যন্ত লাগতে পারে, এবং SSL সাধারণত DNS সঠিকভাবে পয়েন্ট করা এবং ডোমেন পৌঁছযোগ্য না হওয়া পর্যন্ত শেষ হবে না। লক্ষ্য হলো অনুমান বন্ধ করে প্রতিটি স্তর পর্যায়ক্রমে নিশ্চিত করা।
অধিকাংশ ডোমেন সমস্যা বোঝায় (1) আপনি যে হোস্টনেম পরীক্ষা করছেন, (2) কোথায় DNS ম্যানেজ করা হচ্ছে, এবং (3) রেকর্ডটি আসলে কোথায় পয়েন্ট করছে—এই তিনটার মধ্যে মিল নেই। এই তিনটি এক হয়ে গেলে SSL সাধারণত শেষ ধাপ।
ডোমেনের দুইটি সাধারণ ফর্ম আছে: রুট ডোমেন (example.com, apex বলা হয়) এবং সাবডোমেন (www.example.com, app.example.com)। এগুলো সম্পর্কিত কিন্তু আলাদা DNS রেকর্ড থাকতে পারে। তাই স্বাভাবিক যে www কাজ করে আর apex কাজ করে না, অথবা উল্টোটা ঘটে।
নেমসার্ভার ঠিক করে কে আপনার DNS জোনের দায়িত্বে। যদি আপনি একটি কোম্পানি থেকে ডোমেন কিনে থাকেন কিন্তু নেমসার্ভার অন্যত্র নির্দেশ করে, আপনাকে সেই নেমসার্ভার যেখানে নির্দেশ করছে সেখানে DNS এডিট করতে হবে। অনেক “আমি আপডেট করেছি কিন্তু কিছুই পরিবর্তন হয়নি” কেস হয় ভুল ড্যাশবোর্ডে রেকর্ড বদলানোর কারণে।
এগুলো প্রধান রেকর্ড টাইপের কাজগুলো:
TTL হচ্ছে “এটি কতক্ষণ ক্যাশে রাখবে” টাইমার। কম TTL মানে ক্যাশ দ্রুত রিফ্রেশ হয়। বেশি TTL মানে আপনি লম্বা অপেক্ষা করতে পারেন, এমনকি আপনি রেকর্ড ঠিক করলে ও। পুরানো মান কিছু সময় দেখা স্বাভাবিক।
যখন কাস্টম ডোমেন ব্যর্থ হয়, সাধারণত চারটি একটি বাটকেটে পড়ে: DNS রেজলভ হয় না, DNS ভুল জায়গায় রেজলভ করে, SSL প্রস্তুত নয়, অথবা কেবল কিছু মানুষের কাছে ব্যর্থ কারণ ক্যাশিং।
এই ডিসিশন ট্রি ব্যবহার করুন:
www কাজ করে কিন্তু root ডোমেন না করে (বা উল্টো), আপনি সম্ভবত কেবল একটি হোস্টনেম কনফিগার করেছেন, বা টক্কর-করা রিডাইরেক্ট নিয়ম আছে।যে হোস্টিং প্ল্যাটফর্মগুলো ডোমেন ও সার্টিফিকেট অটোমেট করে, সেখানে “cannot find host” এবং “certificate pending” এর মধ্যে পার্থক্য জানালে আপনি জানবেন DNS ঠিক করতে হবে নাকি SSL-এ অপেক্ষা করতে হবে।
অনেক ডোমেন ত্রুটি শুরু হয় একটি সাধারণ মিল না থাকার কারণেই: আপনি এক হোস্টনেমের DNS সেট করেছেন, কিন্তু আপনি অন্যটি পরীক্ষা করছেন।
প্রথমে লিখে নিন যে কোন হোস্টনেমটি লাইভ করতে চান। রুট ডোমেন দেখতে example.com। একটি সাবডোমেন দেখতে www.example.com বা app.example.com। এগুলো আলাদা DNS এন্ট্রি, তাই “www কাজ করে” মানে apex কাজ করবে, এমন নয়।
পরের ধাপে, আপনার হোস্টিং প্ল্যাটফর্ম থেকে প্রত্যাশিত টার্গেট খুঁজে বের করুন। কিছু হোস্ট IP ঠিকানা দেয় (A বা AAAA রেকর্ডের জন্য)। কিছু অন্য একটি হোস্টনেম দেয় (CNAME-এর জন্য)। যদি আপনার হোস্ট ডোমেইন সেটআপ স্ক্রিনে কোনো মান দেয়, সেটাই সুত্রগ্রাহ্য রাখুন।
কিছুই বদলানোর আগে, বর্তমান সেটিংস কপি করে রাখুন:
এছাড়া নিশ্চিত করুন আপনি সঠিক DNS জোন এডিট করছেন। ভুল ডোমেন, ভুল এনভায়রনমেন্ট, বা ভুল প্রদানকারী অ্যাকাউন্টে আপডেট করা সহজ।
অনেক সমস্যা কেবল ভুল রেকর্ড টাইপের। দুইটি কেইস আলাদা করে দেখুন: রুট ডোমেন (example.com) এবং সাবডোমেন (www.example.com)। অনেক DNS প্রদানকারীর কাছে তারা আলাদাভাবে আচরণ করে।
A রেকর্ড একটি নামকে IPv4 ঠিকানায় পয়েন্ট করে। অনেক সেটআপে রুট ডোমেনের জন্য A রেকর্ড ব্যবহার করা হয় কারণ কিছু প্রদানকারী apex-এ CNAME অনুমতি দেয় না। যদি আপনার হোস্ট একটি IP দেয়, A রেকর্ড সাধারণত সঠিক।
AAAA হলো IPv6 ভার্সন। একটি ভুল AAAA রেকর্ড পুরানো গন্তব্যে পয়েন্ট করলে বিভ্রান্তিকর “আমার কাছে কাজ করে” আচরণ তৈরি হতে পারে, কারণ কিছু ভিজিটর IPv6 মারফত পৌঁছাবে আর কেউ IPv4 মারফত। যদি আপনার হোস্ট IPv6 টার্গেট না দিয়ে থাকে, ভুল AAAA রেকর্ড মুছে ফেলা প্রায়ই অদ্ভুত বাগ মেটায়।
CNAME একটি সাবডোমেনকে অন্য হোস্টনেমে পয়েন্ট করে (প্রায়ই www-এর জন্য)। যখন হোস্ট আপনাকে একটি নামকৃত এন্ডপয়েন্ট লক্ষ্য করতে বলছে, তখন এটি সুবিধাজনক।
TXT রেকর্ড ভেরিফিকেশন এবং চ্যালেঞ্জের জন্য—সাধারণ ভুলগুলোর মধ্যে আছে ভুল নাম (root বনাম _acme-challenge বনাম সাবডোমেন), অতিরিক্ত স্পেস, বা ভুল মান পেস্ট করা।
কনফ্লিক্টগুলো খুঁজে দেখুন—এগুলো সবচেয়ে ঝামেলা করে:
অনেক “কাস্টম ডোমেন কাজ করছে না” কেস আসলেই রেকর্ড ভ্যালু নিয়ে নয়। সেগুলো ঘটে কারণ রেকর্ড ভুল প্রদানকারীতে যোগ করা হয়েছে। যদি আপনার ডোমেন Provider A-র nameservers ব্যবহার করে, Provider B-র ড্যাশবোর্ডে রেকর্ড বদলালেও কোনো_public পরিবর্তন হবে না, যদিও ওই ড্যাশবোর্ডে রেকর্ড ঠিক দেখায়।
আপনার কম্পিউটার থেকে DNS-কে জিজ্ঞেস করে একটি দ্বিতীয় মতামত নিন:
dig NS example.com
এই কমান্ড যে nameservers রিটার্ন করে সেগুলোই authoritative।
একটি দ্রুত সেনসিবিলিটি চেক:
ns1... এবং ns2... মতো nameservers দিচ্ছে, ওই একই মানগুলো রেজিস্ট্রারে মেলে থাকতে হবে।যদি আপনি ভুল প্রদানকারীর কাছে রেকর্ড আপডেট করেন, প্রায়ই দুইটি ড্যাশবোর্ডই মিলবে না। কেবলই authoritative nameservers-ই গণ্য।
নেমসার্ভার রেজিস্ট্রারে পরিবর্তনের পরে বিলম্বেও খেয়াল রাখবেন। ট্রানজিশন উইন্ডো চলাকালীন ফলাফল অনিশ্চিত দেখাতে পারে আপনি কোথা থেকে পরীক্ষা করছেন তার উপর নির্ভর করে। যদি nameservers এখনও পরিবর্তিত হচ্ছে, nameserver সেট স্টেবল না হওয়া পর্যন্ত রেকর্ড এডিট থামান, তারপর চালিয়ে যান।
“Propagation” কোনও এক সুইচ নয়। এটা DNS ক্যাশের চেইন (ISP, ফোন ক্যারিয়ার, পাবলিক রিসলভার, এবং আপনার নিজস্ব ডিভাইস) আপডেট হওয়ার ভিন্ন গতির সমষ্টি। এজন্য আপনার ডোমেন সহকর্মীর কাছে কাজ করতে পারে কিন্তু আপনার কাছে না।
TTL (time to live) বলছে কতক্ষণ পর্যন্ত কোনো রিসলভার উত্তরটি রাখতে পারবে। যদি পুরাতন TTL 1 ঘণ্টা ছিল, কিছু মানুষ প্রায় এক ঘণ্টা পুরানো মান দেখতে থাকবে। TTL কমানো কেবল তখনই সাহায্য করে যদি আপনি পরিবর্তনের আগে সেটি কমিয়ে থাকতেন।
ক্যাশিং ডিলেই থেকে আসা সমস্যা আলাদা করতে কয়েকটি দ্রুত চেক করুন:
www) ফেরত যাচাই করুনযদি যেকোনো জায়গায় রেকর্ড ভুল থাকে (ভুল IP, অনুপস্থিত www, পুরানো CNAME), সেটি ঠিক করুন। যদি বেশিরভাগ স্থানে রেকর্ড ঠিক দেখা যায় কিন্তু এক নেটওয়ার্ক পুরোনো মান দেখায়, এটি সাধারণত ক্যাশিং ডিলেই।
SSL সার্টিফিকেট সাধারণত এক মৌলিক কারণে ব্যর্থ হয়: সার্টিফিকেট প্রদানকারী ডোমেনটি ভেরিফাই করতে পারে না যতক্ষণ না DNS সঠিকভাবে পয়েন্ট করে।
সাধারণ সিকোয়েন্স সহজ:
সাধারণ ব্লকারগুলো চোখসহজে মিস করা যায়। ভুল A বা CNAME টার্গেট ভ্যালিডেশন চেকগুলোকে ভুল সার্ভারে নিয়ে যায়। একটি স্থবির AAAA রেকর্ড কিছু ভিজিটরকে আপনার কাজ করা A রেকর্ড অগ্রাহ্য করে ভুল সার্ভারে পাঠাতে পারে, ফলে HTTPS কেবল তাদের জন্যই ব্যর্থ হবে। প্রয়োজনীয় TXT অনুপস্থিত থাকলে প্ল্যাটফর্ম সার্টিফিকেট ইস্যু করতে পারবে না।
লক্ষণগুলো ব্যবহার করে “এখনই ইস্যু হচ্ছে” এবং “মিসকনফিগারড” আলাদা করুন:
অপেক্ষার সময়, রেকর্ড বারবার বদলাবেন না। প্রতিটি পরিবর্তন ঘড়ির কাঁটা রিসেট করে এবং বিভিন্ন নেটওয়ার্কে ভিন্ন উত্তর তৈরি করতে পারে। একবার সঠিক রেকর্ড সেট করুন, তারপর সার্টিফিকেট ইস্যু হওয়া পর্যন্ত রেজলিউশন ও ভেরিফিকেশন পুনরায় যাচাই করুন।
Koder.ai-এর মতো প্ল্যাটফর্ম ব্যবহার করলে, নিরাপদ ফ্লো একই: নিশ্চিত করুন DNS প্রত্যাশিত টার্গেটে পয়েন্ট করছে, ভুল AAAA রেকর্ড থাকলে মুছে ফেলুন, এবং DNS স্থিতিশীল হওয়ার পরে SSL-কে সময় দিন।
ভালো ট্রাবলশুটিং মূলত তুলনা: যা আপনি দেখছেন বনাম আপনি কী আশা করেছিলেন। “আমার ফোনে লোড হচ্ছে”-এর উপর নির্ভর করবেন না—পুনরাবৃত্তি যোগ্য চেক ব্যবহার করুন।
একটি DNS লুকআপ টুল (যেমন nslookup বা dig) ব্যবহার করে রিটার্নকৃত মানটি আপনি ঠিক কি সেট করেছেন তাতে মিলছে কিনা যাচাই করুন (A বা AAAA-এর জন্য একটি IP, CNAME-এর জন্য একটি হোস্টনেম, TXT-এর জন্য একটি টোকেন)।
# Apex (root) domain
dig example.com A
dig example.com AAAA
# www subdomain
dig www.example.com CNAME
# TXT (often used for verification)
dig example.com TXT
আপনি যেসব নাম ব্যবহার করছেন সেগুলো দুইটি চেক করুন: apex (example.com) এবং www (www.example.com)। সাধারণত একটি সঠিক হলেও অন্যটি পুরোনো কোথাও পয়েন্ট করে থাকে।
apex ও www উভয়ের জন্য http:// এবং https:// উভয় খুলুন। আপনি একটি স্পষ্ট “হোম” ডোমেইন এবং একটি পরিষ্কার রিডাইরেক্ট চান।
www) এবং অন্যটিকে সেটার দিকে রিডাইরেক্ট করুন।যদি নেটওয়ার্ক অনুযায়ী ফলাফল ভিন্ন হয়, হয়তো আপনি ক্যাশিং বা প্রোপাগেশন দেখছেন। একটি ছোট লগ রাখুন: আপনি কী বদলালেন, কোথায় বদলালেন, সময়, এবং আপনি কি পর্যবেক্ষণ করেছেন।
অধিকাংশ DNS ও SSL সমস্যা রহস্য নয়। এগুলো ছোট ভুল—আপনি ভুল জিনিস চেক করছেন, বা খুব দ্রুত পরিবর্তন করে পরিষ্কার রিড রিড আউটপুট পাচ্ছেন না।
সবচেয়ে সময় খেয়াল খাওয়ানো বিষয় হলো দুই জায়গায় DNS এডিট করা। নামসার্ভার বদলানোর পরে প্রায়ই এটা হয়: আপনি রেজিস্ট্রারে রেকর্ড আপডেট করেন, কিন্তু DNS আসলে অন্য জায়গায় হোস্ট হচ্ছে। এক ড্যাশবোর্ড ঠিক দেখলেও পাবলিক ফলাফল বদলাবে না।
আরেকটি ক্লাসিক ভুল হলো রুট ডোমেনে CNAME দেওয়ার চেষ্টা করা যেখানে প্রদানকারী তা সমর্থন করে না। আপনাকে A রেকর্ড বা যদি আপনার DNS প্রদানকারী ALIAS বা ANAME স্টাইল রেকর্ড দেয় তা ব্যবহার করতে হতে পারে।
IPv6ও ঝামেলা বাড়াতে পারে। একটি পুরানো AAAA রেকর্ড কিছু ভিজিটরকে ভুল সার্ভারে পাঠাতে পারে যখন অন্যরা সঠিক IP পায়।
“জাস্ট ইন কেস” রেকর্ড নিয়ে যুক্তিহীন হোন—একাধিক A রেকর্ড ভুল কনফিগারেশনের মতো আচরণ করতে পারে যদি একটি লক্ষ্য ভুল থাকে, বিশেষত কাস্টম ডোমেন হোস্টেড অ্যাপ পয়েন্ট করলে।
একটি চূড়ান্ত নিয়ম: ঘড়ি রিসেট করা বন্ধ করুন।
ছোট, শান্ত পরিবর্তন বারবার টুইকিং থেকে ভাল।
আপনি নতুন অ্যাপ লঞ্চ করেছেন এবং example.com ও www.example.com উভয় সেটআপ করেছেন। কয়েক মিনিট পরে www.example.com ভালো লোড করে, কিন্তু রুট ডোমেন DNS এরর দেখায়, পুরোনো সাইট লোড করে, অথবা HTTPS Pending থাকে। এই প্যাটার্ন সাধারণ এবং সাধারণত একটি ছোট কারণে হয়ে থাকে।
শুরু করুন বিরক্তিকর প্রশ্ন দিয়ে: আপনি কি সঠিক জায়গায় DNS এডিট করছেন? যদি আপনার ডোমেন একটি কোম্পানিতে রেজিস্টার করা কিন্তু DNS অন্যত্র হোস্ট করা হয়, আপনি সারাদিন রেকর্ড বদলালেও কিছুই হবে না। প্রথমে nameservers চেক করুন, তারপর ওই nameservers যেই প্রদানকারীকে নির্দেশ করছে তার DNS প্যানেল খুলুন।
পরের ধাপ, দুইটি হোস্টনেম তুলনা করুন। www সাধারণত CNAME হয়। রুট ডোমেন কঠিন: অনেক প্রদানকারী apex-এ CNAME অনুমোদন করে না, তাই সাধারণত A রেকর্ড প্রয়োজন হয় IP-এ, অথবা যদি প্রদানকারী ALIAS/ANAME দিলে সেগুলো ব্যবহার করতে হবে।
একটি কার্যকর সিদ্ধান্ত পথ:
example.com-এ কোনো রেকর্ড নেই (বা কোথাও অন্যত্র পয়েন্ট করছে)? apex রেকর্ড ঠিক করুন।সঠিক শেষ অবস্থা হলো একঘেয়েমি: example.com ও www.example.com উভয় একই অ্যাপের দিকে যায়, একটি ক্যানোনিক্যাল থাকে (অন্যটি রিডাইরেক্ট করে), এবং HTTPS বৈধ।
ডোমেন সেটআপ ব্যর্থ হলে, বেশিরভাগ সমাধান কয়েকটি দ্রুত চেক থেকে আসে। কোনো কিছু বদলানোর আগে এগুলো চালান।
DNS স্পষ্টভাবে সঠিক হলে তারপর SSL চেক করুন। বহু প্ল্যাটফর্ম কেবল তখন সার্টিফিকেট ইস্যু করে যখন তারা আপনার ডোমেনকে ধারাবাহিকভাবে সঠিক টার্গেটে রেজলভ করতে পারে। যদি আপনি অতি তাড়াহুড়ো করে চেক করেন, আপনি স্বাভাবিক দেরিকে ত্রুটি ভেবে ফেলতে পারেন।
আপনি যদি Koder.ai-তে ডিপ্লয় করা অ্যাপে কাস্টম ডোমেন যোগ করে থাকেন, ডোমেন সেটআপ স্ক্রিনকে প্রত্যাশিত টার্গেট হিসেবে নিন, তারপর authoritative DNS-এ ঠিক সেটি মিলিয়ে দিন এবং DNS প্রোপাগেশন সময় পাওয়ার পরে স্ট্যাটাস পুনঃপরীক্ষা করুন।
DNS ও SSL ত্রুটিগুলো পুনরাবৃত্তি না করতে দ্রুত একটি ছোট “ডোমেন সেটআপ নোট” রাখুন। এটি একটি পুনঃব্যবহৃত রানবুক যা আপনি পরেরবার লঞ্চে কপি করে ব্যবহার করতে পারবেন।
এটি আপনার প্রজেক্ট ডকসে রাখুন এবং DNS স্পর্শ করার আগে পূরণ করুন:
লঞ্চের সময়, একজন ব্যক্তি DNS অধিকারী রাখুন। DNS সবচেয়ে বেশি ভেঙে যায় যখন দুজন আলাদা জিনিস “থিক” করছে (উদাহরণ: একজন nameservers বদলাচ্ছে আর অন্যজন রেকর্ড এডিট করছে)।
হোস্টিং পাশে, নিরাপদ রিভার্সের পরিকল্পনা রাখুন। যদি আপনার প্ল্যাটফর্ম স্ন্যাপশট বা রোলব্যাক সমর্থন করে, রাউটিং বদলানোর আগে একটি স্ন্যাপশট নিন যাতে আপনি দ্রুত সর্বশেষ known-good অবস্থায় ফিরে যেতে পারেন। Koder.ai তে আপনি Planning Mode ব্যবহার করে ডোমেন ধাপগুলো লিখে রাখতে পারেন, সেগুলো ধাপে প্রয়োগ করতে পারেন, এবং কোনো পরিবর্তন প্রোডাকশন ভেঙে দিলে রোলব্যাক করতে পারেন।
আপনি যদি DNS নিশ্চিত করে নিয়েও ব্যর্থতা দেখেন, অনুমান করা বন্ধ করে প্রমাণসহ এগিয়ে দিন:
এগিয়ে নেওয়ার সময় হোস্টনেম, প্রত্যাশিত রেকর্ড, বর্তমান রিসলভার রেজাল্ট এবং টাইমস্ট্যাম্প যোগ করুন। এটি ধীর ব্যাক-অ্যান্ড-ফোরটকে দ্রুত ফিক্সে পরিণত করে।
এটি সাধারণত চেইনের এক স্তর ঠিক নেই এমনটাই বোঝায়: DNS রেজলভ হচ্ছে না, DNS ভুল টার্গেটে রেজলভ করছে, সার্ভার/হোস্ট আপনার হোস্টনেম চিনছে না, অথবা HTTPS/SSL এখনও ইস্যু হচ্ছে না। শুরু করুন দেখে নিয়ে যে ঠিক কী এরর দেখা যাচ্ছে এবং আপনি কোন হোস্টনেম টাইপ করছেন (apex বনাম www)।
কারণ example.com (apex) এবং www.example.com আলাদা হোস্টনেম এবং আলাদা DNS রেকর্ড থাকে। বেশিরভাগ সময় www-এর জন্য সঠিক CNAME থাকলেও apex-এ কোনো A রেকর্ড নেই, ভুল A রেকর্ড আছে, অথবা আপনার DNS প্রদানকারী CNAME অনুপযোগী বলে সমস্যা হয়।
রেজিস্ট্রার-এ ডোমেনের nameservers দেখুন এবং সেগুলোকে আপনি যে DNS প্রদানকারীর ড্যাশবোর্ডে এডিট করছেন সেই প্রয়োজ্য প্রদানকারীর সাথে মিলান। সক্রিয় nameservers-এ তালিকাভুক্ত প্রদানকারীই authoritative; অন্য কোথাও রেকর্ড এডিট করলে পাবলিক ইন্টারনেটে কিছুই পরিবর্তন হবে না।
যখন আপনার হোস্ট একটি IPv4 ঠিকানা দেয় তখন A রেকর্ড ব্যবহার করুন, যদি আপনার হোস্ট IPv6 টার্গেট দেয় তখন AAAA ব্যবহার করুন, এবং যখন হোস্ট আপনাকে অন্য একটি হোস্টনেম দেয় তখন CNAME ব্যবহার করুন (সাধারণত www-এর জন্য)। TXT রেকর্ড হলো ভেরিফিকেশন ও চ্যালেঞ্জের জন্য, এবং সেগুলো অবশ্যই আপনার হোস্ট যে নির্দিষ্ট নাম বলেছে সেখানে তৈরি করতে হবে।
একটি স্থবির বা ভুল AAAA রেকর্ড কিছু ব্যবহারকারীকে IPv6-এ পুরানো সার্ভারে পাঠাতে পারে, যখন אחרים IPv4-এ সঠিক সার্ভারে যায়—ফলত: “আমার কাছে কাজ করে” কন্ডিশন। যদি আপনার হোস্ট IPv6 টার্গেট না দিয়ে থাকে, তাহলে ভুল AAAA রেকর্ড মুছে ফেলা সাধারণত সহজ সমাধান।
প্রধানত কারণ আপনি হোস্টিং সাইডে কেবল একটি হোস্টনেম কনফিগার করেছেন (শুধু apex বা শূদু www) অথবা এমন প্রতিযোগিতামূলক রিডাইরেক্ট নিয়ম আছে যা HTTP ও HTTPS বা apex ও www-এর মধ্যে বাউন্স করে। একটি ক্যানোনিক্যাল হোস্টনেম বেছে নিন, দুটো হোস্টনেমই কনফিগার করুন, এবং কেবল একটি পরিষ্কার রিডাইরেক্ট পথ নিশ্চিত করুন।
হ্যাঁ। DNS বহু স্থানে সঠিকভাবে রেজলভ না করলে সার্টিফিকেট প্রদানকারী ডোমেনটি ভেরিফাই করতে পারে না, তাই SSL ইস্যুতে সময় লাগা স্বাভাবিক। DNS কয়েকটি স্থানে ধীরে ধীরে স্থিতিশীল না হওয়া পর্যন্ত SSL সাধারণত ইস্যু হবে না। DNS পরিষ্কারভাবে সঠিক হওয়ার পরে অপেক্ষা করাই সঠিক সিদ্ধান্ত।
TTL হলো কতক্ষণ রেসল্ভার একটি উত্তর ক্যাশে রাখবে—এই সময়কাল শেষ না হলে কেউ কেউ পুরানো মান দেখতে পারে। দুইটি ভিন্ন নেটওয়ার্ক (উদাহরণ: Wi‑Fi ও মোবাইল ডেটা) থেকে টেস্ট করুন এবং DNS বারবার বদলাবেন না যাতে আপনি প্রোপাগেশন পরিষ্কারভাবে পর্যবেক্ষণ করতে পারেন।
dig বা nslookup-এর মতো টুল ব্যবহার করে A/AAAA/CNAME/TXT উত্তরগুলি আপনার প্রত্যাশিত টার্গেটের সাথে মিল করছে কিনা তাও নিশ্চিত করুন, তারপর apex ও www উভয়ের জন্য http:// এবং https:// টেস্ট করুন। যদি এক নেটওয়ার্ক অন্যটির তুলনায় ভিন্ন DNS উত্তর দেখায়, সেটা ক্যাশিং; সব নেটওয়ার্কে ভুল উত্তর দেখা গেলে সেটা কনফিগারেশন ত্রুটি।
Koder.ai-তে, অ্যাপের ডোমেন সেটআপ স্ক্রীনকে প্রত্যাশিত DNS টার্গেটের সূত্র হিসেবে বিবেচনা করুন, তারপর authoritative প্রদানকারীর কাছে ঠিক সেটাই মিলিয়ে দিন। DNS বদলানোর পরে সেটেল হওয়ার জন্য সময় দিন এবং SSL পুনঃপরীক্ষা করুন; লাইভ প্রোজেক্টে রাউটিং বদলালে স্ন্যাপশট/রোলব্যাক ব্যবহার করলে দ্রুত পূর্ববর্তী স্থিতিশীল অবস্থা ফিরে যাওয়া যায়।