DNS Propagation কত সময় নেয় এবং সমস্যা হলে করণীয়

আপনি হয়তো hosting বদলেছেন, domain এর DNS record আপডেট করেছেন, বা nameserver পরিবর্তন করেছেন। কিন্তু কয়েক ঘণ্টা পেরিয়ে গেলেও ওয়েবসাইট আগের জায়গায় দেখাচ্ছে, নতুন সার্ভারে যাচ্ছে না, কখনও যাচ্ছে কখনও যাচ্ছে না। বাংলাদেশে এই ঝামেলাটা আরও বেশি চোখে পড়ে, কারণ অনেক সময় ISP বা মোবাইল নেটওয়ার্কের cache জেদ করে বসে থাকে।

এটাই মূলত DNS Propagation। নাম শুনলে মনে হয় “ইন্টারনেট জুড়ে আপডেট ছড়িয়ে পড়ছে”, কিন্তু বাস্তবে বেশিরভাগ সময় দেরি হয় cache এর কারণে। নিচে সহজ ভাষায় বুঝিয়ে দিচ্ছি, সাধারণভাবে কত সময় লাগে, কোন কোন কারণে সময় বাড়ে, আর সমস্যা হলে ধাপে ধাপে কী করবেন।

DNS Propagation কী এবং কেন সময় লাগে

DNS কে ভাবুন ইন্টারনেটের “ঠিকানা বই”। আপনি যখন banglageek.com টাইপ করেন, তখন DNS ঠিক করে দেয় এই domain কোন IP address এ যাবে। আপনি DNS এ পরিবর্তন করলে (যেমন A record নতুন IP করা), পরিবর্তনটা আপনার DNS provider এর দিক থেকে প্রায় সঙ্গে সঙ্গেই সেভ হয়। তবুও সবার কাছে সাথে সাথে নতুন তথ্য পৌঁছায় না, কারণ মাঝখানে থাকে DNS cache।

এই cache কাজটা করে কয়েক জায়গায়:

• আপনার ISP (যেমন বাসার ব্রডব্যান্ড বা মোবাইল নেটওয়ার্ক)
• বিভিন্ন DNS resolver (যারা আপনার হয়ে DNS খোঁজে)
• আপনার ডিভাইসের Operating System cache
• কখনও কখনও ব্রাউজার বা অ্যাপের নিজস্ব cache

আরেকটা গুরুত্বপূর্ণ বিষয় হলো TTL। TTL মানে একটা DNS record কতক্ষণ পর্যন্ত cache এ রাখা যাবে। TTL যত বেশি, record তত বেশি সময় পুরোনো তথ্য দেখাতে পারে। Cloudflare এর DNS ডকুমেন্টেশনেও TTL কে এমন ফিল্ড হিসেবে বলা হয়েছে যা ঠিক করে দেয় কতক্ষণ record cache হবে এবং ফলে আপডেট end user পর্যন্ত যেতে কতটা সময় লাগবে। 

টেকনিক্যালভাবে TTL হলো এমন একটা সময় (সেকেন্ডে) যতক্ষণ একটি record cache করা “allowed”। এই ধারণাটা DNS স্ট্যান্ডার্ড RFC 1035 এও ব্যাখ্যা করা আছে। 

ছোট করে বললে: DNS বদলালেন, কিন্তু পুরোনো DNS তথ্য অনেক জায়গায় cache হয়ে থাকায় সবাই একই সাথে নতুন তথ্য পায় না।

সাধারণভাবে DNS Propagation কত সময় লাগে

সব পরিস্থিতিতে একই সময় লাগে না। তবে বাস্তব ব্যবহারে একটা সাধারণ ধারণা আছে:

• বেশিরভাগ DNS পরিবর্তন কয়েক মিনিট থেকে কয়েক ঘণ্টার মধ্যে অনেক জায়গায় দেখা যায়
• “ফুল propagation” বলতে সবাই নতুনটা দেখবে, এই পর্যায়ে যেতে সর্বোচ্চ ৪৮ ঘণ্টা লাগতে পারে

GoDaddy তাদের সাপোর্ট ডকুমেন্টেশনে বলে যে DNS পরিবর্তন সাধারণত কয়েক ঘণ্টার মধ্যে ছড়িয়ে পড়ে, তবে সর্বোচ্চ 48 hours লাগতে পারে। তারা TTL, ISP caching, registry ইত্যাদিকে প্রভাবক হিসেবে উল্লেখ করেছে। 
আর মজার ব্যাপার, কিছু ISP TTL মানে না এবং তাদের cache ২ থেকে ৩ দিন পরপর আপডেট করতে পারে বলেও একই ডকে উল্লেখ আছে। 

কোন পরিবর্তনে অপেক্ষা বেশি হতে পারে

• Nameserver change (domain এর NS বদলানো): registry আপডেট, বিভিন্ন জায়গার cache, সব মিলিয়ে বেশি সময় লাগতে পারে
• A record / CNAME বদলানো: TTL কম হলে তুলনামূলক দ্রুত দেখা যায়
• MX record (ইমেইল): ভুল হলে ইমেইল ডেলিভারি সমস্যা হতে পারে, তাই এখানে সতর্ক থাকা জরুরি

বাংলাদেশি বাস্তবতায়: আপনি ঢাকায় বসে মোবাইলে নতুন site দেখছেন, কিন্তু কুমিল্লা বা চট্টগ্রামের ক্লায়েন্টের নেটে এখনও পুরোনো site দেখাচ্ছে, এটা খুবই সাধারণ ঘটনা।

সময় বাড়ায় কমায় যেসব বিষয়

DNS Propagation দ্রুত বা ধীর হওয়ার পেছনে কয়েকটা বাস্তব কারণ কাজ করে।

TTL বেশি সেট করা থাকলে
TTL যত বেশি, পুরোনো তথ্য তত বেশি সময় cache এ থাকবে। ফলে আপডেট দেখতে দেরি। TTL কীভাবে cache time কে নিয়ন্ত্রণ করে, সেটা Cloudflare স্পষ্টভাবে ব্যাখ্যা করেছে। 

ISP বা নেটওয়ার্কের cache
অনেক ISP ব্রাউজিং দ্রুত করতে DNS cache রাখে। এতে স্পিড বাড়ে, কিন্তু DNS পরিবর্তন দেখাতে দেরি হতে পারে। GoDaddy এটার কথাও বলেছে এবং জানিয়েছে কিছু ISP TTL ignore করতে পারে। 

Negative Cache
অনেক সময় আপনি নতুন সাবডোমেইন বানালেন, যেমন shop.yourdomain.com, প্রথমে DNS এ record ছিল না। কিছু resolver “এই নামটা নেই” এই তথ্যও cache করে রাখে। এটাকে negative caching বলা হয়। DNS স্ট্যান্ডার্ডে negative caching এর ধারণা RFC 2308 এ ব্যাখ্যা করা আছে। 
ফলে আপনি record যোগ করার পরও কিছু জায়গায় কিছুক্ষণ “Not found” দেখা দিতে পারে।

একসাথে অনেক পরিবর্তন করা
একই সময়ে nameserver বদলানো, A record বদলানো, আবার CDN সেটআপ, আবার ইমেইল সেটআপ করলে সমস্যা isolate করা কঠিন হয়। বাংলাদেশে অনেকেই তাড়াহুড়া করে “একটা কাজ হচ্ছে না” দেখে আবার নতুন করে পরিবর্তন করে ফেলেন, এতে propagation reset না হলেও confusion বেড়ে যায়।

কীভাবে দ্রুত বুঝবেন কোন জায়গায় আটকে আছে

DNS সমস্যায় “অন্ধভাবে অপেক্ষা” করার বদলে একটু স্মার্টভাবে যাচাই করলে অর্ধেক টেনশন কমে যায়।

আপনি যেটা নিশ্চিত করবেন প্রথমে

• DNS provider/registrar প্যানেলে record ঠিক আছে কি না
• ভুল record টাইপ সেট করেছেন কি না (A vs CNAME vs TXT)
• একই নামের জন্য ডুপ্লিকেট conflict আছে কি না (একই host এ একাধিক A record, ভুল priority ইত্যাদি)

Authoritative vs Resolver ভিউ আলাদা করে দেখুন

• আপনার DNS provider যে value দেখাচ্ছে, সেটাই authoritative সত্য
• কিন্তু আপনার ISP বা পাবলিক resolver পুরোনোটা দেখালে আপনি পুরোনোটা পাবেন

টুল দিয়ে চেক করার সহজ উপায়

• অনলাইন DNS propagation checker ব্যবহার করুন। এগুলো বিভিন্ন দেশের resolver থেকে আপনার domain query করে দেখায় কার কাছে কোন record আছে। (উদাহরণ হিসেবে NetworkingToolbox “DNS Propagation Checker” টাইপ টুলগুলো এভাবেই কাজ করে বলে তারা উল্লেখ করেছে।) 
• আপনার নিজের নেটওয়ার্ক বদলে চেক করুন:
  • বাসার Wi‑Fi বনাম মোবাইল ডেটা
  • VPN অন করে একবার, বন্ধ করে একবার

ক্লায়েন্ট/টিমকে কীভাবে বুঝাবেন
একটা কাজ করেন: বলুন “আপনার নেটওয়ার্কে cache আছে, আপনি মোবাইল ডেটা দিয়ে একবার দেখেন।” বাংলাদেশে এইটা খুব practical। অনেক সময় এতে সঙ্গে সঙ্গেই বোঝা যায় যে সার্ভার ঠিক আছে, সমস্যা শুধু cache।

সমস্যা হলে করণীয়: ধাপে ধাপে ট্রাবলশুটিং

এখানে লক্ষ্য হচ্ছে, কম ঝুঁকিতে দ্রুত root cause বের করা।

সঠিক সময়টা অপেক্ষা করুন, কিন্তু অন্ধভাবে না
TTL যদি ১ ঘণ্টা সেট করা থাকে, আপনি ৫ মিনিটে ফল পাবেন আশা করা ঠিক না। TTL large হলে সময় লাগবেই। TTL কমানো হলে পরিবর্তন তুলনামূলক দ্রুত ছড়ায়। 

DNS record গুলো পরিষ্কার করুন

• একই host এর জন্য পুরোনো A record রেখে নতুন A record যোগ করলে অনেক সময় “কখনও পুরোনো, কখনও নতুন” দেখা যায়
• www আর root domain আলাদা ভাবে সেট করা আছে কি না দেখুন
• CNAME এর সাথে একই host এ A record একসাথে দিয়ে ফেলেছেন কি না চেক করুন

Nameserver সত্যি বদলেছে কি না নিশ্চিত করুন
কিছু ক্ষেত্রে আপনি nameserver সেভ করেছেন মনে করছেন, কিন্তু registrar এ pending বা verify দরকার হতে পারে। Nameserver change হলে registry update লাগে, এবং এতে কয়েক ঘণ্টা থেকে 48 hours পর্যন্ত লাগতে পারে বলে GoDaddy বলছে। 

Local DNS Cache Flush করুন
আপনি নিজের ডিভাইসে পুরোনো cache নিয়ে বসে থাকলে, আপনার কাছে কখনও update দেখা যাবে না।

• Windows: Command Prompt খুলে চালান: ipconfig /flushdns
  Microsoft এর ডক অনুযায়ী /flushdns DNS client resolver cache “flush and reset” করে এবং troubleshooting এর সময় negative cache entry বাদ দিতে সাহায্য করে। 
• Mac: macOS এ dscacheutil -flushcache কমান্ডটি cache flush করার জন্য পরিচিত (এটা man page আর্কাইভেও দেখা যায়)। 
  নোট: macOS ভার্সনভেদে কমান্ডে সামান্য পার্থক্য থাকতে পারে।
• Router restart: অনেক বাসার রাউটারও DNS cache ধরে রাখতে পারে। একবার restart দিলে অনেক সময় সমস্যা কাটে।

অস্থায়ীভাবে অন্য DNS Resolver ব্যবহার করুন
বাংলাদেশে কিছু ISP caching aggressive হলে আপনি সাময়িকভাবে পাবলিক DNS resolver দিয়ে চেক করতে পারেন।

• Google Public DNS: 8.8.8.8 এবং 8.8.4.4 ব্যবহার করার কথা Google তাদের ডকুমেন্টেশনে উল্লেখ করেছে। 
• Cloudflare 1.1.1.1: Cloudflare এর পাবলিক DNS resolver হিসেবে 1.1.1.1 সুপরিচিত, এবং তাদের ডকে এটা ব্যাখ্যা করা আছে। 

এটা “propagation speed up” করে না, কিন্তু আপনার ISP যদি পুরোনো record ধরে রাখে, তখন নতুন record দেখার জন্য workaround হিসেবে কাজ করে।

Negative Cache মাথায় রাখুন
নতুন সাবডোমেইন বা নতুন record যোগ করার পরও কিছু জায়গায় cached “নেই” উত্তর থেকে যেতে পারে। DNS এ negative caching ধারণাটা RFC 2308 এ বিস্তারিত আছে। 
এই ক্ষেত্রে record ঠিক থাকলে সাধারণত সময় দিলেই ঠিক হয়, আর local cache flush করলে দ্রুত বোঝা যায়।

HTTPS/SSL এর কারণে বিভ্রান্ত হবেন না
DNS ঠিক হয়ে গেছে, কিন্তু ব্রাউজারে এখনও “Not secure”, “certificate mismatch” বা redirect loop দেখাচ্ছে। অনেক সময় DNS ঠিক হলেও সার্ভার কনফিগ, SSL, বা CDN cache আলাদা ইস্যু হতে পারে। DNS propagation কে দোষ দিয়ে বসে না থেকে “DNS ঠিক আছে কি না” আলাদা করে verify করুন।

কখন সাহায্য নেবেন

• 48 hours পেরিয়ে গেছে, তবুও একাধিক নেটওয়ার্ক এবং একাধিক resolver এ একই ভুল দেখাচ্ছে
• nameserver/record ঠিক আছে, তবুও email delivery বা site access বড়ভাবে ভাঙা
• DNSSEC, CDN, বা complex সেটআপ আছে এবং আপনি নিশ্চিত না

এই অবস্থায় আপনার DNS provider, hosting support, বা domain registrar support এ টিকিট করা সবচেয়ে ভাল।

পরিবর্তনের আগে প্রস্তুতি: পরে ঝামেলা কমবে

DNS সমস্যা কমানোর সবচেয়ে ভাল কৌশল হলো পরিবর্তনের আগে একটু প্রস্তুতি।

TTL আগেই কমিয়ে নিন
আপনি যদি জানেন আগামীকাল migration করবেন, তাহলে আজই গুরুত্বপূর্ণ record গুলোর TTL কমিয়ে রাখুন (যেমন 300 বা 600 seconds)। TTL কম হলে cache দ্রুত expire হয়, আপডেট দ্রুত দেখা যায়। 
মনে রাখবেন, TTL খুব কম রাখলে nameserver এ query বাড়তে পারে, তাই কাজ শেষ হলে আবার reasonable TTL এ ফিরিয়ে দিন।

পুরোনো hosting কিছুক্ষণ চালু রাখুন
বাংলাদেশে অনেকেই migration করে পুরোনো hosting সাথে সাথে বন্ধ করে দেন। যখন অর্ধেক visitor পুরোনো DNS cache নিয়ে পুরোনো hosting এ যাচ্ছে, তখন তারা “site down” দেখছে। নিরাপদ পথ হলো কমপক্ষে 24-48 hours overlap রাখা।

একসাথে অনেক পরিবর্তন নয়
আগে DNS ঠিক করুন, তারপর CDN/SSL, তারপর ইমেইল। ধাপে করলে সমস্যা diagnose করা সহজ হয়।

উপসংহার

DNS Propagation আসলে “সময় নষ্ট” না, এটা DNS caching এর স্বাভাবিক ফল। বেশিরভাগ ক্ষেত্রে কয়েক ঘণ্টার মধ্যে অনেক জায়গায় আপডেট দেখা যায়, তবে কিছু পরিস্থিতিতে 48 hours পর্যন্ত সময় লাগতে পারে। 

আপনি যদি record ঠিক আছে কি না যাচাই করেন, একাধিক নেটওয়ার্ক থেকে চেক করেন, প্রয়োজন হলে DNS cache flush করেন এবং সাময়িকভাবে Google Public DNS বা Cloudflare 1.1.1.1 দিয়ে যাচাই করেন, তাহলে ৯০% DNS propagation সমস্যা নিজেরই ধরতে পারবেন। 

সাধারণ জিজ্ঞাসা