DNS (Domain Name System) হলো ইন্টারনেটের ফোন বুক: এটি example.com-এর মতো একটি মানুষের-পাঠযোগ্য নামকে 93.184.216.34-এর মতো একটি IP ঠিকানায় অনুবাদ করে। Resolution একটি স্তরক্রমিক (hierarchical) lookup, যা সাধারণত আপনার হয়ে একটি recursive resolver (আপনার ISP-এর অথবা 8.8.8.8-এর মতো একটি পাবলিক resolver) করে দেয় — এটি আপনার পক্ষে authoritative name server-এর গাছটি ধরে হাঁটে:
Browser ──▶ Recursive Resolver ──▶ Root (.) "ask .com's servers"
│ ◀──
├────────▶ TLD (.com) "ask example.com's servers"
│ ◀──
└────────▶ Authoritative "example.com = 93.184.216.34"
(example.com) ◀──
Browser ◀── 93.184.216.34
Resolver প্রথমে root server-গুলোকে জিজ্ঞেস করে (যারা TLD server-গুলো জানে), তারপর .com-এর জন্য TLD server-গুলোকে (যারা জানে example.com-এর জন্য কে authoritative), তারপর authoritative server-কে (যে আসল record ধরে রাখে)। প্রতিবার এটি না-করার জন্য, ফলাফল প্রতিটি স্তরে cache করা হয় — ব্রাউজার, OS, ও resolver — প্রতিটি record-এর TTL (time-to-live) মেনে চলে। একটি গরম cache মাইক্রোসেকেন্ডে resolve করে; একটি ঠান্ডা lookup কয়েকটি round trip খরচ করতে পারে।
সাধারণ record type-সমূহ: A (name → IPv4), AAAA (name → IPv6), CNAME (অন্য একটি নামের alias), MX (mail server), TXT (যেকোনো text, SPF/verification-এ ব্যবহৃত), এবং NS (একটি zone-কে delegate করে)। আপনি সরাসরি resolution পরিদর্শন করতে পারেন:
dig example.com A # A record এবং কোন server উত্তর দিয়েছে তা দেখায়
DNS একটি নাম থেকে শুরু হওয়া প্রতিটি request-এর গুরুত্বপূর্ণ পথে (critical path) বসে থাকে, তাই একটি ধীর বা ভুল-কনফিগার করা resolver সবকিছুতে latency যোগ করে। ইন্টারভিউয়াররা এই প্রশ্নটি পছন্দ করেন কারণ এটি প্রকাশ করে আপনি স্তরক্রম ও caching বোঝেন কিনা — এই দুটি ধারণাই একটি বৈশ্বিক, বিতরণকৃত সিস্টেমকে কোটি কোটি query দ্রুত উত্তর দিতে দেয়। এটি বাস্তব production ঘটনার একটি ঘন ঘন উৎসও ("সবসময়ই DNS"): মেয়াদোত্তীর্ণ record, ভুল TTL, বা পরিবর্তনের পরে propagation বিলম্ব — তাই caching ও TTL কীভাবে কাজ করে তা জানা সরাসরি ব্যবহারিক।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন