DNS সমাধান, শুরু থেকে শেষ পর্যন্ত

প্রতিবার যখন আপনি একটি ডোমেইন ব্রাউজারে টাইপ করেন, একটি লুকআপের চেইন আপনি যে সাইটটি চান তার একটি প্যাকেটও পৌঁছানোর আগেই চালু হয়। সেই চেইনের বেশিরভাগই অদৃশ্য, এবং এর বেশিরভাগ ব্যাখ্যা "এটি একটি ফোন বুকের মতো" তে থেমে যায়। এখানে আসলে কি ঘটে, ধাপে ধাপে, যার মধ্যে রয়েছে সেই অংশগুলি যা মানুষ সাধারণত এড়িয়ে যায়।

Stub resolver বুদ্ধিমান নয়

আপনার অপারেটিং সিস্টেম নিজে থেকে প্রকৃত DNS সমাধান করে না। এটি একটি stub resolver চালায়, একটি সূক্ষ্ম কোডের অংশ যা শুধুমাত্র আপনার প্রশ্নকে /etc/resolv.conf-এ কনফিগার করা যেকোনো DNS সার্ভারে এগিয়ে দেয় Linux-এ বা Windows-এ আপনার নেটওয়ার্ক অ্যাডাপ্টার সেটিংসে। আপনার সেটিংস এই দিয়ে চেক করুন:

cat /etc/resolv.conf

সেই ফাইলটি সাধারণত আপনার রাউটার (যেমন 192.168.1.1), আপনার ISP-এর resolver, অথবা একটি পাবলিক একটি যেমন 1.1.1.1 বা 8.8.8.8-এর দিকে নির্দেশ করে। Stub resolver-এর নিজস্ব কোনো ক্যাশে যুক্তি নেই যা OS বা systemd-resolved-এর মতো একটি স্থানীয় daemon প্রদান করে তার বাইরে।

Recursive resolver প্রকৃত কাজটি করে

এক বার আপনার প্রশ্ন একটি recursive resolver-এ আঘাত করলে, সেই সার্ভার উত্তর খুঁজে পাওয়ার কাজ নিয়ে নেয়, এমনকি যদি এটি সেখানে পেতে অন্যান্য সার্ভারের কাছে জিজ্ঞাসা করতে হয়। যদি উত্তর ইতিমধ্যে একটি পূর্ববর্তী লুকআপ থেকে ক্যাশ করা হয়, আপনি অবিলম্বে এটি ফিরে পান। TTL-এর সাথে চেক করুন:

dig example.com

ANSWER SECTION দেখুন — রেকর্ড টাইপের আগে সংখ্যা (যেমন A-এর আগে 300) সেকেন্ডে TTL। সেটি কত দীর্ঘ resolver-গুলি আবার জিজ্ঞাসা করার আগে রেকর্ডটি ক্যাশ করার অনুমতি পায়।

যদি কিছুই ক্যাশ না থাকে, recursive resolver DNS শ্রেণিবিন্যাসের মূল থেকে নিচে একটি পথ শুরু করে।

Root, TLD, এবং authoritative সার্ভার

13টি root সার্ভার ঠিকানা রয়েছে (a.root-servers.net থেকে m.root-servers.net পর্যন্ত), প্রতিটি anycast রুটিং-এর মাধ্যমে অনেক শারীরিক মেশিন দ্বারা সমর্থিত। Root সার্ভার জানে না example.com কোথায় থাকে, কিন্তু এটি জানে কোন সার্ভার .com পরিচালনা করে, তাই এটি একটি রেফারেল ফিরিয়ে দেয়।

Resolver তখন একটি .com TLD সার্ভার জিজ্ঞাসা করে, যা আবার চূড়ান্ত উত্তর জানে না কিন্তু জানে কোন nameserver গুলি example.com-এর জন্য authoritative। আপনি এই ডেলিগেশন নিজে দেখতে পারেন:

dig +trace example.com

সেই কমান্ডটি প্রতিটি হপ দেখায়: root, তারপর TLD, তারপর ডোমেইনের জন্য authoritative nameserver, প্রকৃত A বা AAAA রেকর্ড দিয়ে শেষ। এটি DNS-কে তাত্ত্বিক পরিবর্তে ভিজ্যুয়ালি বুঝতে একক সেরা কমান্ড।

Authoritative nameserver চূড়ান্ত স্টপ। এটি সেই সার্ভার যা ডোমেইন মালিক আসলে কনফিগার করেছে, প্রায়শই একটি registrar-এর DNS প্যানেলের মাধ্যমে বা Route 53 বা Cloudflare DNS-এর মতো একটি সেবার মাধ্যমে। এটি পুরো চেইনে একমাত্র সার্ভার যার কাছে একটি ক্যাশ করা কপি বা রেফারেলের পরিবর্তে প্রকৃত, প্রামাণিক উত্তর আছে।

রেকর্ড টাইপ যা আপনি আসলে সামলাবেন

একটি A রেকর্ড একটি নাম IPv4 ঠিকানায় ম্যাপ করে, AAAA IPv6-এর জন্য একই কাজ করে। CNAME একটি নামকে আইপি-এর বদলে অন্য নামে নির্দেশ করে, যা কিভাবে Cloudflare বা Fastly-এর মতো CDN গুলি কাঁচা IP গুলি প্রকাশ না করে ট্রাফিক রুট করে। MX রেকর্ড মেইল রুটিং পরিচালনা করে, এবং TXT রেকর্ড নির্বিচার পাঠ বহন করে, সবচেয়ে সাধারণত এখন SPF, DKIM, এবং ডোমেইন যাচাইকরণ স্ট্রিংস-এর জন্য ব্যবহৃত। NS রেকর্ড বিশ্বকে বলে কোন সার্ভার একটি জোনের জন্য authoritative, এবং সেটি রেকর্ড টাইপ যা প্রথম স্থানে ডেলিগেশনকে সম্ভব করে।

ক্যাশিং আসলে কোথায় থাকে

ক্যাশিং একযোগে একাধিক স্তরে ঘটে: ব্রাউজার নিজে (Chrome-এর নিজস্ব DNS ক্যাশ chrome://net-internals/#dns-এ দেখা যায়), OS resolver ক্যাশ, স্থানীয় রাউটার, এবং upstream recursive resolver। এই কারণই একটি DNS পরিবর্তন একটি ডিভাইসে তাৎক্ষণিকভাবে কাজ করতে পারে এবং অন্যটিতে ঘন্টা পর্যন্ত প্রদর্শিত হতে সময় নিতে পারে — আপনি একই ক্যাশে আঘাত করছেন না।

যখন আপনি একটি পরিকল্পিত migration-এর আগে একটি রেকর্ডের TTL কমান, আপনি অবিলম্বে কিছু গতি বাড়াচ্ছেন না। আপনি শুধুমাত্র যে উইন্ডো সংকীর্ণ করছেন যেখানে একবার পরিবর্তন আসলে ঘটে stale ডেটা থাকতে পারে। Cutover-এর পাঁচ মিনিট আগে নয়, কমপক্ষে একটি TTL চক্র আগে এটি করুন।

এটি troubleshooting-এর জন্য কেন গুরুত্বপূর্ণ

যখন একটি সাইট অপৌঁছানোর যোগ্য, dig +trace আপনাকে ঠিক বলে কোন স্তর ভাঙা: একটি root/TLD সমস্যা একটি misconfigured authoritative সার্ভার বা আপনার নিজের মেশিনে একটি stale ক্যাশ থেকে সম্পূর্ণভাবে ভিন্ন দেখায়। dig example.com-কে একটি পরিচিত-ভালো resolver-এর বিরুদ্ধে তুলনা করা, যেমন dig example.com @1.1.1.1, বিচ্ছিন্ন করে সমস্যা আপনার স্থানীয় resolver বা ডোমেইনের প্রকৃত DNS সেটআপে আছে কিনা।

DNS বাইরে থেকে সরল দেখায় কারণ এটি সাধারণত 100ms-এর নিচে সমাধান করে এবং কেউ এটি নিয়ে চিন্তা করে না। নিচে, এটি একটি distributed, cached, hierarchical প্রশ্ন সিস্টেম যা 1980s থেকে কাঠামোতে বৃহত্তর অপরিবর্তিত চলছে, যা মূল ডিজাইন কত ভালো ধরে রেখেছে তার জন্য একটি সুন্দর যুক্তি।

যদি আপনি এটির সাথে আরও এগিয়ে যেতে চান, Korra Studio-র DEFENSE_GRID-এ সম্পর্কিত সেগমেন্ট রয়েছে DNS নিরাপত্তা এক্সটেনশন, exfiltration কৌশল হিসাবে DNS tunneling, এবং Python-এ আপনার নিজের resolver তৈরি করা কভার করছে।