What Is DNS and How It Works

কখনও কি আপনি ভেবে দেখেছেন যে ব্রাউজারে devopsquad.com বা google.com লিখে Enter চাপার পর আসলে পেছনে কী কী ধাপ চলে? আমরা শুধু দেখি পেইজ লোড হচ্ছে, কিন্তু মাঝে মাঝে “DNS_PROBE_FINISHED_NXDOMAIN” বা “Server not found” দেখলেই বুঝি এই অদৃশ্য লেয়ারে আসল গোলমালটা হয়।

DevOps, SRE, এমনকি সাধারণ developer হিসেবে কাজ করলেও, DNS, resolver, authoritative nameserver, আর caching ঠিকমতো না বুঝলে ট্রাবলশুটিং একদম অন্ধকারে তীর ছোড়ার মতো লাগে। এই লেখায় আমি DNS-কে একদম বেসিক থেকে ধরেছি।

DNS lookup-এর ৮টা ধাপ, কোন সার্ভার কোথায় কি রোল প্লে করে, কোন ধরনের DNS query হয়, আর কোথায় কোথায় cache ধরে রেখে performance বাড়ানো হয় সবকিছু ধীরে-সুস্থে খুলে বলার চেস্টা করেছি। আমার বিশ্বাস আজকের এই টিউটোরিয়ালে আমাদের অনেক কিছুই শেখা হবে।

আমি যখন প্রথম Production incident DNS মিসকনফিগারেশনের ধাক্কা খেয়েছিলাম, তখনই বুঝেছি “ওহ, এটা শুধু নেটওয়ার্ক টিমের বিষয় না, আমাদের Day-to-Day DevOps লাইফের বেসিক স্কিল”। এই আর্টিকেলটা পড়ে আপনি অন্তত এতটা কমফোর্টেবল হয়ে যাবেন যে পরেরবার DNS সংক্রান্ত সমস্যা দেখলে আতঙ্ককিত না হয়ে, মাথায় পরিষ্কার একটা mental ম্যাপ নিয়ে ডিবাগ শুরু করতে পারবেন। তাহলে চলুন শুরু করা যাক।

DNS কী? | DNS আসলে কাজ করে কীভাবে

Domain Name System বা সংক্ষেপে DNS হচ্ছে Internet-এর ফোনবুকের মতো জিনিস। আমরা মানুষজন সাধারণত google.com, facebook.com এর মতো Domain name দিয়ে ওয়েবসাইটে যাই। কিন্তু ব্রাউজার আর অন্য মেশিনগুলো একে অপরের সঙ্গে কথা বলে IP address দিয়ে। DNS-এর কাজ হলো এই Domain name গুলোকে সঠিক IP address-এ translate করে দেওয়া, যেন ব্রাউজার বুঝতে পারে কোন সার্ভারে রিকোয়েস্ট পাঠাতে হবে।

Internet-এ যেকোনো ডিভাইস, হোক সেটা laptop, mobile, server প্রতিটিরই একটা করে unique IP address থাকে, যেটা ব্যবহার করে অন্য মেশিন সেটাকে খুঁজে পায়। এখন ধরুন, আপনাকে যদি প্রতিটা সাইটের জন্য 192.168.10.10 টাইপের IPv4 address বা এর চেয়েও জটিল IPv6 address যেমন 2400:cb00:2048:1::c629:d7a2 মুখস্থ রাখতে হতো তাহলে সেটা প্র্যাক্টিক্যালি অসম্ভব।

এই ঝামেলা থেকে বাঁচানোর জন্যই DNS server গুলো আছে। তারা একটা lookup service-এর মতো কাজ করে। আপনি যখন Domain name দেন যেমনঃ DevOpsquad.com, DNS পেছনে বসে সেই নামের against-এ থাকা IP address বের করে দেয়, আর আপনার Browser সেই IP ব্যবহার করে আসল resource (ওয়েবসাইট, API, ইত্যাদি) লোড করে।

DNS কীভাবে কাজ করে?

DNS resolution বলতে বোঝায় একটা human-friendly hostname (যেমন www.devopsquad.com) কে কম্পিউটারের বোঝার মতো IP address (যেমন 192.168.10.10) এ কনভার্ট করার প্রক্রিয়া। Internet-এ থাকা প্রতিটা device-এর জন্য আলাদা একটা করে IP address থাকে, ঠিক যেমন নির্দিষ্ট বাড়ি খুঁজে পেতে আমাদের একটা নির্দিষ্ট রাস্তার ঠিকানা লাগে, IP address ঠিক তেমনই কাজ করে।

আপনি যখন কোনো Webpage লোড করতে চান, তখন আসলে দু’টা জগৎকে মিলিয়ে দিতে হয়। একদিকে আছে আপনি ব্রাউজারে যা টাইপ করছেন যেমন example.com, আরেকদিকে আছে সেই সাইটটা যে সার্ভারে চলছে তার machine-friendly IP address।
DNS এই ট্রান্সলেটর/দোভাষীর কাজটাই করে দেয়। অর্থাৎ মানুষের জন্য সহজ নাম আর মেশিনের জন্য দরকারি নম্বর (IP Address)।

DNS resolution-এর পুরো প্রসেসটা বুঝতে হলে আগে একটু ধারণা থাকা দরকার যে এই রিকোয়েস্ট বা DNS query আসলে কোন কোন hardware component-এর মধ্য দিয়ে যায়। আপনার ব্রাউজারের দৃষ্টিতে সবকিছুই একদম “Behind the scenes” হয়। আপনি শুধু URL লিখে Enter চাপেন, আর বাকি কাজগুলো যেমন DNS lookup, resolve, cache ইত্যাদি সব কিছুর ঝামেলা আপনার কম্পিউটার আর নেটওয়ার্কের বিভিন্ন DNS server মিলে নিজেরাই সামলে নেয়।

একটা Webpage লোড আর ৪ ধরনের DNS server

DNS দিয়ে যখন কোনো ওয়েবসাইট লোড হয়, তখন আসলে একাধিক DNS server মিলেমিশে কাজ করে। স্কুলের লাইব্রেরিতে যেমন আলাদা আলাদা লোক আর সেকশন থাকে কেউ বই খুঁজে দেয়, কেউ ইনডেক্স দেখায়, কেউ নির্দিষ্ট শেল্ফ দেখিয়ে দেয় ঠিক তেমনই DNS-এরও নিজের “টিম” আছে। সাধারণভাবে চারটা key অংশ থাকে।

DNS Record Request Sequence

১) DNS Recursor – প্রথম লাইনের “লাইব্রেরিয়ান”

DNS recursor-কে আপনি একেবারে ফ্রন্টডেস্কের Librarian ভাবতে পারেন। Client machine (আপনার ব্রাউজার, মোবাইল, অ্যাপ ইত্যাদি) যখন কোনো Domain-এর জন্য query পাঠায়, প্রথমেই সেটা সাধারণত এই DNS recursor-এর কাছেই যায়।

• এটা সাধারণত আপনার ISP, local network (যেমন office, home router), বা কোনো public DNS (যেমন Google DNS, Cloudflare DNS) হতে পারে।
• Recursor সরাসরি সব উত্তর জানে না, কিন্তু কাজ তারই। Client একটা domain-এর IP address চাইছে, এখন যেভাবেই হোক এটা তাকে বের করতেই হবে।

তারপর সে নিজের প্রয়োজনেই বাড়তি DNS request পাঠিয়ে বাকিদের থেকে তথ্য জোগাড় করে আনে, যতক্ষণ না final IP address পায়।

২) Root Nameserver – লাইব্রেরির মূল index

Root nameserver হলো সেই ইনডেক্স যেখান থেকে পুরো Internet-এর DNS lookup শুরু হয়।
এটাকে আমরা ধরতে পারি লাইব্রেরির বড় index book-এর মতো, যেখানে লেখা আছে: “কোন rack-এ কোন type-এর বই আছে।”

Root server নিজের কাছে সব domain-এর IP address রাখে না, কিন্তু জানে পরের ধাপে কোন TLD server-এর কাছে পাঠাতে হবে।

যেমন ব্রাউজার www.devopsquad.com রিজলভ করতে চাইলে, recursor root server-কে জিজ্ঞেস করবে “.com ডোমেইনগুলো কাকে জিজ্ঞেস করব?” Root server তখন বলবে, “.com এর জন্য এই এই TLD server-গুলোর কাছে যাও”।

৩) TLD Nameserver – TLD অনুযায়ী নির্দিষ্ট শেল্ফ

TLD nameserver (Top Level Domain server)-কে আপনি ধরে নিতে পারেন একটা নির্দিষ্ট rack বা শেল্ফ হিসেবে যেমন .com সেকশন, .org সেকশন, .net সেকশন ইত্যাদি। Hostname-এর শেষের অংশটাই TLD যেমন devopsquad.com-এ TLD হলো com।

এই TLD server-এর কাজ হলো ওই TLD-এর ভেতরে থাকা ডোমেইনের জন্য কোন authoritative nameserver-এর কাছে যেতে হবে সেটা বলে দেওয়া।

উদাহরণ:

• Query: www.devopsquad.com
• Root বলল: .com এর জন্য TLD server-এ যাও।
• .com TLD server তখন recursor-কে বলবে:
  devopsquad.com ডোমেইনের authoritative nameserver হচ্ছে A, B, C ওদের একজনের কাছে যাও।”

৪) Authoritative Nameserver – আসল “বই”, যেখানে উত্তর লেখা

সবশেষে আসে authoritative nameserver এখানেই আসল data থাকে। লাইব্রেরির উদাহরণে এটা একধরনের dictionary-র মতো, যেখানে নির্দিষ্ট শব্দের meaning লেখা থাকে।

Authoritative server-এর কাজ:

• ওর zone file-এর ভেতরে যদি ওই hostname-এর DNS record থাকে (যেমন A record, AAAA record),
• তাহলে সে সেই hostname-এর জন্য নির্দিষ্ট IP address রিটার্ন করে দেবে DNS recursor-কে।

মানে, www.devopsquad.com এর A record যদি সেখানে থাকে, সে উত্তর দেবে:

www.devopsquad.com → 192.168.10.10 (উদাহরণ হিসেবে)

তারপর recursor (আমাদের librarian) ঐ IP address নিয়ে client-এর ব্রাউজারকে বলে দেয়:

এই নাও, সার্ভারের ঠিকানা পেয়ে গেছি এখন তুমি সরাসরি ওখানে HTTP/HTTPS request পাঠাও।

এই পুরো প্রক্রিয়াটাই এত দ্রুত হয় যে আমরা ইউজার হিসেবে শুধু দেখি URL লিখে Enter দিলেই কয়েক মিলিসেকেন্ড/সেকেন্ডের মধ্যে পেজ লোড হয়ে গেল। পেছনের এই চারটা DNS server অনেকটা অটোপাইলটে এসব সামলে নিচ্ছে।

Authoritative DNS server আর Recursive DNS resolver এর মধ্যে পার্থক্য কী?

এই দুইটা টার্মই মূলত DNS infrastructure-এর ভেতরের Server (বা server group) বোঝায়, কিন্তু এদের কাজ ও অবস্থান একে-অপরের থেকে আলাদা। একই pipeline-এর দু-দিকের দুইজন খেলোয়াড় বলতে পারেন।

সহজ করে মনে রাখার একটা উপায় হলোঃ

• Recursive resolver থাকে DNS query-এর শুরুর দিকে
• আর Authoritative nameserver থাকে একদম শেষ দিকে

মানে, client যখন “এই ডোমেইনের IP টা দাও তো?” বলে যাত্রা শুরু করে, তখন প্রথমে recursive resolver-এর কাছে যায়। আর সব শেষে যে সার্ভার থেকে আসল রেকর্ড (যেমন A record, CNAME) ফিরে আসে, সেটা হলো Authoritative Nameserver।

Recursive DNS resolver

Recursive DNS resolver হলো সেই কম্পোনেন্ট, যেটা client-এর পাঠানো recursive request রিসিভ করে এবং প্রতিশ্রুতি দেয়,

ঠিক আছে, আমি সব জায়গায় খুঁজে দেখে তোমাকে final DNS record এনে দিচ্ছি।

এটা কী করে?

• ক্লায়েন্ট যখন বলে: www.example.com এর IP লাগবে
• Recursive resolver তখন নিজে নিজে একাধিক DNS server-এ request পাঠাতে থাকে
  • আগে root nameserver
  • তারপর TLD nameserver
  • শেষে authoritative nameserver
• এভাবে ঘুরে–ফিরে requested record না পাওয়া পর্যন্ত চেষ্টা করে
• কোনো কারণে record না পেলে timeout বা error রিটার্ন করে

কিন্তু ভালো খবর হলো প্রতিটা request-এর জন্যই তাকে সব ধাপে যেতে হয় না। এখানেই কাজে আসে caching।

Caching কীভাবে সাহায্য করে?

Caching basically একটা Data Persistence Mechanism। মানে, resolver আগের DNS lookup-এর ফলাফল কিছু সময়ের জন্য নিজের মেমোরি/স্টোরেজে রেখে দেয় (যতক্ষণ না TTL শেষ হয়)।

DNS সার্ভারগুলো সাধারণত cache ব্যবহার করে ঠিক এই কারণেইঃ

• বারবার একই রেকর্ডের জন্য upstream সার্ভারে query পাঠাতে না হয়
• bandwidth কম লাগে
• upstream/root/TLD/authoritative সার্ভারগুলোর ওপর লোডও কম পড়ে
• আর end user-এর কাছে উত্তর দ্রুত পৌঁছে যায়

আমরা DevOps আর SRE কাজ করতে গিয়ে প্র্যাকটিক্যালি যা দেখি ভালোভাবে cache টিউন করা থাকলে DNS অনেক কম latency-তে কাজ করে, আর অকারণে recursive lookup-এ ট্রাফিকও কম পড়ে।

Authoritative DNS server

সিম্পলি বললে, authoritative DNS server হচ্ছে সেই সার্ভার, যেখানে আসল DNS resource record গুলো থাকে এবং এগুলোর দায়িত্বও তারই ওপর। পুরো DNS lookup chain-এর একদম নিচের লেয়ারে এই সার্ভার বসে থাকে। যেখান থেকে শেষ পর্যন্ত সেই রেকর্ডটা রিটার্ন হয়, আর সেই রেকর্ড ব্যবহার করেই আপনার ব্রাউজার ঠিকঠাক IP address এ গিয়ে ওয়েবসাইট বা অন্য কোনো web resource-এ কানেক্ট হতে পারে।

Authoritative nameserver-এর একটা বড় বৈশিষ্ট্য হলোঃ

• ও নিজেই নিজের ডেটা থেকে query-এর উত্তর দিতে পারে,
• অন্য কোনো DNS server-কে আর জিজ্ঞেস করতে হয় না,
  কারণ নির্দিষ্ট কিছু DNS record-এর জন্য এটাকেই final source of truth ধরা হয়।

কিছু কিছু ক্ষেত্রে, যেমন query যদি হয় blog.devopsquad.com বা shop.devopsquad.com এর মতো কোনো subdomain এর জন্য, তখন এই chain-এর ভেতরে আরেকটা nameserver যুক্ত হয়। এই অতিরিক্ত nameserver সাধারণত ওই subdomain-এর CNAME record স্টোর করে রাখে এবং সেখান থেকে সেই subdomain কোন আসল নাম/হোস্টকে পয়েন্ট করছে সেটা resolve হয়।

এবার আসি services-এর পার্থক্যে।

অনেক DNS service আর Cloudflare যে ধরনের সার্ভিস দেয়, এই দুটো জিনিস কিন্তু এক না।

যেমন –

• Google DNS,
• OpenDNS,
• বা ISP-রা (যেমন link3)

এসব provider-রা সাধারণত বিভিন্ন data center-এ DNS recursive resolver ডিপ্লয় করে রাখে। এরা Optimized DNS server cluster দিয়ে দ্রুত query resolve করতে খুব ভালো কাজ করে, কিন্তু এগুলো fundamentally আলাদা Cloudflare-এর হোস্ট করা nameserver থেকে।

Cloudflare মূলত এমন সব Infrastructure-level nameserver চালায়, যেগুলো Internet-এর ভিত্তি কাঠামোর অংশ। এর দারুণ একটা উদাহরণ হলো F-root server network, যেটার একটা অংশ হোস্ট করার দায়িত্ব Cloudflare-এর ওপর।

F-root হলো root-level DNS nameserver গুলোর একটি, যেটা প্রতিদিন বিলিয়ন-বিলিয়ন DNS request হ্যান্ডেল করে। Cloudflare-এর Anycast network আর্কিটেকচারের কারণে তারা সারা দুনিয়াজুড়ে ছড়িয়ে থাকা সার্ভার থেকে একই IP-তে ট্রাফিক সার্ভ করতে পারে, ফলে বিশাল পরিমাণ DNS ট্রাফিকও খুব কম latency আর বিনা service interruption-এ সামলানো সম্ভব হয়।

DNS lookup-এর ধাপগুলো কী কী?

বেশিরভাগ ক্ষেত্রে DNS-এর কাজই হলো ‍একটা domain name কে সঠিক IP address এ translate করা। এই প্রক্রিয়াটা আসলে কীভাবে হয়, সেটা বুঝতে চাইলে ভালো হয় যদি একে ব্রাউজার থেকে শুরু করে DNS system হয়ে আবার ব্রাউজারে ফেরা একটা যাত্রা হিসেবে কল্পনা করি। মানে, ব্রাউজার একটা প্রশ্ন করল “devopsquad.com কোথায় থাকে?” তারপর DNS ecosystem ঘুরে সেই উত্তর নিয়ে আবার ব্রাউজারে ফিরে এল।

এখন চলুন এই পুরো DNS lookup প্রক্রিয়াটা ধাপে ধাপে দেখি।

নোট: অনেক সময় DNS lookup-এর দরকারি তথ্য আগে থেকেই কোথাও cached থাকে

• হয় আপনার নিজের কম্পিউটার বা ব্রাউজারের ভেতরে (local cache),
• নয়তো DNS infrastructure-এর অন্য কোনো server-এ (recursive resolver/cache server ইত্যাদি)।

সাধারণভাবে ধরা হয়, একটা Full DNS lookup প্রক্রিয়ায় প্রায় ৮টা ধাপ থাকে। কিন্তু যখনই কোথাও cache hit হয় (মানে, আগে থেকেই তথ্য পাওয়া যায়), তখন এই ধাপগুলোর কিছু অংশ স্কিপ হয়ে যায় তাই lookup অনেক দ্রুত হয়ে যায়।

যে উদাহরণটা আমরা নিচে দেখব, সেখানে ধরা হচ্ছে কিছুই cached নেই, তাই full ৮টা স্টেপই follow করতে হবে।

DNS lookup-এর ৮টা ধাপ

• ইউজার ব্রাউজারে devopsquad.com টাইপ করে Enter চাপলো। এই query প্রথমে Internet-এর ভেতর দিয়ে গিয়ে একটা DNS recursive resolver-এর কাছে পৌঁছে।
• ওই resolver এরপর গিয়ে একটি DNS root nameserver (.) কে query পাঠায়।
• Root server resolver-কে রিপ্লাই দিয়ে বলে দেয়, কোন Top Level Domain (TLD) DNS server (যেমন .com, .net ইত্যাদি)–এর কাছে যেতে হবে; এই TLD server–গুলো নিজেদের অধীনে থাকা ডোমেইনগুলোর তথ্য রাখে। আমাদের উদাহরণে devopsquad.com খোঁজার সময় request-টা .com TLD-এর দিকে রিডাইরেক্ট করা হয়।
• এরপর resolver এইবার request পাঠায় .com TLD server-এর কাছে।
• .com TLD server উত্তর দেয় devopsquad.com ডোমেইনের nameserver (authoritative nameserver) কোন IP address-এ আছে, সেই তথ্য দিয়ে।
• তারপর recursive resolver আরেকটা query পাঠায় সরাসরি ওই domain-এর nameserver-এ (devopsquad.com-এর authoritative DNS server)।
• ঐ nameserver তখন devopsquad.com ডোমেইনের জন্য থাকা IP address resolver-কে রিটার্ন করে।
• শেষ ধাপে DNS resolver, যেটা শুরুতে ব্রাউজারের query রিসিভ করেছিল, সেই একই ব্রাউজারকে এখন devopsquad.com ডোমেইনের IP address দিয়ে রিপ্লাই দেয়।

এভাবে যখন DNS lookup-এর এই ৮টা ধাপ শেষ হয় আর devopsquad.com এর জন্য IP address পাওয়া যায়, তখন ব্রাউজার অবশেষে আসল ওয়েবপেজটা লোড করার জন্য request পাঠাতে পারে।

এরপর যা হয়ঃ

• ব্রাউজার ঐ পাওয়া IP address-এ একটা HTTP (বা HTTPS) request পাঠায়।
• সেই IP address-এ থাকা web server ঐ request রিসিভ করে এবং corresponding webpage-এর content ব্রাউজারে ফেরত পাঠায়, যেটা আপনি Screen-এ rendered আকারে দেখতে পান। অর্থাৎ ১০ টা স্টেপ পার হয়ে আমরা একটা Webpage দেখতে পাই।

DNS caching কী? আর কোথায় কোথায় DNS cache রাখা হয়?

Caching-এর মূল উদ্দেশ্য খুব সোজা: ডেটা সাময়িকভাবে এমন জায়গায় জমা রাখা, যেখান থেকে পরে সেই ডেটা রিকোয়েস্ট এলে ফাস্ট আর রিলায়েবল ভাবে রেসপন্স দেওয়া যায়।

DNS caching মানে হলো DNS-এর তথ্যগুলোকে client-এর যতটা সম্ভব কাছে রেখে দেওয়া, যাতে পুরো DNS lookup chain-এর নিচের দিকের সার্ভারগুলোর কাছে না গিয়েও আগেই query resolve হয়ে যায়। ফলে:

• ওয়েবপেজের load time কমে,
• আর নেটওয়ার্কের bandwidth আর সার্ভারের CPU consumption দুটোই কম হয়।

DNS data বিভিন্ন লেভেলে cache হতে পারে, আর প্রতিটা cache-ই DNS record-গুলোকে কিছু নির্দিষ্ট সময়ের জন্য রাখে, যেটা ঠিক করা হয় ওই রেকর্ডের TTL (time-to-live) দিয়ে।

Browser DNS caching

Modern web browser গুলো ডিফল্টভাবেই DNS record কিছু সময়ের জন্য cache করে রাখে। কারণটাও একদম পরিষ্কার অর্থাৎ DNS caching যদি ব্রাউজারের একদম কাছাকাছি হয়, তাহলে cache চেক করতে আর সঠিক IP address বের করে রিকোয়েস্ট পাঠাতে কম ধাপ লাগে, মানে performance বেড়ে যায়।

তাই যখন কোনো ওয়েবসাইটে যাওয়ার জন্য ব্রাউজারের DNS record দরকার পড়ে, তখন প্রথমেই সে দেখে, এই ডোমেইনের রেকর্ড কি already আমার browser cache-এ আছে?

যদি থাকে, তাহলে আর resolver, root, TLD, authoritative কাউকেই জিজ্ঞেস করতে হয় না, ব্রাউজার cache থেকে IP নিয়ে সরাসরি সার্ভারে HTTP/HTTPS request পাঠিয়ে দেয়।

যদি আপনি Chrome ব্যবহার করেন, তাহলে আপনার ব্রাউজারের DNS cache-এর অবস্থা দেখতে পারেন এই URL-এ গিয়ে chrome://net-internals/#dns

এখানে গিয়ে আপনি দেখতে পাবেন ব্রাউজার কোন কোন ডোমেইনের জন্য কী কী DNS entry ক্যাশ করে রেখেছে, আর চাইলে সেগুলো clear-ও করে দিতে পারেন।

Operating system (OS) level DNS caching

OS level DNS caching হলো DNS lookup বের হওয়ার আগেই কম্পিউটারের ভেতরে দ্বিতীয় আর শেষ local স্টেপ। মানে, ব্রাউজার বা অ্যাপ থেকে query বের হয়ে প্রথমে যায় OS-এর কাছে, তারপর সেখান থেকে না পেলে বাইরের নেটওয়ার্কে যায়।

আপনার অপারেটিং সিস্টেমে যেই ছোট প্রসেসটা DNS নিয়ে কাজ করে, তাকে সাধারণত বলে stub resolver বা DNS client।

ওর কাজটা এক প্রকার এরকমঃ

• কোনো অ্যাপ্লিকেশন (যেমন browser, curl, কোনো CLI টুল) OS-কে জিজ্ঞেস করল “devopsquad.com এর IP addressটা দাও।”
• stub resolver প্রথমেই নিজের cache চেক করে দেখে এই ডোমেইনের কোনো রেকর্ড আগে থেকে আছে কি না।
• যদি cache-এ থাকে, তাহলে সেখান থেকেই IP রিটার্ন করে দেবে, বাইরে কোনো DNS server-এর দরকারই হয় না।
• আর যদি cache-এ না থাকে, তখন সে একটা DNS query পাঠায় local network-এর বাইরে, সাধারণত আপনার ISP-এর ভেতরে থাকা DNS recursive resolver-এর কাছে।
  এই query-টা হয় recursive flag সেট করা অবস্থায়, মানে সে বলে “তুমি সব জায়গা ঘুরে আমার জন্য final রেজাল্ট নিয়ে আসো।

ISP-এর recursive resolver কীভাবে cache ব্যবহার করে?

আপনার ISP-এর মধ্যে থাকা recursive resolver যখন কোনো DNS query পায়, তখন আগের সব ধাপের মতোই প্রথমে দেখে এই host → IP mapping কি already আমার local persistence / cache-এ আছে?

এখানেও cache খুব critical ভূমিকা রাখে। আর মজার ব্যাপার, শুধু A record আছে কি নেই তাই না, NS record থাকলেও resolver অনেকটা শর্টকাট নিতে পারে।

Recursive resolver cache-এর ওপর ভিত্তি করে কয়েকটা অপশনাল শর্টপাথ নিতে পারে:

• যদি A record না থাকে, কিন্তু ঐ ডোমেইনের authoritative nameserver-এর NS record থাকে, তাহলে resolver সরাসরি সেই authoritative nameserver-গুলোকেই query করবে, এতে root server আর .com TLD server-এর ধাপগুলো স্কিপ হয়ে যাবে (আমাদের devopsquad.com উদাহরণে)।
• যদি NS record-ও না থাকে, কিন্তু TLD server (.com) এর তথ্য cache-এ থাকে, তাহলে resolver সরাসরি ওই TLD server-এ query পাঠাবে, ফলে root server-এ যাওয়ার স্টেপটা স্কিপ হয়ে যাবে।
• আর খুবই rare কেসে, যদি cache-এ TLD server সম্পর্কিত কোনো রেকর্ডও না থাকে, তখন resolver বাধ্য হয়ে আবার একদম শুরু থেকে root server-কে query করবে। সাধারণত এমনটা তখনই বেশি হয়, যখন resolver-এর DNS cache একেবারে purge/flush করে ফেলা হয় (যেমন কোনো maintenance, restart, বা manual cache clear-এর পর)।

DevOps-এ কাজ করতে গেলে এগুলো বোঝা খুব জরুরি। dnsmasq, systemd-resolved, বা containerized workload-এ /etc/resolv.conf নিয়ে কাজ করার সময় বুঝতে পারবেন, কোন লেয়ারে cache লাগছে আর কোথায় latency হচ্ছে।

এখন পর্যন্ত আপনি DNS-কে শুধু “ইন্টারনেটের ফোনবুক” হিসেবে নয়, বরং একটা ধাপে ধাপে কাজ করা সিস্টেম হিসেবে দেখেছেন, যেখানে recursive resolver, root server, TLD server, আর authoritative nameserver মিলে আপনার টাইপ করা domain name-টাকে সঠিক IP address-এ পৌঁছে দেয়।

আমরা দেখলাম DNS query-এর আলাদা আলাদা ধরন (recursive, iterative, non-recursive) কীভাবে কাজ করে, আর browser, OS, ISP resolver সব লেভেলে DNS caching কীভাবে latency কমিয়ে পুরো সিস্টেমকে ফাস্ট আর ইফিশিয়েন্ট করে রাখে।

বাস্তবে DevOps বা SRE হিসেবে যখন কোনো incident আসবে, তখন এই ধারণাগুলোই আপনাকে সাহায্য করবে ঠিক করতে।

এখন কি cache flush করব, resolver বদলাব, না কি নেম সার্ভারের কনফিগ ঘাঁটব?

চাইলে এখন থেকেই dig, nslookup বা host কমান্ড দিয়ে খেলা শুরু করতে পারেন, নিজের মেশিন আর প্রোজেক্টের domain গুলোর DNS flow দেখতে পারেন। যত বেশি হাত-কলমে DNS নিয়ে কাজ করবেন, তত কম “ম্যাজিক” আর বেশি “লজিক” মনে হবে।

শেষ কথা একটাই DNS ঠিকমতো বুঝতে পারলে, নেটওয়ার্ক সম্পর্কিত অনেক ধোঁয়াশা কেটে যাবে আর আপনার Production সিস্টেমে সমস্যা হলে, আপনি হবেন সেই মানুষটা যে আত্মবিশ্বাস নিয়ে বলতে পারবে, “চল, DNS থেকে শুরু করি।”