DNS গভীরে (Recursive, GeoDNS, Anycast)
- ●DNS মানুষের পড়ার মতো domain নামকে machine-এর IP address-এ অনুবাদ করে।
- ●Resolver → root → TLD → authoritative — এই ধাপে নাম resolve হয়, আর caching/TTL গতি বাড়ায়।
- ●GeoDNS ব্যবহারকারীর অবস্থান বুঝে কাছের server দেয়, Anycast একই IP-কে বহু জায়গায় বসায়।
সমস্যাটা কী?
মানুষ মনে রাখে facebook.com, কিন্তু কম্পিউটার চেনে শুধু IP address যেমন 157.240.1.35। প্রতিটা website-এর IP মুখস্থ রাখা অসম্ভব। তাছাড়া IP তো বদলায়ও — আজ যে server, কাল হয়তো অন্যটা। তাহলে নাম থেকে IP কে বের করে দেবে?
এই কাজটাই করে DNS (Domain Name System) — ইন্টারনেটের ফোনবুক। কিন্তু এই ফোনবুক একটা মাত্র খাতা নয়; এটা পুরো পৃথিবীজুড়ে ছড়ানো একটা বিশাল, স্তরভিত্তিক, cache-ভরা system। গভীরে গেলে দেখা যায় এর পেছনে আছে recursive resolution, caching, নানা record type, আর GeoDNS/Anycast-এর মতো চতুর কৌশল।
মূল ধারণা
DNS Resolver হলো সেই server (সাধারণত তোমার ISP বা Google-এর
8.8.8.8) যে তোমার পক্ষ থেকে domain নাম খুঁজে IP বের করার পুরো কাজটা সামলায়।
DNS-এর মূল কথা: কোনো একটা server পুরো ইন্টারনেটের সব নাম জানে না। দায়িত্ব ভাগ করা আছে স্তরে স্তরে — root, TLD (যেমন .com, .org), আর প্রতিটি domain-এর নিজস্ব authoritative server। Resolver এই শৃঙ্খল ধরে এগিয়ে সঠিক উত্তর জোগাড় করে।
কীভাবে কাজ করে
Recursive বনাম Iterative
দুটো ভিন্ন আচরণ:
- Recursive query — তুমি (client/stub resolver) resolver-কে বলো "আমাকে শুধু চূড়ান্ত IP দাও"। বাকি দৌড়াদৌড়ি resolver করবে।
- Iterative query — resolver যখন root/TLD-কে জিজ্ঞেস করে, ওরা চূড়ান্ত উত্তর দেয় না, বরং "পরের কাকে জিজ্ঞেস করবে" সেই reference দেয়। resolver নিজে এক এক করে এগোয়।
ধাপে ধাপে resolution
www.example.com খুঁজতে cache খালি থাকলে:
| ধাপ | কাকে জিজ্ঞেস | উত্তর |
|---|---|---|
| 1 | Stub resolver → Recursive resolver | "IP দাও" (recursive) |
| 2 | Resolver → Root server | ".com TLD server-এর কাছে যাও" |
| 3 | Resolver → TLD (.com) server | "example.com-এর authoritative server-এ যাও" |
| 4 | Resolver → Authoritative Server | "www.example.com = 93.184.216.34" |
| 5 | Resolver → তোমার device | চূড়ান্ত IP |
ধাপ ২–৪ iterative, কিন্তু ধাপ ১ ছিল recursive — দুটো একসাথেই ঘটে।
Caching ও TTL
প্রতিবার এই ৪ ধাপ করলে website ভয়ানক ধীর হতো। তাই প্রতিটি স্তরে উত্তর cache করা হয় — browser, OS, resolver সবখানে।
TTL (Time To Live) হলো একটা DNS record কতক্ষণ cache-এ রাখা যাবে তার সময়সীমা (সেকেন্ডে)।
TTL শেষ হলে cache মুছে আবার lookup হয়। এটা একটা trade-off:
- বড় TTL (যেমন ৮৬৪০০ = ১ দিন) → কম query, দ্রুত response, কিন্তু IP বদলালে ছড়াতে দেরি।
- ছোট TTL (যেমন ৩০০ = ৫ মিনিট) → বেশি query, কিন্তু পরিবর্তন দ্রুত প্রচার। Server migration-এর আগে TTL ছোট করে রাখা হয়।
গুরুত্বপূর্ণ record type
| Record | কাজ |
|---|---|
| A | domain → IPv4 address |
| AAAA | domain → IPv6 address |
| CNAME | একটা নামকে আরেকটা নামের alias বানায় (যেমন www → example.com) |
| MX | কোন mail server email গ্রহণ করবে |
| NS | কোন authoritative name server এই domain সামলায় |
| TXT | যেকোনো লেখা (SPF, domain verification) |
ভাবো তুমি ঢাকায় নতুন এসে এক ডাক্তারের ঠিকানা খুঁজছ। তুমি যাও এলাকার ফার্মেসিতে (resolver) — "এই ডাক্তার কোথায়?"। ফার্মেসি জানে না, পাঠায় থানার তথ্যকেন্দ্রে (root)। তথ্যকেন্দ্র বলে "এই এলাকার ব্যাপার, ওই ওয়ার্ড অফিসে যাও" (TLD)। ওয়ার্ড অফিস দেয় ডাক্তারের চেম্বারের সঠিক ঠিকানা (authoritative)। পরেরবার কেউ একই ডাক্তার খুঁজলে ফার্মেসি নিজের খাতা (cache) দেখেই বলে দেয় — যতদিন না ঠিকানা বদলায় (TTL)।
কৌশল
GeoDNS
একই domain-এর জন্য ব্যবহারকারীর ভৌগোলিক অবস্থান অনুযায়ী আলাদা IP ফেরত দেওয়া। ঢাকার ব্যবহারকারী পাবে সিঙ্গাপুরের server-এর IP, লন্ডনের ব্যবহারকারী পাবে ইউরোপের server-এর IP। ফলে latency কমে, কারণ data কম দূরত্ব ভ্রমণ করে। CDN-গুলো এটা ব্যাপকভাবে ব্যবহার করে।
Anycast
Anycast হলো এমন routing কৌশল যেখানে একই IP address পৃথিবীর অনেক জায়গায় একসাথে advertise করা হয়, আর network নিজেই ব্যবহারকারীকে নেটওয়ার্ক-হিসেবে নিকটতম server-এ পাঠায়।
GeoDNS অবস্থান দেখে আলাদা উত্তর দেয়; Anycast একই IP রেখে network route দিয়ে কাছের জায়গায় পাঠায়। Root DNS server (মাত্র ১৩টি "logical" নাম, কিন্তু শত শত physical instance) Anycast-এই চলে — এজন্যই এত কম সংখ্যা দিয়েও পুরো পৃথিবী চলে। Cloudflare-এর 1.1.1.1-ও Anycast।
কখন ব্যবহার করবে / করবে না
- ছোট TTL — যখন শিগগিরই IP বদলাবে (deployment, failover)।
- বড় TTL — স্থিতিশীল service-এ, query কমাতে।
- GeoDNS/Anycast — বিশ্বজুড়ে ব্যবহারকারী আছে এমন বড় service-এ; ছোট একক-অঞ্চলের app-এ দরকার নেই।
DNS পরিবর্তন সঙ্গে সঙ্গে সবার কাছে পৌঁছায় না — পুরোনো TTL শেষ না হওয়া পর্যন্ত অনেক resolver পুরোনো IP cache করে রাখে। তাই migration-এর অন্তত একদিন আগে TTL ছোট (যেমন ৩০০s) করে নাও, নইলে কিছু ব্যবহারকারী পুরোনো (মৃত) server-এ যেতেই থাকবে।
বাস্তব উদাহরণ
একটা e-commerce site shop.com.bd ঢাকা ও যুক্তরাষ্ট্র দুই জায়গায় server রাখে:
- ঢাকার ব্যবহারকারী lookup করলে GeoDNS ঢাকার কাছের (সিঙ্গাপুর) server-এর IP দেয়।
- সেই IP আসলে Anycast — একই IP বহু data center-এ থাকায় network নিকটতমটায় পাঠায়।
- উত্তর
8.8.8.8resolver-এ cache হয় TTL ৩০০s; পরের ব্যবহারকারী তাৎক্ষণিক IP পায়। - Black Friday-র আগে server বদলাতে হলে তারা TTL ৬০s নামিয়ে রাখে যাতে পরিবর্তন দ্রুত ছড়ায়।
Interview-এ "DNS lookup কেন কখনো ধীর, কখনো তাৎক্ষণিক?" — উত্তর: caching ও TTL। প্রথমবার পুরো recursive chain চলে (root→TLD→authoritative), পরে cache থেকে আসে যতক্ষণ TTL বাকি। আর "GeoDNS vs Anycast" আলাদা করতে পারলে seniority বোঝা যায়: একটা DNS-স্তরের সিদ্ধান্ত, আরেকটা routing-স্তরের।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Recursive resolution-এ সবার আগে কোন server-কে জিজ্ঞেস করা হয় (cache খালি থাকলে)?
2. একটি domain-এর IPv4 address কোন record type-এ থাকে?
3. TTL কমিয়ে রাখলে কী হয়?