DNS — নাম থেকে ঠিকানা, resolver আর caching

১ · নাম মানুষের জন্য, ঠিকানা যন্ত্রের জন্য — আর HOSTS.TXT থেকে DNS

পর্ব ১৬ আর ২১-এ দেখেছেন, ইন্টারনেটে প্রতিটি packet যায় IP ঠিকানা ধরে — 192.0.2.80 বা 2001:db8::80. কিন্তু কেউ ব্রাউজারে সংখ্যা লেখেন না; লেখেন www.example.com. নাম আর ঠিকানা আলাদা রাখার তিনটি বড় কারণ আছে:

• মনে রাখা: মানুষ শব্দ মনে রাখে, ১২৮ bit-এর IPv6 ঠিকানা নয়।
• বদলানোর স্বাধীনতা: একটি ওয়েবসাইট অন্য hosting-এ সরলে ঠিকানা বদলায়, নাম একই থাকে। ঠিক যেমন কেউ বাসা বদলালেও তাঁর নাম বদলায় না।
• একাধিক ঠিকানা: একটি নামের পেছনে অনেক সার্ভার থাকতে পারে — কাছেরটি বা সুস্থটি বেছে দেওয়া যায় (অংশ ৯)।

নাম থেকে ঠিকানা বের করার ব্যবস্থার নাম DNS (Domain Name System). এটি একটি application layer protocol (পর্ব ৩৪-এর application layer-এর client-server ধাঁচে), কিন্তু প্রায় সব অ্যাপ্লিকেশন কাজ শুরুর আগে এর ওপর নির্ভর করে — HTTP, ইমেইল, ভিডিও কল, সবাই।

২ · নামের গাছ — root, TLD, domain, zone আর delegation

DNS-এর নামগুলো একটি উল্টো গাছ (namespace). সবার ওপরে root — নামহীন, লেখা হয় একটি ফাঁকা বিন্দু . দিয়ে। নাম পড়া হয় ডান থেকে বাঁয়ে, গাছের গোড়া থেকে পাতার দিকে। www.example.com.-এর শেষের বিন্দুটিই root — সাধারণত আমরা লিখি না, কিন্তু সব নামের শেষে সেটি আছে। শেষ বিন্দুসহ পুরো নামকে বলে FQDN.

                       .  (root)
        ┌──────────┬───────┴──────┬──────────────┐
       com        org            bd            arpa      ← TLD
    ┌───┴───┐      │        ┌─────┼─────┐        │
 example  ...   example    com   gov   ac   in-addr  ← দ্বিতীয় স্তর
 ┌──┴──┐                    │                    │
www   mail                 ...                  ...

প্রতিটি অংশকে বলে label — www, example, com. একটি label সর্বোচ্চ ৬৩ বাইট, পুরো নাম তারে সর্বোচ্চ ২৫৫ বাইট; বড়-ছোট হাতের অক্ষরে পার্থক্য নেই (Example.COM আর example.com একই)।

TLD — গাছের প্রথম শাখা

.bd-এর কথা: বাংলাদেশের ccTLD-এ সাধারণত সরাসরি নাম.bd না দিয়ে দ্বিতীয় স্তরের অধীনে নাম দেওয়া হয় — .com.bd (ব্যবসা), .gov.bd (সরকার), .edu.bd ও .ac.bd (শিক্ষা), .org.bd, .net.bd ইত্যাদি। এটি দেশীয়ভাবে পরিচালিত; কোন শাখায় কে নাম নিতে পারবেন, কী কাগজ লাগবে — এসব নিয়ম সময়ের সাথে বদলায়, তাই নাম নেওয়ার আগে দায়িত্বপ্রাপ্ত কর্তৃপক্ষের সর্বশেষ নির্দেশনা দেখে নিন। বাংলা লিপিতে একটি IDN ccTLD-ও আছে (.বাংলা)।

Domain বনাম zone, আর delegation

Domain মানে গাছের একটি শাখা আর তার নিচের সবকিছু — example.com domain-এ আছে www.example.com, mail.example.com, এমনকি dev.eu.example.com. Zone হলো গাছের সেই অংশ, যার তথ্য একটি প্রশাসন একসাথে রাখে আর যার উত্তর একই সার্ভার-সেট দেয়। মালিক চাইলে নিচের কোনো শাখার দায়িত্ব অন্য কাউকে দিয়ে দিতে পারেন — এটিই delegation. তখন সেই শাখা নতুন একটি zone হয়।

Delegation আসলে দুটি record: ওপরের zone-এ (parent) লেখা থাকে নিচের zone-এর NS record — “example.com-এর উত্তর দেবে ns1.example.com আর ns2.example.com”. আর নিচের zone-এ (child) একই NS record থাকে, সাথে zone-এর পরিচয়পত্র SOA (অংশ ৬)। Root zone-এর ব্যবস্থাপনা IANA-র দায়িত্বে; সেখানে প্রতিটি TLD-এর delegation থাকে। কেউ একটি নাম কেনেন একটি registrar-এর মাধ্যমে, যে registry-কে জানায় কোন NS-এ delegate করতে হবে।

৩ · কে কোন কাজ করে — stub, recursive resolver, root, TLD আর authoritative

Root server-এর “১৩” সংখ্যাটি: নাম ১৩টি, যন্ত্র ১৩টি নয়। প্রায় এক ডজন আলাদা সংস্থা এই নামগুলো চালায়, আর প্রতিটি নামের পেছনে anycast দিয়ে পৃথিবীর বহু শহরে instance আছে — সব মিলিয়ে এক হাজারেরও বেশি (সর্বশেষ সংখ্যা root-servers.org-এ)। সংখ্যাটি ১৩-তে আটকে থাকার মূল কারণ পুরোনো ৫১২ বাইটের UDP উত্তরে সবার নাম-ঠিকানা আঁটানো। Anycast কীভাবে একই ঠিকানাকে বহু জায়গায় বসায়, তা পর্ব ২৫-এ (BGP) দেখেছেন। প্রতিটি recursive resolver-এ root server-দের ঠিকানার একটি ছোট তালিকা আগে থেকে দেওয়া থাকে (root hints) — নইলে প্রথম প্রশ্ন কাকে করবে?

Recursive resolver কোথা থেকে আসে? বাসায় Wi-Fi-তে যুক্ত হলে DHCP সাধারণত router বা ISP-র resolver-এর ঠিকানা দেয় (পর্ব ১৮, DHCP আর ARP). অনেকে হাতে public resolver বসান — বড় কোম্পানি বা অলাভজনক সংস্থার চালানো, anycast-এ ছড়ানো resolver. এখানে একটি বাণিজ্যিক বিনিময় আছে: আপনার সব নাম-খোঁজা resolver-চালকের চোখে পড়ে, তাই কার resolver ব্যবহার করছেন, তা গোপনীয়তার সিদ্ধান্তও (অংশ ৯)।

৪ · ধাপে ধাপে খোঁজা — iterative বনাম recursive

পরীক্ষার সবচেয়ে প্রিয় ছবি: একটি ল্যাপটপ প্রথমবার www.example.com খুঁজছে, resolver-এর cache সম্পূর্ণ ফাঁকা। দুই রকম প্রশ্ন আছে। Recursive query-তে প্রশ্নকারী বলে “পুরো উত্তর এনে দিন” — stub resolver এভাবেই resolver-কে জিজ্ঞেস করে। Iterative query-তে সার্ভার যা জানে তা-ই বলে — উত্তর বা পরের ঠিকানা (referral); resolver নিজে পরের জনকে জিজ্ঞেস করে। Root আর TLD সার্ভার শুধু iterative উত্তর দেয় — লাখো resolver-এর হয়ে খুঁজতে গেলে তারা ডুবে যেত।

Recursive বনাম iterative — তুলনা ও হিসাব

পাঠ্যবইয়ে একটি দ্বিতীয় ছবিও থাকে: সব সার্ভার recursive হলে resolver root-কে, root TLD-কে, TLD authoritative-কে জিজ্ঞেস করে, আর উত্তর একই পথে ফেরে। তখনো বার্তা ৮টি (stub ↔ resolver ২টি, তারপর তিন জোড়া চেইনে) — কিন্তু root আর TLD-কে প্রতিটি অনুরোধের অবস্থা মনে রাখতে হতো। বাস্তবে তাই root ও TLD শুধু iterative.

৫ · Caching আর TTL — প্রতিটি স্তরে খাতায় টুকে রাখা

প্রতিটি নাম-খোঁজায় ৮টি বার্তা লাগলে root server-গুলো এক সেকেন্ডও টিকত না। DNS টিকে আছে cache-এর জোরে। প্রতিটি record-এর সাথে থাকে একটি TTL — সেকেন্ডে, “এই উত্তর কতক্ষণ মনে রাখা যাবে”। (নামটি IP header-এর TTL-এর মতো হলেও মানে আলাদা: সেখানে hop গোনা, এখানে সময়।) TTL ঠিক করেন zone-এর মালিক, আর cache-এ থাকা সময়ে resolver উত্তর দেওয়ার সময় বাকি TTL কমিয়ে জানায়।

Cache থাকে অনেক জায়গায়: ব্রাউজারের ভেতরে, OS-এর stub-এ (systemd-resolved, Windows DNS Client), বাসার router-এ, ISP-র resolver-এ। সবচেয়ে বড় প্রভাব resolver-এর cache-এর — হাজারো গ্রাহক একই resolver ব্যবহার করেন, তাই জনপ্রিয় নাম প্রায় সবসময় সেখানে তৈরি থাকে।

নিচের simulator একটি ছোট নকল জগৎ: root, .com TLD আর ns1.example.com. এখানে www.example.com একটি CNAME — আসল নাম web.example.com, যার A record-এর TTL ৩০০. একই zone-এ থাকায় authoritative সার্ভার একই উত্তরে CNAME আর A দুটোই দেয়। Simulator চারটি সময়ে খোঁজে, আর একটি অস্তিত্বহীন নাম দিয়ে negative caching দেখায়। (ঠিকানাগুলো documentation ব্লকের, কাল্পনিক।)

// Iterative resolution over a mock hierarchy, with a TTL cache (all addresses are documentation IPs).
const SERVERS = {
  "root": { "com.": ["REFERRAL", "a.gtld-servers.net", "192.0.2.30", 172800] },
  "a.gtld-servers.net": { "example.com.": ["REFERRAL", "ns1.example.com", "203.0.113.53", 172800] },
  "ns1.example.com": { "www.example.com.": ["CNAME", "web.example.com.", 3600],
                       "web.example.com.": ["A", "192.0.2.80", 300], "SOA-MIN": 900 } };
const cache = new Map(); let sent = 0;                    // key "name type" -> {type, data, exp}
const get = (k, now) => { const e = cache.get(k); return e && e.exp > now ? e : null; };
const put = (name, type, data, ttl, now) => cache.set(name + " " + type, { type, data, exp: now + ttl });
function lookup(name, now) {
  for (;;) {
    const hit = get(name + " A", now) || get(name + " CNAME", now) || get(name + " NEG", now);
    if (hit) { console.log(`  cache HIT  ${name} ${hit.type} ${hit.data} (ttl left ${hit.exp - now}s)`);
      if (hit.type !== "CNAME") return hit.data; name = hit.data; continue; }
    const zone = ["example.com.", "com."].find(z => name.endsWith(z) && get(z + " NS", now));
    let server = zone ? get(zone + " NS", now).data : "root"; console.log(`  cache MISS ${name} -> ask ${server}`);
    for (;;) {
      const zd = SERVERS[server], key = Object.keys(zd).find(k => name.endsWith(k)); sent += 2;  // query + reply
      let rr = zd["SOA-MIN"] ? zd[name] : zd[key];
      if (!rr) { console.log(`    ${server}: NXDOMAIN, SOA minimum ${zd["SOA-MIN"]}s`);
        put(name, "NEG", "NXDOMAIN", zd["SOA-MIN"], now); return "NXDOMAIN"; }
      if (rr[0] === "REFERRAL") {
        console.log(`    ${server}: referral ${key} NS ${rr[1]} (glue ${rr[2]}) ttl=${rr[3]}`);
        put(key, "NS", rr[1], rr[3], now); server = rr[1]; continue; }
      for (; rr; rr = zd[name]) {                         // answer; in-zone CNAME target comes in the same reply
        console.log(`    ${server}: answer AA ${name} ${rr[0]} ${rr[1]} ttl=${rr[2]}`);
        put(name, rr[0], rr[1], rr[2], now);
        if (rr[0] === "A") return rr[1]; name = rr[1];
      } break;                                            // CNAME pointed outside this zone: start again
    }
  }
}
for (const [t, n] of [[0, "www"], [100, "www"], [400, "www"], [410, "nope"], [500, "nope"]]) {
  const before = sent; console.log(`t=${t}s lookup ${n}.example.com.`);
  console.log(`  => ${lookup(n + ".example.com.", t)}   (resolver<->server messages: ${sent - before})`); }

t=0s lookup www.example.com.
  cache MISS www.example.com. -> ask root
    root: referral com. NS a.gtld-servers.net (glue 192.0.2.30) ttl=172800
    a.gtld-servers.net: referral example.com. NS ns1.example.com (glue 203.0.113.53) ttl=172800
    ns1.example.com: answer AA www.example.com. CNAME web.example.com. ttl=3600
    ns1.example.com: answer AA web.example.com. A 192.0.2.80 ttl=300
  => 192.0.2.80   (resolver<->server messages: 6)
t=100s lookup www.example.com.
  cache HIT  www.example.com. CNAME web.example.com. (ttl left 3500s)
  cache HIT  web.example.com. A 192.0.2.80 (ttl left 200s)
  => 192.0.2.80   (resolver<->server messages: 0)
t=400s lookup www.example.com.
  cache HIT  www.example.com. CNAME web.example.com. (ttl left 3200s)
  cache MISS web.example.com. -> ask ns1.example.com
    ns1.example.com: answer AA web.example.com. A 192.0.2.80 ttl=300
  => 192.0.2.80   (resolver<->server messages: 2)
t=410s lookup nope.example.com.
  cache MISS nope.example.com. -> ask ns1.example.com
    ns1.example.com: NXDOMAIN, SOA minimum 900s
  => NXDOMAIN   (resolver<->server messages: 2)
t=500s lookup nope.example.com.
  cache HIT  nope.example.com. NEG NXDOMAIN (ttl left 810s)
  => NXDOMAIN   (resolver<->server messages: 0)

“DNS propagation” বলে কিছু নেই — আছে TTL

Hosting বদলালে প্রায়ই শোনা যায় “DNS propagate হতে ২৪–৪৮ ঘণ্টা লাগবে”। আসলে কোনো হালনাগাদ কোথাও “ছড়ায়” না। Authoritative সার্ভারে record বদলানো মাত্রই নতুন উত্তর দেওয়া শুরু হয়; পুরোনো উত্তর টিকে থাকে শুধু সেই resolver-গুলোতে, যারা আগে এটি cache করেছিল — সর্বোচ্চ পুরোনো TTL পর্যন্ত। তাই পেশাদারেরা বদলের এক-দুই দিন আগে TTL কমিয়ে (যেমন ৩০০) রাখেন, বদলান, তারপর আবার বাড়ান। NS বদলের সময় parent zone-এর NS TTL (প্রায়ই দুই দিন) গুরুত্বপূর্ণ — সেটি আপনার হাতে নেই। কিছু resolver নিজের নিয়মে TTL-এর সর্বনিম্ন বা সর্বোচ্চ সীমা বসায়, তাই বাস্তবে সামান্য ব্যতিক্রম দেখা যায়।

৬ · Resource record — A থেকে HTTPS পর্যন্ত

Zone-এর প্রতিটি তথ্য একটি resource record (RR): নাম TTL class type ডেটা. Class প্রায় সবসময় IN (Internet). একটি ছোট zone ফাইল (BIND-এর প্রচলিত লেখার ধাঁচে):

$ORIGIN example.com.
$TTL 3600
@     IN SOA  ns1.example.com. hostmaster.example.com. (
              2026102601 ; serial
              7200       ; refresh (2 h)
              900        ; retry (15 min)
              1209600    ; expire (14 days)
              300 )      ; minimum = negative-caching TTL
@     IN NS    ns1.example.com.
@     IN NS    ns2.example.net.
@     IN A     192.0.2.80
@     IN AAAA  2001:db8::80
www   IN CNAME web.example.com.
web   300 IN A 192.0.2.80
@     IN MX    10 mail.example.com.
mail  IN A     192.0.2.25
@     IN TXT   "v=spf1 mx -all"
_sip._tcp IN SRV 10 60 5060 sip.example.com.
@     IN CAA   0 issue "ca.example.net"
ns1   IN A     203.0.113.53
80.2.0.192.in-addr.arpa. IN PTR web.example.com.  ; থাকে reverse zone-এ, এখানে শুধু দেখানোর জন্য

CNAME-এর নিয়ম আর apex-এর সমস্যা

নিয়ম: যে নামে CNAME আছে, সেখানে আর কোনো record থাকতে পারবে না — কারণ CNAME মানে “এই নামের সব প্রশ্ন ওই নামে যান”। কিন্তু zone-এর মূল নামে (apex, যেমন খালি example.com) সবসময় SOA আর NS থাকে। তাই example.com-এ CNAME বসানো যায় না — অথচ CDN-গুলো চায় গ্রাহক একটি CNAME দিয়ে তাদের দিকে নির্দেশ করুক। সমাধান: অনেক DNS সেবাদাতার নিজস্ব “ALIAS/ANAME” বা CNAME flattening — authoritative সার্ভার নিজেই লক্ষ্য-নামের A/AAAA খুঁজে apex-এ বসিয়ে দেয় (এটি মান নয়, সেবাদাতা ভেদে আচরণ আলাদা)। নতুন মানসম্মত পথ HTTPS record-এর “alias mode”, তবে সব ক্লায়েন্ট এখনো তা ব্যবহার করে না।

SOA-র সংখ্যাগুলো — primary আর secondary

একটি zone সাধারণত একটি primary সার্ভারে সম্পাদিত হয় আর এক বা একাধিক secondary সার্ভার কপি রাখে (zone transfer). SOA-র সংখ্যাগুলো secondary-কে নিয়ম বলে দেয়:

Refresh-এর অপেক্ষা না করে primary বদলের খবর সাথে সাথে জানাতে পারে NOTIFY বার্তায় (RFC 1996); তখন secondary serial দেখে বড় হলে transfer চায়।

Reverse DNS — ঠিকানা থেকে নাম

কখনো উল্টো প্রশ্ন লাগে: “192.0.2.10 কার?” — log পড়ার সময়, traceroute-এ router-এর নাম দেখাতে, মেইল সার্ভার যাচাইয়ে। DNS নাম ধরে খোঁজে, তাই ঠিকানাকে একটি বিশেষ নামে রূপ দেওয়া হয়। IPv4-এ অক্টেটগুলো উল্টো ক্রমে লিখে শেষে .in-addr.arpa: 10.2.0.192.in-addr.arpa. উল্টো কেন? DNS নাম ডান দিকে সাধারণ (গাছের গোড়া), বাঁয়ে নির্দিষ্ট; IP ঠিকানা বাঁ দিকে সাধারণ (network), ডানে নির্দিষ্ট (host). উল্টালে দুটি মিলে যায়, আর 192.0.2.0/24-এর মালিককে 2.0.192.in-addr.arpa zone delegate করা যায়। IPv6-এ প্রতিটি hex অঙ্ক (nibble) একটি label, উল্টো ক্রমে, শেষে .ip6.arpa (RFC 3596). Reverse DNS-এর record হলো PTR.

// Build reverse-DNS (PTR) names for IPv4 and IPv6 - documentation addresses only.
function ptr4(ip) {
  return ip.split(".").reverse().join(".") + ".in-addr.arpa.";
}
function expand6(ip) {                              // "2001:db8::5" -> 8 groups of 4 hex digits
  const [head, tail] = ip.split("::");
  const h = head ? head.split(":") : [], t = tail !== undefined && tail ? tail.split(":") : [];
  const zeros = tail === undefined ? [] : Array(8 - h.length - t.length).fill("0");
  return [...h, ...zeros, ...t].map(g => g.padStart(4, "0"));
}
function ptr6(ip) {
  const nibbles = expand6(ip).join("").split("");  // 32 hex digits, one label each
  return nibbles.reverse().join(".") + ".ip6.arpa.";
}
for (const ip of ["192.0.2.10", "198.51.100.53", "203.0.113.7"])
  console.log(ip.padEnd(15), "->", ptr4(ip));
console.log("zone for 192.0.2.0/24     ->", ptr4("192.0.2"));
for (const ip of ["2001:db8::1", "2001:db8:abcd:12::567:89ab"]) {
  console.log("\n" + ip);
  console.log("  expanded :", expand6(ip).join(":"));
  const name = ptr6(ip);
  console.log("  PTR name :", name);
  console.log("  labels   :", name.split(".").length - 1, "(32 nibbles + ip6 + arpa)");
}
console.log("\nzone for 2001:db8::/32     ->", ptr6("2001:db8::").slice(-25));

192.0.2.10      -> 10.2.0.192.in-addr.arpa.
198.51.100.53   -> 53.100.51.198.in-addr.arpa.
203.0.113.7     -> 7.113.0.203.in-addr.arpa.
zone for 192.0.2.0/24     -> 2.0.192.in-addr.arpa.

2001:db8::1
  expanded : 2001:0db8:0000:0000:0000:0000:0000:0001
  PTR name : 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
  labels   : 34 (32 nibbles + ip6 + arpa)

2001:db8:abcd:12::567:89ab
  expanded : 2001:0db8:abcd:0012:0000:0000:0567:89ab
  PTR name : b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.2.1.0.0.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa.
  labels   : 34 (32 nibbles + ip6 + arpa)

zone for 2001:db8::/32     -> 8.b.d.0.1.0.0.2.ip6.arpa.

৭ · DNS বার্তার ভেতরে — header, চারটি section আর compression

প্রশ্ন আর উত্তরের গঠন একই (RFC 1035): ১২ বাইটের header, তারপর চারটি section.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5   (bit)
┌───────────────────────────────┐
│              ID               │  byte 0-1
├─┬───────┬─┬─┬─┬─┬─┬─┬─┬───────┤
│Q│Opcode │A│T│R│R│Z│A│C│ RCODE │  byte 2-3
│R│       │A│C│D│A│ │D│D│       │
├─┴───────┴─┴─┴─┴─┴─┴─┴─┴───────┤
│QDCOUNT│ANCOUNT│NSCOUNT│ARCOUNT│  byte 4-11 (2 bytes each)
├───────────────────────────────┤
│ Question   (name, type, class)│
│ Answer     (RR …)             │
│ Authority  (NS, SOA …)        │
│ Additional (glue, OPT …)      │
└───────────────────────────────┘

• ID (১৬ bit) — প্রশ্নকারী বাছে, উত্তরে হুবহু ফেরত আসে; এ দিয়েই উত্তর প্রশ্নের সাথে মেলে।
• QR 0 = প্রশ্ন, 1 = উত্তর। Opcode 0 = সাধারণ প্রশ্ন। AA authoritative উত্তর। TC উত্তর কাটা পড়েছে (truncation) — TCP-তে আবার জিজ্ঞেস করুন। RD recursion চাই, RA recursion দেওয়া যায়। AD/CD DNSSEC-এর জন্য। RCODE: 0 NOERROR, 2 SERVFAIL, 3 NXDOMAIN, 5 REFUSED.
• চারটি count — প্রতিটি section-এ কয়টি entry.
• নাম লেখার নিয়ম: প্রতিটি label-এর আগে তার দৈর্ঘ্যের একটি বাইট, শেষে 00 (root-এর ফাঁকা label). বিন্দু তারে যায় না। www.example.com = 03 'www' 07 'example' 03 'com' 00 = ১৭ বাইট।

একই নাম একটি উত্তরে বারবার আসে (প্রশ্নে, প্রতিটি answer-এ, authority-তে)। জায়গা বাঁচাতে আছে name compression: দৈর্ঘ্য-বাইটের ওপরের দুই bit 11 হলে (অর্থাৎ বাইট 0xC0 বা তার বেশি) সেটি label নয়, একটি pointer — পরের ১৪ bit বার্তার শুরু থেকে একটি offset, “বাকি নাম ওখান থেকে পড়ুন”। c0 0c মানে offset ১২ — ঠিক যেখানে প্রশ্নের নাম শুরু (header ১২ বাইট)। এজন্য উত্তরে c0 0c প্রায় সবসময় দেখবেন।

নিচের প্রোগ্রাম প্রথমে হাতে একটি প্রশ্ন বানায় (ID 0x1a2b, RD = 1, www.example.com A), তারপর একটি হাতে-বানানো উত্তর পড়ে — যেখানে CNAME-এর ডেটা আর দ্বিতীয় answer-এর নাম দুটোই pointer দিয়ে লেখা।

// Build a DNS query by hand, then parse a hand-made response that uses compression pointers.
const hx = a => a.map(b => b.toString(16).padStart(2, "0")).join(" ");
const u16 = (m, o) => m[o] << 8 | m[o + 1];
const encName = n => [...n.split(".").flatMap(l => [l.length, ...[...l].map(c => c.charCodeAt(0))]), 0];
const q = [0x1a, 0x2b, 0x01, 0x00, 0, 1, 0, 0, 0, 0, 0, 0, ...encName("www.example.com"), 0, 1, 0, 1];
console.log(`QUERY (${q.length} bytes)\n header:     ${hx(q.slice(0, 12))}\n qname:      ${hx(q.slice(12, 29))}\n type/class: ${hx(q.slice(29))}`);
function readName(m, o, path) {                       // returns [name, offset after the name]
  const labels = []; let end = -1;
  while (m[o] !== 0) {
    if ((m[o] & 0xc0) === 0xc0) {                     // two top bits 11 -> 14-bit pointer
      const to = u16(m, o) & 0x3fff; path.push(`ptr@${o}->${to}`);
      if (end < 0) end = o + 2; o = to; continue;
    }
    labels.push(String.fromCharCode(...m.slice(o + 1, o + 1 + m[o]))); o += m[o] + 1;
  }
  return [labels.join(".") + ".", end < 0 ? o + 1 : end];
}
// response: same id, flags 8180, 1 question, 2 answers (CNAME, then A) - names compressed
const r = [0x1a, 0x2b, 0x81, 0x80, 0, 1, 0, 2, 0, 0, 0, 0, ...q.slice(12),
  0xc0, 0x0c, 0, 5, 0, 1, 0, 0, 0x0e, 0x10, 0, 6, 3, 0x77, 0x65, 0x62, 0xc0, 0x10,
  0xc0, 0x2d, 0, 1, 0, 1, 0, 0, 0x01, 0x2c, 0, 4, 192, 0, 2, 80];
const f = u16(r, 2);
console.log(`\nRESPONSE (${r.length} bytes) id=0x${u16(r, 0).toString(16)} flags=0x${f.toString(16)}`);
console.log(` QR=${f >> 15} opcode=${f >> 11 & 15} AA=${f >> 10 & 1} TC=${f >> 9 & 1} RD=${f >> 8 & 1} RA=${f >> 7 & 1} RCODE=${f & 15}`);
console.log(` counts: QD=${u16(r, 4)} AN=${u16(r, 6)} NS=${u16(r, 8)} AR=${u16(r, 10)}`);
let [qn, o] = readName(r, 12, []);
console.log(` question: ${qn} type=${u16(r, o)} class=${u16(r, o + 2)}`); o += 4;
for (let i = 0; i < u16(r, 6); i++) {
  const path = [], start = o; let name; [name, o] = readName(r, o, path);
  const type = u16(r, o), ttl = u16(r, o + 4) * 65536 + u16(r, o + 6), len = u16(r, o + 8), rd = o + 10;
  const data = type === 1 ? r.slice(rd, rd + 4).join(".") : readName(r, rd, path)[0];
  console.log(` answer@${start}: ${name} ${type === 1 ? "A" : "CNAME"} ttl=${ttl} rdlen=${len} -> ${data}  [${path.join(", ")}]`);
  o = rd + len;
}

QUERY (33 bytes)
 header:     1a 2b 01 00 00 01 00 00 00 00 00 00
 qname:      03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00
 type/class: 00 01 00 01

RESPONSE (67 bytes) id=0x1a2b flags=0x8180
 QR=1 opcode=0 AA=0 TC=0 RD=1 RA=1 RCODE=0
 counts: QD=1 AN=2 NS=0 AR=0
 question: www.example.com. type=1 class=1
 answer@33: www.example.com. CNAME ttl=3600 rdlen=6 -> web.example.com.  [ptr@33->12, ptr@49->16]
 answer@51: web.example.com. A ttl=300 rdlen=4 -> 192.0.2.80  [ptr@51->45, ptr@49->16]

UDP 53, TCP 53, আর zone transfer

সাধারণ প্রশ্ন-উত্তর যায় UDP port 53-এ — একটি প্রশ্ন, একটি উত্তর, handshake নেই। উত্তর বড় হলে সার্ভার TC bit বসায়, আর ক্লায়েন্ট একই প্রশ্ন TCP port 53-এ আবার করে। TCP-তে প্রতিটি বার্তার আগে ২ বাইটের দৈর্ঘ্য থাকে (TCP-র byte stream-এ সীমানা চিহ্ন)। আজ TCP সমর্থন ঐচ্ছিক নয়, বাধ্যতামূলক (RFC 7766). পুরোনো ৫১২ বাইটের সীমা, EDNS(0), ১,২৩২ বাইটের পরামর্শ আর retry-র timeout — এগুলো পর্ব ২৮-এ (UDP) বিস্তারিত দেখেছেন। পুরো zone কপি করা (AXFR) বা শুধু বদলগুলো (IXFR) সবসময় TCP-তে, কারণ ডেটা বড় আর নির্ভরযোগ্যভাবে পৌঁছাতে হবে। AXFR শুধু নিজের secondary-দের জন্য খোলা রাখুন (ঠিকানা-তালিকা বা TSIG key দিয়ে) — নইলে যে-কেউ পুরো zone-এর তালিকা নামিয়ে নিতে পারে।

৮ · Linux-এ নাম খোঁজা — /etc/hosts, nsswitch.conf আর resolv.conf

একটি প্রোগ্রাম নাম দিয়ে সংযোগ করতে চাইলে সাধারণত ডাকে getaddrinfo(). Linux-এর glibc তখন তিনটি ফাইল দেখে:

1. /etc/nsswitch.conf — কোন উৎস কোন ক্রমে দেখা হবে। প্রচলিত লাইন hosts: files dns: আগে ফাইল, তারপর DNS. systemd-ভিত্তিক distro-তে প্রায়ই files mdns4_minimal [NOTFOUND=return] resolve dns-এর মতো লম্বা লাইন দেখবেন।
2. /etc/hosts — হাতে লেখা নাম-ঠিকানার ছোট তালিকা, HOSTS.TXT-এর উত্তরসূরি। এখানে থাকলে DNS-এ প্রশ্নই যায় না — পরীক্ষার জন্য সুবিধাজনক, ভুলে গেলে রহস্যময়।
3. /etc/resolv.conf — DNS-এর পালা এলে কোন resolver-কে জিজ্ঞেস করবে: nameserver (glibc সর্বোচ্চ ৩টি ব্যবহার করে, ক্রমানুসারে), search (ছোট নামের পেছনে যোগ করার domain), আর options (timeout: ডিফল্ট ৫ সেকেন্ড, attempts: ডিফল্ট ২, ndots:)। systemd-resolved থাকলে এখানে প্রায়ই nameserver 127.0.0.53 — আসল resolver-এর তালিকা দেখায় resolvectl status.

নিচের স্ক্রিপ্ট এই রানারে ফাইলগুলো পড়ে, getent দিয়ে glibc-র একই পথে localhost খোঁজে, তারপর একটি পাবলিক নাম আর একটি অস্তিত্বহীন নাম খোঁজে। এই রানার একটি sandbox — সাধারণ বাইরের সংযোগ এখানে ধরে নেওয়া যায় না, তাই ফল যা-ই হোক, স্ক্রিপ্ট সুন্দরভাবে জানায় আর সর্বোচ্চ ৮ সেকেন্ড অপেক্ষা করে। গোপনীয়তার জন্য স্ক্রিপ্ট নিজেই loopback, 10.0.2.x আর IPv6-এর স্থানীয় ঠিকানা ছাড়া সব ঠিকানা, search domain আর host-এর নিজস্ব নাম ঢেকে দেয়।

private() { case "$1" in 127.*|10.0.2.*|::1|fd*|fe80:*|ff0*|fe00:*) return 0;; esac; return 1; }
echo "== 1. /etc/resolv.conf (which resolver? which options?) =="
if [ -r /etc/resolv.conf ]; then
  grep -Ev '^[[:space:]]*(#|;|$)' /etc/resolv.conf | while read -r key val rest; do
    case "$key" in
      nameserver) private "$val" || val="<resolver-IP>";;
      search|domain) val="<search-domain>"; rest="";;
    esac
    echo "  $key $val${rest:+ $rest}"
  done
else echo "  (resolv.conf নেই)"; fi
echo "== 2. /etc/hosts (the local name table) =="
if [ -r /etc/hosts ]; then
  grep -Ev '^[[:space:]]*(#|$)' /etc/hosts | while read -r ip names; do
    private "$ip" || ip="<host-IP>"; case "$names" in *localhost*|ip6-*) ;; *) names="<hostname>";; esac
    echo "  $ip $names"
  done
else echo "  (hosts নেই)"; fi
echo "== 3. lookup order (/etc/nsswitch.conf) =="
grep '^hosts:' /etc/nsswitch.conf 2>/dev/null || echo "  (nsswitch.conf নেই -> glibc default: files, then dns)"
echo "== 4. getent hosts localhost (uses the same order as programs) =="
getent hosts localhost || echo "  not found"
echo "== 5. DNS tools here? =="
for t in dig nslookup host resolvectl; do command -v "$t" >/dev/null && echo "  $t: আছে" || echo "  $t: নেই"; done
echo "== 6. two names through DNS =="
for name in example.com does-not-exist.invalid; do
  out=$(timeout 8 getent ahosts "$name"); rc=$?
  case $rc in
    0) echo "  $name: found, $(echo "$out" | awk '{print $1}' | sort -u | wc -l) distinct addresses (not shown)";;
    2) echo "  $name: exit 2 = name not found";;
    124) echo "  $name: exit 124 = no reply within 8 s";;
    *) echo "  $name: exit $rc = lookup failed";;
  esac
done

== 1. /etc/resolv.conf (which resolver? which options?) ==
  nameserver 10.0.2.3
  nameserver <resolver-IP>
  nameserver <resolver-IP>
  nameserver <resolver-IP>
  nameserver <resolver-IP>
== 2. /etc/hosts (the local name table) ==
  127.0.1.1 <hostname>
  127.0.0.1 localhost
  ::1 localhost ip6-localhost ip6-loopback
  ff02::1 ip6-allnodes
  ff02::2 ip6-allrouters
  <host-IP> <hostname>
  10.0.2.100 <hostname>
== 3. lookup order (/etc/nsswitch.conf) ==
hosts:          files dns
== 4. getent hosts localhost (uses the same order as programs) ==
::1             localhost ip6-localhost ip6-loopback
== 5. DNS tools here? ==
  dig: নেই
  nslookup: নেই
  host: নেই
  resolvectl: নেই
== 6. two names through DNS ==
  example.com: found, 4 distinct addresses (not shown)
  does-not-exist.invalid: exit 2 = name not found

একটি সাধারণ Linux ল্যাপটপে (ইন্টারনেট আছে, dig ইনস্টল করা) একই প্রশ্নের চেহারা এরকম — header-এর flag আর section-গুলো অংশ ৭-এর সাথে মিলিয়ে দেখুন:

$ dig www.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6699
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.example.com.               IN      A

;; ANSWER SECTION:
www.example.com.        3543    IN      CNAME   web.example.com.
web.example.com.        243     IN      A       192.0.2.80

;; Query time: 3 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; MSG SIZE  rcvd: 78

TTL ৩,৫৪৩ আর ২৪৩ — দুটোই মূল মান (৩,৬০০ আর ৩০০) থেকে ৫৭ সেকেন্ড কম, অর্থাৎ উত্তরটি cache থেকে, কেউ প্রায় এক মিনিট আগে এটি এনেছিল। আকার ৭৮ বাইট: অংশ ৭-এর ৬৭ বাইটের উত্তর আর EDNS-এর ১১ বাইটের OPT record. aa flag নেই — authoritative নয়। dig +trace www.example.com নিজেই root থেকে ধাপে ধাপে খোঁজে (stepper ১-এর মতো), dig -x 192.0.2.80 PTR খোঁজে, আর dig @ns1.example.com example.com SOA একটি নির্দিষ্ট সার্ভারকে সরাসরি জিজ্ঞেস করে।

PS> Resolve-DnsName www.example.com -Type A     # dig-এর মতো, Windows-এ
PS> nslookup www.example.com                     # পুরোনো, Windows আর macOS দুটোতেই
PS> ipconfig /displaydns                         # Windows-এর stub cache দেখা
PS> ipconfig /flushdns                           # সেই cache মুছে ফেলা
# hosts ফাইল: C:\Windows\System32\drivers\etc\hosts

Linux-এ systemd-resolved-এর cache মুছতে resolvectl flush-caches; macOS-এ সাধারণত sudo dscacheutil -flushcache আর sudo killall -HUP mDNSResponder (সংস্করণ ভেদে একটু আলাদা)। মনে রাখবেন, নিজের যন্ত্রের cache মুছলেও ISP-র resolver-এর cache থেকে যায়।

৯ · Load balancing, নিরাপত্তা, গোপনীয়তা আর সমস্যা খোঁজা

DNS দিয়ে ট্রাফিক ভাগ করা

একটি নামের একাধিক A record থাকলে সার্ভার প্রতিবার ক্রম ঘুরিয়ে দিতে পারে — round-robin DNS, সবচেয়ে সরল load balancing. তবে DNS জানে না কোন সার্ভার মরে গেছে, আর cache-এর কারণে ভাগ সমান হয় না। আরও বুদ্ধিমান authoritative সার্ভার প্রশ্নকারী resolver-এর অবস্থান দেখে কাছের data center-এর ঠিকানা দেয়, অসুস্থ সার্ভার বাদ দেয় — CDN-গুলো ঠিক এভাবে ব্যবহারকারীকে কাছের সার্ভারে পাঠায় (পর্ব ৩৮, web cache আর CDN). এখানে ছোট TTL (৩০–৩০০ সেকেন্ড) জরুরি, যাতে সিদ্ধান্ত দ্রুত বদলানো যায়।

Cache poisoning — জাল উত্তর বিশ্বাস করানো

UDP-তে resolver একটি উত্তর গ্রহণ করে যদি তা ঠিক সার্ভারের ঠিকানা থেকে, ঠিক port-এ, ঠিক ID নিয়ে আসে। কেউ যদি আসল উত্তরের আগে এগুলো অনুমান করে জাল উত্তর পাঠাতে পারে, resolver সেটি cache-এ রেখে TTL ধরে হাজারো ব্যবহারকারীকে ভুল ঠিকানা দেবে — cache poisoning. ২০০৮ সালে Dan Kaminsky দেখান যে অস্তিত্বহীন উপ-নাম দিয়ে এই অনুমানের সুযোগ প্রায় অসীমবার পাওয়া যায়, ফলে শুধু ১৬ bit-এর ID-র ওপর নির্ভর করা বিপজ্জনক (ইতিহাসটি পর্ব ২৮-এর ভাবনার প্রশ্নে আছে)। প্রতিরক্ষা স্তরে স্তরে:

• এলোমেলো ID আর এলোমেলো উৎস port (source port randomization) — অনুমানের জায়গা কয়েক হাজার গুণ বাড়ে (RFC 5452).
• 0x20 encoding — প্রশ্নের নামে বড়-ছোট অক্ষর এলোমেলো মেশানো (wWw.ExAmPle.cOm); DNS case-insensitive হলেও উত্তরে প্রশ্নের হুবহু বানান ফেরে, তাই জাল উত্তরকে সেটাও অনুমান করতে হয়। সব resolver এটি ব্যবহার করে না।
• Bailiwick যাচাই — example.com-এর সার্ভারের উত্তরে অন্য domain-এর record এলে বিশ্বাস না করা।
• DNSSEC — শেষ কথা: cryptographic স্বাক্ষর।

DNSSEC-এর বিশ্বাসের শিকল — ধারণা

DNSSEC (মূল মান RFC 4033–4035, ২০০৫) record গোপন করে না, শুধু প্রমাণ করে যে record zone-মালিকের লেখা আর পথে বদলায়নি। প্রতিটি record-সেটের সাথে একটি স্বাক্ষর RRSIG; স্বাক্ষর যাচাইয়ের public key থাকে zone-এর DNSKEY record-এ। কিন্তু সেই key-কে বিশ্বাস কেন? কারণ parent zone-এ (.com) child-এর key-এর একটি hash রাখা থাকে — DS record, যা parent নিজের key দিয়ে স্বাক্ষর করে। এভাবে example.com-এর key-কে নিশ্চিত করে .com, .com-কে root, আর root-এর key resolver-এ আগে থেকে বসানো থাকে (trust anchor; root zone ২০১০ সালে স্বাক্ষরিত হয়) — এটিই chain of trust. যাচাই সফল হলে resolver উত্তরে AD bit বসায়; ব্যর্থ হলে SERVFAIL দেয়। বিস্তারিত cryptography পর্ব ৪৭–৪৮-এ, আক্রমণের প্রেক্ষাপট পর্ব ৫০-এ।

গোপনীয়তা — DoT, DoH, QNAME minimisation আর filtering

সাধারণ DNS এনক্রিপ্ট করা নয়: পথের যে-কেউ (Wi-Fi-র মালিক, ISP) দেখতে পারেন আপনি কোন নাম খুঁজছেন, এমনকি বদলেও দিতে পারেন। সমাধানগুলো:

লক্ষ করুন, DoT/DoH আর DNSSEC দুটি আলাদা সমস্যার সমাধান: প্রথমটি পথের গোপনীয়তা (stub ↔ resolver), দ্বিতীয়টি তথ্যের সত্যতা (মালিক থেকে resolver পর্যন্ত)। আর DNS এনক্রিপ্ট করলেও যে ঠিকানায় পরে সংযোগ হয়, আর TLS-এর SNI (পর্ব ৪৮) থেকে অনেক কিছু বোঝা যায়।

সমস্যা খোঁজা — NXDOMAIN, SERVFAIL, timeout আর পুরোনো cache

“সাইট খুলছে না, DNS-এর সমস্যা মনে হচ্ছে” — প্রথমে বুঝুন কোন সমস্যা। তিনটি ফল দেখতে একই রকম (“not found”), কিন্তু কারণ সম্পূর্ণ আলাদা:

একটি পদ্ধতি: (১) getent hosts নাম — OS কী দেখছে (hosts ফাইলসহ); (২) dig নাম — resolver কী দিচ্ছে, status আর TTL; (৩) dig @অন্য-resolver নাম — সমস্যা কি শুধু আপনার resolver-এ; (৪) dig +trace নাম — গাছের কোন ধাপে ভাঙছে; (৫) নাম ছাড়া সরাসরি IP-তে সংযোগ — DNS আদৌ দায়ী কি না। পদ্ধতিগত সমস্যা-খোঁজা পর্ব ৫৫-এ।

১০ · AI-এর যুগে DNS — record, কমান্ড আর নিরাপত্তার পরামর্শ যাচাই

“আমার domain-এর DNS ঠিক করে দিন” — AI দ্রুত zone ফাইল বা dig কমান্ড লিখে দেবে। কিন্তু DNS-এর ভুল সাথে সাথে ধরা পড়ে না; TTL-এর কারণে ঘণ্টা বা দিন পরে, অন্য কারও resolver-এ। AI-এর পরিচিত ভুলগুলো:

AI-এর DNS পরামর্শ ব্যবহারের আগে — চেকলিস্ট

• Zone ফাইল named-checkzone (বা সেবাদাতার যাচাই) দিয়ে পাস করিয়েছি; সব পূর্ণ নামের শেষে বিন্দু আছে
• CNAME কোথাও অন্য record-এর পাশে নেই, apex-এ নেই; MX আর NS-এর লক্ষ্য CNAME নয়
• বদলের আগে TTL কমিয়েছি, বদলের পর dig @প্রতিটি-NS দিয়ে serial আর নতুন record মিলিয়েছি
• Recursive resolver শুধু নিজের নেটওয়ার্কের জন্য, AXFR শুধু secondary-দের জন্য খোলা
• PTR-এর নাম, সংখ্যা আর RFC নম্বর নিজে হিসাব করে বা rfc-editor.org-এ মিলিয়েছি; নিজের ল্যাবে dig আর packet capture দিয়ে আসল বার্তা দেখেছি