DNS: Internet-এর Phonebook

এই Lesson শেষে তুমি পারবে

• DNS কেন দরকার তা ব্যাখ্যা করতে, এবং যেকোনো Domain Name-কে DNS Tree-এর একটি পথ হিসেবে পড়তে।
• চার ধরনের DNS Server-এর নাম বলতে, এবং প্রতিটি ঠিক কী জানে ও কী উত্তর দেয় তা বলতে।
• একটি পূর্ণ Lookup ধাপে ধাপে বর্ণনা করতে, এবং শর্টকাট (Cache Hit) ও ব্যর্থতা (NXDOMAIN, Timeout, SERVFAIL) চিনতে।
• সঠিক Record Type বেছে নিতে: A, AAAA, CNAME, MX, TXT, NS, সঙ্গে PTR ও SOA।
• ভেবেচিন্তে TTL ব্যবহার করতে: Caching স্তর, নিরাপদে IP পরিবর্তন, এবং কেন “DNS Propagation” আসলে Cache-এর মেয়াদ শেষ হওয়া।
• DoH/DoT ও DNSSEC ব্যাখ্যা করতে, এবং System Designer-রা কীভাবে Geo-routing ও Failover-এর জন্য DNS ব্যবহার করে তা বলতে।
• Split-horizon (Private) DNS সাজাতে, যেখানে একই নামের উত্তর Network-এর ভেতরে আর বাইরে আলাদা, আর Cache-এর ফাঁদে না পড়ে DNS দিয়ে Service Discovery করতে।

#DNS কেন দরকার

Network-এ কম্পিউটারগুলো একে অপরকে চেনে IP Address দিয়ে, যেমন 142.250.190.46 (IPv4) বা 2001:db8::1 (IPv6)। Router গন্তব্যের IP দেখে Packet পাঠায়; “google.com” মানে কী, Router তা জানেই না।

অন্যদিকে মানুষের পক্ষে হাজার হাজার সংখ্যার সারি মনে রাখা অসম্ভব। Domain Name System (DNS) এই সমস্যার সমাধান করে: মানুষের সহজবোধ্য নাম, যেমন google.com, কে কম্পিউটারের প্রয়োজনীয় IP Address-এ রূপান্তর করে। এজন্যই DNS-কে বলা হয় Internet-এর Phonebook।

DNS শুধু নাম থেকে IP-ই দেয় না:

• একটি নামের অনেক Address থাকতে পারে। বড় সাইটগুলো চাপ ভাগ করতে ও ব্যবহারকারীকে কাছের Data Centre-এ পাঠাতে ভিন্ন ভিন্ন ব্যবহারকারীকে ভিন্ন IP দেয়।
• কেউ টের না পেয়েই Address বদলানো যায়। কোনো প্রতিষ্ঠান Website নতুন Server-এ সরালে শুধু DNS আপডেট করে, ব্যবহারকারী আগের নামই লিখতে থাকে।
• একটি নামে অন্য তথ্যও থাকে: কোন Server ওই Domain-এর Email গ্রহণ করে (MX), ডাকনাম বা Alias (CNAME), মালিকানার প্রমাণ ও Email-নিরাপত্তার নিয়ম (TXT), আরও অনেক কিছু।

#Domain Name পড়া: DNS Tree

DNS কোনো একটি কম্পিউটারে রাখা বিশাল তালিকা নয়। এটি একটি হায়ারার্কিক্যাল (পদানুক্রমিক) ব্যবস্থা, একটি উল্টো Tree, আর প্রতিটি Domain Name সেই Tree-এর একটি পথ, যা ডান থেকে বামে পড়তে হয়।

ধরো www.example.com. (শেষের বিন্দুটি সাধারণত দেখা যায় না, কিন্তু আসলে থাকে):

Root পর্যন্ত সম্পূর্ণ লেখা নাম, যেমন www.example.com., কে বলে Fully Qualified Domain Name (FQDN)।

TLD প্রধানত দুই ধরনের:

• gTLD (Generic): .com, .org, .net, .dev, .app…
• ccTLD (Country Code): .bd, .uk, .in। অনেক দেশ নিজেদের দ্বিতীয় স্তরও রাখে, তাই বাংলাদেশি একটি প্রতিষ্ঠানের ঠিকানা হতে পারে shop.com.bd।

#চার ধরনের DNS Server

একটি Lookup চার ধরনের Server মিলে সম্পন্ন করে। প্রত্যেকে Tree-এর শুধু নিজের অংশটুকু জানে।

1. ১. Recursive Resolver: যে সহকারী পুরো কাজটা করে

   তোমার ডিভাইস প্রশ্নটি একটি Recursive Resolver-কে পাঠিয়ে অপেক্ষা করে। খোঁজাখুঁজির পুরো দায়িত্ব Resolver-এর: সে বাকি তিন ধরনের Server-এর কাছে একে একে যায়, চূড়ান্ত IP Address সংগ্রহ করে ফেরত দেয়। সে সাম্প্রতিক উত্তরের একটি বড় Cache-ও রাখে।

   সাধারণত এটি হয় তোমার ISP-এর Resolver (Link3, Grameenphone…), যা DHCP স্বয়ংক্রিয়ভাবে তোমার ডিভাইসকে দেয়। অনেকে এর বদলে Public Resolver ব্যবহার করে: Google 8.8.8.8, Cloudflare 1.1.1.1 বা Quad9 9.9.9.9।

   তোমার অপারেটিং সিস্টেমে একটি ছোট সহকারী আছে, যাকে বলে Stub Resolver। সে নিজে Tree ধরে হাঁটতে পারে না; শুধু প্রশ্ন Recursive Resolver-এ পাঠায় আর উত্তর Cache করে।

2. ২. Root Name Server: প্রধান ডিরেক্টরি

   Root Server পদানুক্রমের শীর্ষবিন্দুতে। এরা কোনো Website-এর IP জানে না। এরা শুধু একটি জিনিস জানে: প্রতিটি TLD-এর (.com, .org, .bd…) দায়িত্বে কোন Server।

   বিশ্বে ১৩টি নামের Root Server পরিচয় আছে, a.root-servers.net থেকে m.root-servers.net পর্যন্ত, যা ১২টি প্রতিষ্ঠান পরিচালনা করে। প্রতিটি পরিচয় একটি মেশিন নয়: Anycast-এর কারণে একই IP Address অনেক স্থান থেকে ঘোষণা করা হয়, ফলে বিশ্বজুড়ে হাজারেরও বেশি Root Server Instance আছে, বাংলাদেশেও। তোমার Query সবচেয়ে কাছেরটিতে যায়।

3. ৩. TLD Name Server: বিশেষায়িত বিভাগ

   প্রতিটি TLD-এর নিজস্ব Server আছে। .com TLD Server প্রতিটি .com Domain-এর জন্য জানে মালিক কোন Authoritative Name Server নিবন্ধন করেছে। Website-এর IP তারা তখনও জানে না।

4. ৪. Authoritative Name Server: মূল রেকর্ড বই

   এটি শেষ ধাপ। কোনো Domain-এর Authoritative Server (যেমন ns1.example.com, অথবা Cloudflare তোমার DNS Host হলে তাদের Server) আসল Record ধারণ করে: A, AAAA, MX, TXT ইত্যাদি। এর উত্তরই চূড়ান্ত ও নির্ভুল, তাই একে বলে Authoritative। অন্য সব Server শুধু এই উত্তর পুনরাবৃত্তি বা Cache করে।

   প্রতিটি Domain-এর সাধারণত অন্তত দুটি Authoritative Server থাকে, আলাদা Network-এ, যাতে একটি বিকল হলে Domain অফলাইন না হয়।

#একটি সম্পূর্ণ Lookup, ধাপে ধাপে

তুমি example.com লিখে Enter চাপার পরের কয়েক Millisecond-এ এটাই ঘটে। প্রতিটি পরিস্থিতি Play করে দেখো: প্রথমটি পুরো যাত্রা, বাকিগুলো প্রতিদিন যেসব ভিন্নতা দেখা যায়।

খোঁজাখুঁজি সবসময় নিজের ঘর থেকেই শুরু হয়। পুরো ব্যাপারটা দুই ভাগে ভাবলে সহজ: প্রথমে Local Cache-এর যাত্রা (Browser, অপারেটিং সিস্টেম, বাসার Router, তারপর Recursive Resolver-এর Cache), যেখানেই বেশিরভাগ Lookup-এর উত্তর মিলে যায়; আর তারপর Global Search (Root → TLD → Authoritative), যা লাগে শুধু তখন, যখন পথের কোনো Cache-এ টাটকা কপি নেই। ফেরার পথে উত্তরটা যত Cache পেরোয়, সবখানে জমা হয়, যতক্ষণ তার TTL অনুমতি দেয়।

Cold Cache-এর ক্ষেত্রে কথায় বললে:

1. User Request: তুমি Browser-এ example.com লেখো।
2. Local Cache Check: Browser নিজের DNS Cache দেখে, তারপর অপারেটিং সিস্টেম নিজের Cache ও hosts File দেখে। কিছু না পেলে OS প্রশ্নটি Recursive Resolver-এ পাঠায়।
3. Root Server-এ Query: Resolver জানতে চায়: “example.com কোথায় পাব?”
4. Root-এর উত্তর: “আমি example.com চিনি না, তবে .com TLD Server-এর ঠিকানা জানি, সেখানে যোগাযোগ করো।” এ ধরনের উত্তরকে বলে Referral।
5. TLD Server-এ Query: Resolver একটি .com Server-কে জিজ্ঞেস করে।
6. TLD-এর উত্তর: “IP আমার কাছে নেই, তবে example.com-এর Authoritative Name Server হলো ns1/ns2.example.com। তাদের দরজায় নক করো।”
7. Authoritative Server-এ Query: Resolver ns1.example.com-কে জিজ্ঞেস করে।
8. চূড়ান্ত উত্তর: “example.com-এর IPv4 Address হলো 203.0.113.10, আর তুমি এটি ৩৬০০ সেকেন্ড Cache রাখতে পারো।”
9. Caching ও Delivery: Resolver উত্তরটি নিজের Cache-এ রেখে তোমার ডিভাইসে ফেরত দেয়, ডিভাইসও Cache করে। এবার Browser ঐ IP-তে HTTP/HTTPS Connection খুলে Page লোড করে।

#Recursive বনাম Iterative Query

ওই প্রবাহে দুই ধরনের প্রশ্ন আলাদাভাবে আচরণ করে:

• Recursive Query (তোমার ডিভাইস → Resolver): “যা-ই লাগুক, আমাকে চূড়ান্ত উত্তর এনে দাও।” Resolver-কে হয় উত্তর, নয়তো Error ফেরত দিতেই হবে।
• Iterative Query (Resolver → Root, TLD, Authoritative): “তুমি যা জানো তা বলো।” প্রতিটি Server নিজের জ্ঞান থেকে উত্তর দেয়: হয় উত্তর, নয়তো আরও কাছের Server-এর Referral। Resolver নিজেই Referral অনুসরণ করে।

#DNS কীভাবে Network-এ চলে

• সাধারণ DNS ব্যবহার করে UDP Port 53: একটি ছোট প্রশ্নের Packet, একটি উত্তরের Packet, কোনো Handshake নেই। তাই এটি খুব দ্রুত।
• উত্তর একটি UDP Packet-এর জন্য বেশি বড় হলে (DNSSEC-এ প্রায়ই হয়), Server একটি “Truncated” Flag দেয় এবং Resolver TCP Port 53-এ আবার চেষ্টা করে। Server-গুলোর মধ্যে পুরো Zone কপি করা (Zone Transfer) সবসময় TCP-তে হয়।
• UDP-তে কোনো Connection নেই, তাই হারানো Packet-এর কোনো উত্তরই আসে না। Resolver এটি সামলায় Timeout ও Retry দিয়ে, প্রায়ই অন্য একটি Name Server-এ।

#DNS Record Type

DNS Server-এ কেবল IP Address রাখা হয় না। প্রতিটি তথ্য একটি Record, যার একটি Type, নাম, মান ও TTL থাকে।

কয়েকটি নিয়ম যা প্রায়ই ভুল হয়:

• একই নামে CNAME-এর পাশে অন্য কোনো Record থাকতে পারে না। তাই মূল Domain-এ (example.com, যাকে Zone Apex বলে) CNAME দেওয়া যায় না, কারণ সেখানে NS ও SOA Record থাকতেই হয়। অনেক DNS Host এর বিকল্প দেয়: ALIAS, ANAME বা “CNAME Flattening”।
• MX ও CNAME-এর মান নাম, IP নয়। প্রেরককে এরপর Mail Server-এর A/AAAA Record খুঁজতে হয়।
• একটি নামের একই Type-এর একাধিক Record থাকতে পারে, যেমন চাপ ভাগ করতে দুটি A Record, বা Backup-এর জন্য দুটি MX Record।

এখানে একটি MX Record কাজ করছে, মূল Mail Server বন্ধ থাকলে কী হয় তা-সহ:

#TTL ও Caching

প্রতিবার Website-এ ঢুকতে যদি বিশ্বজুড়ে চারটি Server ঘুরতে হতো, Internet ধীর হয়ে যেত এবং Authoritative Server-এর ওপর প্রচণ্ড চাপ পড়ত। সমাধান হলো Caching, যা নিয়ন্ত্রণ করে TTL।

#TTL মানে কী

TTL (Time To Live) হলো প্রতিটি DNS Record-এর সঙ্গে জুড়ে দেওয়া সেকেন্ডের একটি সংখ্যা। এটি Resolver ও Browser-কে বলে: “এই Record তুমি এতক্ষণ Cache-এ রাখতে পারো।”

কোনো Record-এর TTL = 3600 হলে প্রতিটি Browser ও Resolver এটি ১ ঘণ্টা Cache করতে পারে। এরপর কপিটি মুছে যায়, আর পরের Request Authoritative Server থেকে নতুন করে আনে।

সাধারণ মান:

Resolver বাকি থাকা TTL দেয়। ২০ মিনিট আগে TTL ৩৬০০ দিয়ে Cache করলে সে তোমাকে বলবে TTL 2400, ফলে পরের প্রতিটি Cache একই মুহূর্তে মেয়াদোত্তীর্ণ হয়।

#DNS Cache-এর চারটি স্তর

উত্তর চারটি স্তরে Cache হয়, এবং যে স্তরে প্রথম বৈধ কপি পাওয়া যায় Lookup সেখানেই থামে:

1. Browser Cache: Chrome, Firefox সম্প্রতি ভিজিট করা নামগুলো অল্প সময় মনে রাখে।
2. OS Cache ও hosts File: Browser-এ না পেলে অপারেটিং সিস্টেম তার Memory ও hosts File দেখে; hosts File হলো একটি Local Text File, যেখানে লেখা নামগুলোর ক্ষেত্রে এটি DNS-কে পাশ কাটিয়ে যায়।
3. Router Cache: অনেক বাসার Wi-Fi Router একটা ছোট DNS Forwarder হিসেবে কাজ করে: DHCP তোমার ডিভাইসগুলোকে বলে দেয় Router-কেই DNS Server হিসেবে ব্যবহার করতে, আর Router Network-এর সব ডিভাইসের জন্য উত্তর Cache করে। যে Router শুধু ISP-এর Resolver-এর Address বিলিয়ে দেয়, সে কিছুই Cache করে না।
4. ISP / Resolver Cache: তোমার Recursive Resolver-এ (সাধারণত ISP-এর, আর তুমি বদলে থাকলে 1.1.1.1-এর মতো কোনো Public Resolver) হাজারো গ্রাহকের জন্য শেয়ার করা বিশাল Cache থাকে, তাই জনপ্রিয় নামগুলো প্রায় সবসময় আগে থেকেই থাকে।

#নিরাপদে Record বদলানো

শেষ পয়েন্টটিই TTL নিয়ে সবচেয়ে কাজের কথা। কোনো সাইট নতুন Server-এ সরলে কী হয় দেখো, ভুলভাবে ও সঠিকভাবে:

কোনো Service নতুন IP-তে সরানোর নিরাপদ পদ্ধতি:

1. আগেভাগে TTL কমাও, যেমন ৮৬৪০০ থেকে ৩০০, IP পুরনোটাই রেখে।
2. অন্তত পুরনো TTL পরিমাণ সময় অপেক্ষা করো, যাতে প্রতিটি Cache ছোট TTL-টি পায়।
3. Record নতুন IP-তে বদলাও। প্রায় ৫ মিনিটের মধ্যে সবাই অনুসরণ করবে।
4. পুরনো Server কিছুক্ষণ চালু রাখো পিছিয়ে থাকাদের জন্য, তারপর TTL আবার বাড়াও।

#Negative Caching

“পাওয়া যায়নি” উত্তরও Cache হয়। কোনো নামের অস্তিত্ব না থাকলে Server NXDOMAIN ফেরত দেয়, আর Resolver উত্তরটি Zone-এর SOA Record-এ দেওয়া সময় পর্যন্ত Cache রাখে। তাই কেউ (বা তুমি) কোনো Subdomain খোঁজার ঠিক পরে সেটি তৈরি করলে, Negative Cache শেষ না হওয়া পর্যন্ত মানুষ “নেই” উত্তর পেতে পারে।

#DNS-এর নিরাপত্তা ও গোপনীয়তা

DNS ১৯৮০-এর দশকে কোনো নিরাপত্তা ছাড়াই তৈরি হয়েছিল। তিনটি সমস্যা ও তাদের সমাধান:

#System Design-এ DNS

যেহেতু প্রতিটি Client Connect করার আগে DNS-কে জিজ্ঞেস করে, তাই বড় System-এ Traffic নিয়ন্ত্রণের একদম প্রথম জায়গা হলো DNS।

• Geo / Latency-based Routing (GeoDNS): প্রত্যেক ব্যবহারকারীকে সবচেয়ে কাছের বা দ্রুততম Region-এর IP দিয়ে উত্তর দেওয়া। AWS Route 53, Cloudflare-এর মতো Service এটি করে।
• Health-checked Failover: Health Check-এ ব্যর্থ Region-এর IP দেওয়া বন্ধ করা। এর জন্য ছোট TTL দরকার, কারণ পুরনো উত্তর রাখা Client মেয়াদ শেষ না হওয়া পর্যন্ত সেটিই ব্যবহার করবে।
• Round-robin DNS: একটি নামের জন্য একাধিক A Record, প্রতিটি উত্তরে ক্রম ঘুরিয়ে। এটি সস্তা কিন্তু অন্ধ: Load বোঝে না, আর Health Check ছাড়া বিকল Server-ও ফেরত দিতে থাকে। সাধারণত DNS একটি Load Balancer-কে নির্দেশ করে, আর Load Balancer Traffic ভাগ করে।
• Anycast: একই IP অনেক স্থান থেকে ঘোষণা করা (Root Server, 1.1.1.1 ও CDN এভাবেই কাজ করে), ফলে Routing নিজেই ব্যবহারকারীকে সবচেয়ে কাছের সাইটে পৌঁছে দেয়।
• DNS একটি নির্ভরতা: তোমার DNS Provider বন্ধ হলে পুরোপুরি সুস্থ Server-ও নাম দিয়ে পৌঁছানোর অযোগ্য হয়ে যায়। এজন্য বড় প্রতিষ্ঠানগুলো দুটি DNS Provider ব্যবহার করে।

#Split-horizon আর Private DNS

অনেক সময় একটা নামের মানে হওয়া উচিত দুই রকম, কে জিজ্ঞেস করছে তার ওপর নির্ভর করে। অফিস বা Cloud Network-এর ভেতরে app.example.com হওয়া উচিত Private Address 10.0.1.20; Internet-এ সেটা হওয়া উচিত Public Load Balancer 203.0.113.10। আর db.internal.example.com-এর মতো নাম থাকা উচিত শুধু ভেতরেই। একেই বলে Split-horizon DNS (Split-brain বা Split DNS নামেও চলে): একই Zone দুটো View হিসেবে রাখা হয়, আর উত্তর নির্ভর করে তুমি কোন Resolver-কে জিজ্ঞেস করছ তার ওপর।

প্রতিষ্ঠানগুলো কেন এটা করে:

• ভেতরের Client ছোট, Private পথে যায়: মাঝে NAT নেই, Public Address ঘুরে আসা Hairpinning নেই (Lesson 1.7), Load Balancer বা বাইরে যাওয়ার খরচও নেই।
• ভেতরের নাম ভেতরেই থাকে: বাইরের কেউ জানতেই পারে না ভেতরে কোন কোন Host আছে।
• Public Zone ছোট থাকে: Internet-এর যা দরকার শুধু সেটুকু।

কীভাবে বানানো হয়:

• নিজের Data Center-এ: ভেতরের DNS Server (যেমন Windows Active Directory-র সঙ্গে আসা DNS) রাখে ভেতরের কপি; Public DNS Host রাখে বাইরের কপি। অনেক DNS Server নিজেই দুটো View চালাতে পারে, Client-এর Address দেখে কোনটা দেবে ঠিক করে।
• Cloud-এ: একটা Private Hosted Zone (AWS Route 53, Google Cloud DNS, Azure Private DNS) এক বা একাধিক VPC-র সঙ্গে জুড়ে দেওয়া হয়। প্রতিটা VPC-তে একটা নিজস্ব VPC Resolver থাকে (AWS-এ Network-এর Base Address যোগ দুই, যেমন 10.0.0.2), যে আগে Private Zone থেকে উত্তর দেয়, না পেলে Public DNS থেকে। Cloud Service-এর Private Endpoint-ও একই কৌশলে চলে: Service-এর চেনা নামটাই তোমার VPC-র ভেতরে একটা Private IP-তে Resolve হয়।
• Hybrid: অফিস আর Cloud Network একে অপরের ভেতরের Domain-এর প্রশ্ন Conditional Forwarding দিয়ে পাঠিয়ে দেয় (“internal.example.com-এর প্রশ্ন যাবে 10.0.0.2-তে”)।

কোথায় গোলমাল হয়:

• VPN আছে, Resolver ভুল। Tunnel চলছে, কিন্তু DNS এখনো বাইরের Resolver-এ যাচ্ছে: Public নামের উত্তর আসে Public, আর ভেতরের নামে আসে NXDOMAIN। সমাধান VPN-এ Split DNS: ভেতরের Domain-এর Query Tunnel দিয়ে ভেতরের Resolver-এ যাবে।
• পুরনো ভেতরের উত্তর। Laptop অফিস থেকে বের হলো Private Address Cache করে নিয়ে, তারপর TTL শেষ না হওয়া পর্যন্ত Service-এ পৌঁছাতে পারে না। তাই Split নামে TTL ছোট রাখো।
• দুই View আলাদা হয়ে যায়। কেউ এক View-তে Record যোগ করে আরেকটায় ভুলে যায়, আর Service চলে অর্ধেক ব্যবহারকারীর জন্য। দুটো View-ই Code-এ রাখো, একসঙ্গে Review করো।
• নিজের নয় এমন নাম ব্যবহার। বানানো Domain-এ ভেতরের নাম রাখলে (corp.com, .local, মনগড়া Top-level Domain) একদিন আসল নামের সঙ্গে বা Local Network-এর ডিভাইস খোঁজার ব্যবস্থার সঙ্গে ধাক্কা লাগে। নিজের Domain-এর একটা Subdomain ব্যবহার করো, যেমন internal.example.com; ২০২৪ সালে ICANN Private ব্যবহারের জন্য .internal-ও সংরক্ষণ করেছে।

#DNS দিয়ে Service Discovery

অনেক Service-ওয়ালা System-এ Instance সারাক্ষণ চালু হয়, বন্ধ হয়, জায়গা বদলায়, তাই IP Address Code-এ লিখে রাখলে ভাঙবেই। Service Discovery দিয়ে একটা Service নাম ধরে আরেকটা Service-এর এই মুহূর্তের সুস্থ Instance খুঁজে পায়, আর এর সবচেয়ে পুরনো ও সবখানে চলা উপায় হলো DNS:

• প্রতিটা Instance চালু হয়েই একটা Registry-তে Register করে (Consul, Kubernetes, AWS Cloud Map), আর Registry তার Health Check করে।
• Client payments.service.consul-এর মতো একটা নাম Resolve করে, আর পায় শুধু সুস্থ Instance-এর Address।
• SRV Record দেয় যা A Record পারে না: Port, সঙ্গে Priority আর Weight (_payments._tcp.example.com SRV 1 1 8443 p1.example.com)। Container যখন একই Host-এ আলাদা Port-এ চলে, তখন এটা কাজে লাগে।
• TTL হয় কয়েক সেকেন্ড, কখনো শূন্য, কারণ তালিকা সারাক্ষণ বদলায়।
• Kubernetes-এ একটু ভিন্নতা আছে: payments.shop.svc.cluster.local-এর মতো সাধারণ Service নাম Resolve হয় একটা স্থির Virtual IP-তে, আর প্রতিটা Node-এর Proxy নিয়ম Connection-গুলো সুস্থ Pod-দের মধ্যে ভাগ করে দেয়। Pod আসে-যায়, DNS একটুও বদলায় না। Headless Service অবশ্য সরাসরি Pod-এর Address ফেরত দেয়।

দুর্বল জায়গাটা তুমি আগেই চেনো: Cache। মরা Instance-কে DNS থেকে সরালে বদলায় শুধু পরের উত্তর; যে Client পুরনো তালিকা Cache করেছে, সে TTL শেষ না হওয়া পর্যন্ত মরা Address-কেই ডাকে, আর যে Runtime TTL মানে না সে ডাকে Restart পর্যন্ত। লম্বা Connection (HTTP/2, gRPC) পুরনো Instance-এই আটকে থাকে, যতক্ষণ না আবার Connect করে। তাই ব্যর্থ হলে Client-কে অন্য Address-এ আবার চেষ্টা করতেই হবে, আর বড় System প্রায়ই এমন Library বা Service Mesh যোগ করে যা সরাসরি Registry দেখে এক সেকেন্ডের কম সময়ে সাড়া দেয়; DNS থাকে সবার জন্য চলা সাধারণ ভিত্তি হিসেবে।

#নিজে করে দেখো

Terminal থেকে সরাসরি DNS দেখা যায়:

# Windows, macOS, Linux: তোমার কনফিগার করা Resolver-কে জিজ্ঞেস করো
nslookup example.com

# নির্দিষ্ট Resolver (Cloudflare)-কে MX Record জিজ্ঞেস করো
nslookup -type=mx gmail.com 1.1.1.1

# macOS / Linux: TTL-সহ বিস্তারিত উত্তর
dig example.com A
dig +trace example.com     # নিজেই Root → TLD → Authoritative হেঁটে দেখো

# Windows: OS-এর DNS Cache দেখো ও মুছে ফেলো
ipconfig /displaydns
ipconfig /flushdns

dig-এর Output-এ ANSWER SECTION দেখো: IN A-এর আগের সংখ্যাটি বাকি থাকা TTL। একই Command দুবার চালালে দেখবে সংখ্যাটি কমছে: এটিই তোমার Resolver-এ Cache Hit।

#সারসংক্ষেপ

মূল শিক্ষা

• DNS নামকে IP Address-এ রূপান্তর করে (এবং Mail Server, Alias, যাচাইয়ের Text ইত্যাদিও রাখে)। এটি একটি হায়ারার্কি, ডান থেকে বামে পড়তে হয়: Root → TLD → Domain → Host।
• চার ধরনের Server: Recursive Resolver তোমার হয়ে কাজ করে; Root Server TLD-এর পথ দেখায়; TLD Server Domain-এর Name Server দেখায়; Authoritative Server আসল Record রাখে।
• একটি পূর্ণ Lookup হলো তোমার ডিভাইস থেকে একটি Recursive Query এবং Resolver-এর কয়েকটি Iterative Query; তবে বেশিরভাগ Lookup-এর উত্তর আসে কোনো Cache থেকে (Browser, OS/hosts File, Router, Resolver)।
• মূল Record: A (IPv4), AAAA (IPv6), CNAME (Alias), MX (Mail, Priority অনুযায়ী), TXT (SPF/DKIM/যাচাই), NS (কে Authoritative), সঙ্গে PTR ও SOA।
• TTL ঠিক করে উত্তর কতক্ষণ Cache হবে। Record বদলানোর আগে TTL কমাও; “Propagation” মানে কেবল Cache-এর মেয়াদ শেষ হওয়া। “পাওয়া যায়নি”-ও Cache হয়।
• যেসব ব্যর্থতা দেখবে: NXDOMAIN (নামের অস্তিত্ব নেই), পরের Name Server-এ Retry-সহ Timeout, এবং কোনো বৈধ উত্তর না পেলে SERVFAIL।
• DoH/DoT Query এনক্রিপ্ট করে; DNSSEC সত্যতা প্রমাণ করে। System Design-এ DNS ভৌগোলিক অবস্থান, Health ও Round-robin অনুযায়ী ব্যবহারকারীকে পাঠায়, আর TTL হলো গতি বনাম চাপের Trade-off।
• Split-horizon DNS একই নামের জন্য ভেতরের আর বাইরের Client-কে আলাদা উত্তর দেয় (Private Hosted Zone, VPC Resolver); VPN Client-এর দরকার ভেতরের Resolver। Service Discovery চলে DNS নাম, ছোট TTL আর SRV Record দিয়ে; এর দুর্বল জায়গা Cache, তাই Client-কে আবার চেষ্টা করতে হয়।

নিজেকে যাচাই করো: DNS৩০টি প্রশ্ন