Cloud DNS — record, TTL, health check আর traffic routing

১ · Hosted zone — আপনার domain-এর রেজিস্টার খাতা

রাত দুইটায় একটি কাল্পনিক অনলাইন বাজার অ্যাপের দল নতুন region-এ সরে গেল। Server ঠিক আছে, load balancer ঠিক আছে, তবু ঢাকার কিছু ব্যবহারকারী পুরোনো site দেখছেন। অথচ চট্টগ্রামের অন্য কেউ দেখছেন নতুনটি। কেউ ভাবলেন, “DNS এখনো propagate হয়নি।” এই একটি বাক্যে যে ভুল ধারণা লুকিয়ে আছে, এই পর্ব সেটি ভাঙবে।

DNS-এর protocol আর নামের গাছের তত্ত্ব আছে Computer Networks · DNS পর্বে। সংক্ষেপে: resolver আপনার হয়ে root, TLD আর authoritative server-কে জিজ্ঞেস করে উত্তর আনে, তারপর cache করে। এখানে আমরা দেখব অন্য দিকটি। আপনি যখন একটি সেবা চালান, তখন DNS কীভাবে সাজাবেন, বদলাবেন, আর বিপদে কীভাবে ব্যবহার করবেন।

Cloud-এ authoritative server আপনাকে বানাতে হয় না। আপনি একটি hosted zone তৈরি করেন। এটি একটি domain-এর সব record-এর managed খাতা, আর provider সেটি দুনিয়াজুড়ে ছড়ানো name server থেকে পরিবেশন করে। এই server-গুলো সাধারণত anycast-এ চলে।

Public আর private zone

• Public hosted zone: Internet-এর যে কেউ জিজ্ঞেস করতে পারে। ওয়েবসাইট, API আর mail-এর record এখানে থাকে।
• Private hosted zone: শুধু আপনার নির্বাচিত VPC-র ভেতর থেকে উত্তর মেলে। Database বা ভেতরের সেবার নাম এখানে রাখা হয়।

একটি ধাপ নতুনরা প্রায়ই ভুলে যান। Public zone বানালে provider আপনাকে কয়েকটি name server-এর নাম দেয়, যেমন Route 53-এ সাধারণত চারটি। এগুলো registrar-এ বসাতে হবে। তবেই TLD আপনার zone-এর দিকে পথ দেখাবে। এই কাজ না করলে zone-এ যত record-ই লিখুন, কেউ দেখবে না। Zone মুছে আবার বানালে নাম বদলে যেতে পারে, তাই তখনো registrar-এ মিলিয়ে দেখুন।

একই কাজ তিন provider-এ এই নামে পাবেন। নামগুলো লেখার সময়ের; নতুন সুবিধা আসতে থাকে, তাই official docs মিলিয়ে নিন।

২ · Record-এর ধরন — চালানোর সময় যেগুলো হাতে লাগে

প্রতিটি record-এর চারটি অংশ: নাম, TTL, ধরন আর মান। এদের তাত্ত্বিক রূপ আছে Computer Networks-এর DNS পর্বে। এখানে দেখুন কোনটি কখন, আর কোথায় ঠকতে হয়।

CAA-র একটি নিয়ম মনে রাখা দরকার। CA/Browser Forum-এর নিয়মে ২০১৭ সাল থেকে public CA-কে certificate দেওয়ার আগে CAA দেখতে হয়। Standard-টি এখন RFC 8659 (২০১৯)। তাই এটি একটি ছোট কিন্তু সত্যিকারের নিরাপত্তা-স্তর। এটি অন্য CA-কে ভুল করে আপনার নামে certificate দেওয়া থেকে থামায়।

৩ · Apex-এ CNAME কেন বসে না, আর alias কী করে

Zone apex মানে domain-এর নিজের নাম, www ছাড়া example.com. ধরুন আপনার site একটি load balancer-এর পেছনে, যার নাম lb-demo.example.net. www-এর জন্য CNAME বসানো সহজ। কিন্তু example.com-এ বসাতে গেলে console আপত্তি করবে।

কারণটি provider-এর খেয়াল নয়, DNS-এর নিয়ম। RFC 1034 (১৯৮৭) বলে, কোনো নামে CNAME থাকলে সেই নামে অন্য কোনো record থাকতে পারবে না। আর RFC 2181 (১৯৯৭) তা আরও স্পষ্ট করে। অথচ apex-এ SOA আর NS থাকতেই হবে, সাধারণত MX আর TXT-ও থাকে। দুই নিয়ম একসাথে মানা যায় না।

Alias record এই গিঁট খোলে কৌশলে। আপনি provider-কে বলেন, “apex-এর A উত্তরের জন্য এই target-এর ঠিকানাগুলো দেখে নিন।” Authoritative server নিজের দিক থেকে target-এর বর্তমান IP বের করে, আর resolver-কে একটি সাধারণ A উত্তর দেয়। Resolver CNAME দেখেই না। তাই নিয়ম ভাঙে না, আর load balancer-এর IP বদলালেও আপনাকে কিছু করতে হয় না।

উদাহরণ: Route 53-এর alias, Azure DNS-এর alias record set, আর কিছু DNS provider-এর ALIAS, ANAME বা CNAME flattening. Google Cloud DNS-এ এই সুবিধার অবস্থা সময়ের সাথে বদলেছে, তাই docs দেখে নিন। নাম কাছাকাছি হলেও ভেতরের কাজ আর target-এর সীমা provider-ভেদে আলাদা।

৪ · TTL আর “propagation” — আসলে কী ছড়ায়

“DNS propagate হতে ৪৮ ঘণ্টা লাগে” কথাটি শুনে মনে হয়, নতুন record ঢেউয়ের মতো দুনিয়ায় ছড়াচ্ছে। বাস্তব উল্টো। Propagation বলে কিছু push হয় না। Provider-এর নিজের name server-গুলো সাধারণত দ্রুত মিলে যায়। তারপর কিছুই ছড়ায় না। শুধু দুনিয়ার লাখো resolver-এর cache একে একে মেয়াদোত্তীর্ণ হয়। প্রত্যেকে নিজের সময়ে আবার জিজ্ঞেস করে।

নিজের চোখে দেখতে পারেন। Resolver-এর কাছে থাকা TTL কমতে থাকে, আর authoritative সবসময় পুরো মান দেখায়। আউটপুট নমুনা; নাম আর মান আলাদা হবে।

# ask the resolver you normally use (cached copy, TTL counts down)
dig +noall +answer www.example.com A
# ask the authoritative server directly (full TTL)
dig +noall +answer @ns1.example.net www.example.com A

# নমুনা আউটপুট — version-ভেদে আলাদা হতে পারে
# www.example.com.   47   IN   A   198.51.100.20
# www.example.com.   60   IN   A   198.51.100.20

Site সরানো: TTL আগে কমানোর পুরো ধাপ

নিচের কাল্পনিক site-এর পুরোনো ঠিকানা old = 198.51.100.10, নতুন new = 203.0.113.50. Record-এর TTL 86400 s, অর্থাৎ ১ দিন। T হলো cutover, অর্থাৎ যে মুহূর্তে record বদলে নতুন ঠিকানায় যাওয়া হবে। R1 একটি resolver, যে T-এর ২৬ ঘণ্টা আগে উত্তরটি নিয়েছিল।

যদি TTL না কমিয়েই সরাতেন? নিচের planner দুই পথের তুলনা করে। ধরে নেওয়া হয়েছে, ২% ট্রাফিক TTL না মেনে ২ ঘণ্টা পর্যন্ত পুরোনো ঠিকানা ধরে রাখে। এই সংখ্যা ধারণা, বাস্তবে আপনার log দেখে ঠিক করতে হবে। Resolver-দের cache-এর বাকি সময় সমভাবে ছড়ানো ধরা হয়েছে।

// TTL migration planner. Share of traffic still reaching the OLD address after cutover.
function mulberry32(a) {
  return () => {
    a = (a + 0x6D2B79F5) | 0;
    let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const OLD_TTL = 86400, NEW_TTL = 60, SAFETY = 3600;
const STUCK = 0.02;    // assumption: 2% of traffic ignores TTL and holds the old name
const STUCK_FOR = 7200; // assumption: such clients let go within 2 hours
console.log("lower TTL at T-" + (OLD_TTL + SAFETY) + " s (old TTL + 1 h safety)");

function oldShare(ttl, t, n = 20000) {
  const r = mulberry32(2026);
  let old = 0;
  for (let i = 0; i < n; i++) {
    const stuck = r() < STUCK;
    const left = stuck ? r() * STUCK_FOR : r() * ttl; // time until this client re-asks
    if (left > t) old++;
  }
  return (100 * old / n).toFixed(1).padStart(6) + "%";
}
const times = [0, 30, 60, 300, 1800, 3600, 7200, 21600, 86400];
console.log("t after cutover   TTL 60 first   no lowering (TTL 86400)");
for (const t of times) {
  console.log((t + " s").padEnd(18) + oldShare(NEW_TTL, t).padEnd(15) + oldShare(OLD_TTL, t));
}
console.log("retire old server: not before T+" + STUCK_FOR + " s, and only when its log is quiet");

যা TTL-এর হিসাবে ধরা পড়ে না

• TTL না মানা client: কিছু resolver খুব ছোট TTL বাড়িয়ে নেয়। JVM-এর মতো runtime বা library নিজের মতো cache রাখতে পারে, সেটি version আর setting-নির্ভর।
• চালু connection: DNS শুধু নতুন সংযোগের আগে দেখা হয়। Connection pool আর keep-alive পুরোনো IP-তে থেকে যায়।
• NS বদলানো: DNS provider বদলালে TLD-তে থাকা NS-এর দীর্ঘ TTL কাজ করে, যা অনেক TLD-তে ১–২ দিন। এজন্য দুই zone-ই কিছুদিন একই record নিয়ে চালু রাখুন।
• Negative caching: নতুন record বসানোর আগে কেউ নামটি খুঁজে NXDOMAIN পেয়ে থাকলে, সেই “নেই” উত্তরও cache হয়। সময় ঠিক হয় SOA থেকে (RFC 2308, ১৯৯৮)। তাই নতুন record বসানোর আগে নামটি পরীক্ষা করে ফেলবেন না।

TTL কত রাখবেন — খরচসহ হিসাব

ছোট TTL মানে দ্রুত বদল, কিন্তু বেশি query. ধরে নিই ১০,০০০টি resolver সবসময় সক্রিয়, আর প্রতি ১০ লাখ query-র দাম $০.৫০ (ধরে নেওয়া সংখ্যা; আসল দাম provider-এর pricing পাতায় দেখুন)। ৩০ দিনের মাস ধরে হিসাব:

• TTL 3600: 10,000 × 1 × 720 = ৭২ লাখ query, প্রায় $৩.৬০।
• TTL 60: 10,000 × 60 × 720 = ৪৩.২ কোটি query, প্রায় $২১৬।

এটি সর্বোচ্চ সীমার হিসাব, তবু অনুপাতটি (৬০ গুণ) সত্যি। আরেকটি দাম আছে: ছোট TTL-এ provider-এর সমস্যা সাথে সাথে ব্যবহারকারীর গায়ে লাগে, কারণ cache-এর আড়াল থাকে না। তাই সাধারণ অবস্থায় 300–3600 s, migration-এর আগে 60 s, আর failover record-এ provider-এর পরামর্শমতো ছোট মান রাখা একটি প্রচলিত পথ। এটি নিয়ম নয়, শুরু করার জায়গা।

Zone file-এর ভুল চোখে ধরা কঠিন। Zone file হলো record-এর সাধারণ লেখা রূপ, যা export করা যায়। নিচের ছোট audit apex-এর CNAME, CNAME-এর সাথে অন্য record আর ঝুঁকিপূর্ণ দীর্ঘ TTL খোঁজে। ঠিকানা-জাতীয় record-এই শুধু দেখে, কারণ NS আর SOA-তে দীর্ঘ TTL স্বাভাবিক।

set -euo pipefail
cat > example.zone <<'EOF'
$ORIGIN example.com.
$TTL 3600
@       86400 IN SOA   ns1.example.net. ops.example.com. 2026103001 7200 3600 1209600 300
@       86400 IN NS    ns1.example.net.
@       86400 IN NS    ns2.example.net.
@       300   IN CNAME lb-demo.example.net.
@       3600  IN MX    10 mail.example.com.
www     60    IN CNAME lb-demo.example.net.
api     86400 IN A     198.51.100.20
pay           IN A     198.51.100.30
blog    300   IN CNAME blog-demo.example.net.
blog    300   IN TXT   "site-verification=demo"
EOF

awk -v max=3600 '
/^\$TTL/ { dflt = $2; next }
/^[$;]/ || NF == 0 { next }
{
  n++; owner = $1; ttl = dflt; type = $3; note = " (zone default)"
  if ($2 ~ /^[0-9]+$/) { ttl = $2; type = $4; note = "" }
  count[owner]++
  if (type == "CNAME") cname[owner] = 1
  # NS and SOA change rarely, so a long TTL is normal there.
  if (type ~ /^(A|AAAA|CNAME)$/ && ttl + 0 > max + 0)
    printf "WARN  %-5s %s TTL %s is above %s: a cutover would be slow\n", owner, type, ttl, max
  if (type == "A" && note != "") printf "INFO  %-5s %s TTL %s%s\n", owner, type, ttl, note
}
END {
  if (cname["@"]) print "ERROR @     CNAME at the apex: SOA and NS must live there"
  for (o in cname) if (o != "@" && count[o] > 1) print "ERROR " o "  CNAME shares its name with other records"
  print "records checked: " n
}' example.zone

৫ · Routing policy — একই প্রশ্নের আলাদা উত্তর

সাধারণ DNS একটি প্রশ্নের একটিই উত্তর দেয়। Managed DNS এর ওপর আরেকটি স্তর বসায়: কে জিজ্ঞেস করছে, কোন target সুস্থ, আর আপনার ঠিক করা ভাগ দেখে উত্তর বাছাই। এই সিদ্ধান্ত হয় শুধু উত্তর দেওয়ার মুহূর্তে, অনুরোধের পথে নয়। Load balancer-এর সাথে এখানেই বড় পার্থক্য।

একটি প্রশ্ন জরুরি: “ব্যবহারকারী কোথায়” provider কীভাবে জানে? Authoritative server দেখে resolver-এর ঠিকানা, ব্যবহারকারীর নয়। ঢাকার কেউ সিঙ্গাপুরের public resolver ব্যবহার করলে ভুল অঞ্চলে যেতে পারেন। EDNS Client Subnet (RFC 7871, ২০১৬) ঠিকানার একটি অংশ পাঠিয়ে এটি কমায়, তবে সব resolver এটি পাঠায় না। তাই geo দিয়ে আইনগত সীমা মানতে গেলে শুধু DNS-এ ভরসা করবেন না; দরজায় অন্য যাচাইও লাগে। Latency-র ক্ষেত্রেও এটি মাপা গড়, প্রতিটি মানুষের নিশ্চয়তা নয়।

Weighted routing-এর সত্যিকারের চেহারা

৯০/১০ ভাগ মানে কি ঠিক ৯০/১০ traffic? নিচের সিমুলেটর দুটি অবস্থা দেখায়। প্রথমে প্রতিটি query আলাদাভাবে উত্তর পায়। পরে ব্যবহারকারীরা resolver-এর পেছনে, আর resolver ৬০ সেকেন্ড একটি উত্তর ধরে রাখে। Seed বাঁধা, তাই প্রতিবার একই ফল আসবে।

// Weighted DNS routing: 90% blue, 10% green. Seeded PRNG, so every run is identical.
function mulberry32(a) {
  return () => {
    a = (a + 0x6D2B79F5) | 0;
    let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const pct = (x, n) => (100 * x / n).toFixed(1).padStart(5) + "%";
const WEIGHTS = { blue: 90, green: 10 }, SUM = 100;
const pick = (r) => (r() * SUM < WEIGHTS.blue ? "blue" : "green");

// Part 1: every DNS query is answered independently.
console.log("queries   green share   (target 10.0%)");
for (const n of [20, 100, 1000, 100000]) {
  const r = mulberry32(1); let green = 0;
  for (let i = 0; i < n; i++) if (pick(r) === "green") green++;
  console.log(String(n).padStart(7) + "   " + pct(green, n));
}

// Part 2: users sit behind resolvers, and a resolver caches one answer for 60 s.
const resolvers = [40000, 12000, 5000, 2000, 500, 200, 100, 100, 50, 50]; // users
const TOTAL = resolvers.reduce((a, b) => a + b, 0);
console.log("\nusers=" + TOTAL + " resolvers=" + resolvers.length + "  minute by minute:");
const r = mulberry32(7);
let line = [];
for (let minute = 1; minute <= 10; minute++) {
  let green = 0;
  for (const users of resolvers) if (pick(r) === "green") green += users;
  line.push(pct(green, TOTAL).trim());
}
console.log("green share: " + line.join(" "));

DNS দিয়ে canary

DNS-ভিত্তিক canary মানে নতুন version-কে অল্প ওজন দিয়ে শুরু করা, যেমন ১%, ৫%, ২৫%, ১০০%. Terraform-এ Route 53-এর একটি উদাহরণ নিচে; অন্য provider-এর নিজস্ব resource আছে। Terraform নিজে শেখানো হবে পর্ব ৫২-তে।

resource "aws_route53_record" "www_blue" {
  zone_id         = var.zone_id
  name            = "www.example.com"
  type            = "A"
  ttl             = 60
  records         = ["198.51.100.20"]
  set_identifier  = "blue"
  health_check_id = var.blue_check_id

  weighted_routing_policy {
    weight = 95
  }
}

resource "aws_route53_record" "www_green" {
  zone_id         = var.zone_id
  name            = "www.example.com"
  type            = "A"
  ttl             = 60
  records         = ["198.51.100.21"]
  set_identifier  = "green"
  health_check_id = var.green_check_id

  weighted_routing_policy {
    weight = 5
  }
}

DNS canary-র তিনটি দুর্বলতা জেনে রাখুন। ভাগ মোটা দাগের, কারণ resolver-এর cache আছে। Rollback সঙ্গে সঙ্গে হয় না, TTL পর্যন্ত অপেক্ষা লাগে। আর একই ব্যবহারকারী একবার blue, একবার green পেতে পারেন। সূক্ষ্ম ভাগের জন্য load balancer বা service mesh-এর weighted target ভালো (System Design · Canary, আর পর্ব ৫৯)। DNS canary মানায় পুরো cluster বা region-এর মধ্যে, যেখানে সামনে আর কোনো সাধারণ LB নেই।

৬ · Health check আর failover — কত সেকেন্ড লাগে

Failover record-এ primary-র সাথে একটি health check জোড়া থাকে। Provider দুনিয়ার কয়েকটি জায়গা থেকে endpoint-কে পরীক্ষা করে। Check ব্যর্থ হলে DNS failover শুরু হয়: authoritative এখন secondary-র ঠিকানা দেয়। কিন্তু উত্তর বদলানো আর ব্যবহারকারী সরে যাওয়া এক কথা নয়।

লেখার সময়ে Route 53-এ interval সাধারণত 30 s বা 10 s, আর threshold পরিবর্তনযোগ্য। AWS failover record-এর TTL ৬০ সেকেন্ড বা কম রাখতে পরামর্শ দেয়। Provider-ভেদে এই মান আলাদা, তাই docs মিলিয়ে নিন। এবার ধাপে ধাপে দেখুন: I = 10, F = 3, TTL = 60. Primary ঠিক t = 0-তে পড়ে গেল, আর শেষ সফল check ঠিক তার আগে হয়েছিল। তিনজন ব্যবহারকারীর দল: R-A (উত্তর নিয়েছে t = -5-এ), R-B (t = -50-এ), আর App C, যে TTL না মেনে নিজের ১২০ সেকেন্ডের cache রাখে।

এক client-এর গল্প থেকে পুরো জনতার হিসাবে আসি। নিচের সিমুলেটর ২০,০০০ client-এর জন্য check-এর phase আর cache-এর বাকি সময় এলোমেলো রাখে, তবে seed বাঁধা।

// How long until clients leave a dead primary? Times in seconds.
function mulberry32(a) {
  return () => {
    a = (a + 0x6D2B79F5) | 0;
    let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
function simulate({ interval, fails, ttl, appCache }, n = 20000) {
  const r = mulberry32(2929), moved = [];
  for (let i = 0; i < n; i++) {
    const detect = r() * interval + (fails - 1) * interval; // now answers "secondary"
    // The resolver re-fetches every ttl seconds; its next fetch after detect wins.
    let t = r() * ttl;                               // first expiry after the crash
    while (t < detect) t += ttl;
    moved.push(t + r() * appCache);                  // the app's own cache adds more
  }
  moved.sort((a, b) => a - b);
  const q = (p) => Math.round(moved[Math.floor(p * (n - 1))]);
  return [q(0.5), q(0.95), q(1)];
}
const cases = [
  ["slow check, long TTL", { interval: 30, fails: 3, ttl: 300, appCache: 0 }],
  ["fast check, long TTL", { interval: 10, fails: 3, ttl: 300, appCache: 0 }],
  ["fast check, TTL 60", { interval: 10, fails: 3, ttl: 60, appCache: 0 }],
  ["fast check, TTL 60, app 300", { interval: 10, fails: 3, ttl: 60, appCache: 300 }],
];
console.log("case".padEnd(29) + "worst-formula  p50  p95  max");
for (const [name, c] of cases) {
  const formula = c.fails * c.interval + c.ttl + c.appCache;
  const [p50, p95, max] = simulate(c);
  console.log(name.padEnd(29) + String(formula).padStart(13) +
    String(p50).padStart(5) + String(p95).padStart(5) + String(max).padStart(5));
}

৭ · Split-horizon, VPC resolver আর hybrid forwarding

প্রতিটি VPC-র ভেতরে provider একটি VPC resolver দেয়। VM আলাদা কিছু না করেই তাকে জিজ্ঞেস করে। AWS-এ এর ঠিকানা সাধারণত VPC CIDR-এর base + 2 (যেমন 10.0.0.2), Azure-এ 168.63.129.16, আর Google Cloud-এ metadata server-এর 169.254.169.254. এগুলো লেখার সময়ের তথ্য।

Split-horizon DNS মানে একই নামের দুই রকম উত্তর: ভেতর থেকে private ঠিকানা, বাইরে থেকে public ঠিকানা। এতে ভেতরের traffic ভেতরেই থাকে, আর NAT বা internet পথের ঝামেলা ও খরচ এড়ানো যায়। একই নামের কারণে certificate-ও একটিতেই চলে।

Hybrid: অফিস আর cloud-এর নাম মেলানো

পর্ব ২৮-এর VPN বা dedicated link দিয়ে অফিস আর VPC জোড়া থাকলেও নাম নিজে থেকে মেলে না। অফিসের server db.internal.example.com চিনবে না, আর VM চিনবে না erp.corp.example. সমাধান conditional forwarding: নির্দিষ্ট নামের প্রশ্ন নির্দিষ্ট resolver-এ পাঠানো।

• Cloud থেকে অফিসে: Outbound endpoint আর forwarding rule: corp.example-এর প্রশ্ন অফিসের DNS server-এ যাবে।
• অফিস থেকে cloud-এ: Inbound endpoint: VPC-র ভেতরে একটি ঠিকানা, যেখানে অফিসের DNS server প্রশ্ন পাঠায়। VPC resolver-এর ঠিকানা সাধারণত VPC-র বাইরে থেকে ব্যবহার করা যায় না, তাই এটি লাগে।

Route 53 Resolver endpoint, Azure DNS Private Resolver আর Cloud DNS forwarding zone এই কাজের উদাহরণ। DNS TCP আর UDP দুই পথেই port 53 ব্যবহার করে, তাই firewall-এ দুটিই দরকার (পর্ব ২৭)। Hybrid-এর সবচেয়ে সাধারণ ত্রুটি হলো শুধু UDP খোলা; বড় উত্তর তখন ব্যর্থ হয়, আর সমস্যাটি মাঝেমধ্যে দেখা দেয়।

৮ · DNS যখন single point of failure

DNS সাধারণত এত নির্ভরযোগ্য যে কেউ ভাবে না। আবার সব সেবা এর ওপর দাঁড়িয়ে, তাই এটি পড়লে অনেকখানি পড়ে। ইঞ্জিনিয়ারদের মধ্যে একটি কৌতুক আছে, “It's always DNS.” সব সময় নয়, তবু কয়েকটি জনসমক্ষে বর্ণিত ঘটনা শিক্ষণীয়। বিস্তারিত সংশ্লিষ্ট প্রতিষ্ঠানের প্রকাশিত প্রতিবেদন থেকে দেখে নিন।

• Dyn, অক্টোবর ২০১৬: Managed DNS provider Dyn-এর ওপর বড় DDoS হয়, যার পেছনে Mirai botnet-এর ভূমিকার কথা জানা যায়। যে বড় বড় site শুধু এই একটি provider-এ ছিল, তাদের অনেকেই কিছু সময় পৌঁছানোর বাইরে চলে যায়, যদিও তাদের server সচল ছিল।
• Facebook, অক্টোবর ২০২১: প্রতিষ্ঠানটির প্রকাশিত বর্ণনা অনুযায়ী, backbone-এর একটি কাজে ভুলের পর তাদের DNS server-গুলোর BGP ঘোষণা সরে যায়। ফলে নাম মেলা বন্ধ হয়, আর ভেতরের সরঞ্জামও ক্ষতিগ্রস্ত হওয়ায় ঠিক করতে দেরি হয়।
• AWS us-east-1, অক্টোবর ২০২৫: AWS-এর প্রকাশিত সারাংশ অনুযায়ী, DynamoDB-র স্বয়ংক্রিয় DNS ব্যবস্থাপনায় একটি race condition একটি regional endpoint-এর record খালি করে দেয়। এর প্রভাব ওপর-নির্ভর আরও অনেক সেবায় ছড়ায়।

তিনটি ঘটনার ধরন তিন রকম: বাইরের আক্রমণ, network-এর ভুল, নিজের automation-এর ভুল। শিক্ষা একই: DNS-কে একটি single point of failure হিসেবে দেখুন, আর তাকে আলাদা করে নকশা করুন।

• দুই DNS provider: Secondary DNS বা দুই provider-এ একই zone রাখা। ধরে নিই একেকটির availability ৯৯.৯%, আর ব্যর্থতা স্বাধীন। তাহলে 1 − 0.001² = ৯৯.৯৯৯৯%. বাস্তবে স্বাধীনতা পুরো নয়, আর alias বা routing policy দুই provider-এ হুবহু মেলে না।
• যুক্তিসঙ্গত TTL: সবকিছু 60 s রাখলে provider পড়ার এক মিনিটেই সব cache খালি। Cache একটি আড়াল।
• ঠিক করার পথ DNS-এর বাইরে: Runbook আর জরুরি প্রবেশ যেন যে DNS পড়েছে, তার ওপরই নির্ভর না করে।
• Automation-এ সাবধানতা: DNS বদল review, ছোট blast radius আর দ্রুত rollback দিয়ে করুন।

৯ · নিরাপত্তা — registrar lock, DNSSEC আর dangling record

Domain-এর চাবি

DNS-এর সবচেয়ে উঁচু চাবি registrar account. কেউ সেটি পেলে NS বদলে পুরো domain নিয়ে যেতে পারে। Sea Turtle নামে যে DNS hijack অভিযান Cisco Talos ২০১৯ সালে প্রকাশ করে, তাতে registrar আর registry-স্তরের প্রবেশের কথা উঠে আসে। তাই চারটি সহজ অভ্যাস:

• Registrar-এ শক্ত MFA, আর সীমিত ব্যবহারকারী।
• Registrar lock চালু, যাতে সাধারণ অনুরোধে transfer না হয়। গুরুত্বপূর্ণ domain-এ registry lock-ও ভাবুন।
• Auto-renew চালু। সময়মতো নবায়ন না করে domain হারানো একটি অপ্রত্যাশিত রকমের সাধারণ দুর্ঘটনা।
• DNS বদলের IAM অনুমতি সরু, আর audit log চালু (পর্ব ৩১ ও ৩৪)।

DNSSEC, সংক্ষেপে

DNSSEC (RFC 4033–4035, ২০০৫) record-এ digital signature যোগ করে, যাতে resolver যাচাই করতে পারে উত্তরটি পথে বদলায়নি। এটি উত্তর গোপন করে না, শুধু খাঁটিত্ব প্রমাণ করে। চালু করতে zone-এ signing করতে হয়, আর registrar-এ DS record বসাতে হয়। ভুল key বা rollover-এ যাচাইকারী resolver-এ পুরো domain ব্যর্থ হতে পারে। Slack ২০২১ সালের DNSSEC rollout-এর সময় এমন একটি outage-এর বর্ণনা নিজেরাই প্রকাশ করেছে। তাই সুবিধা বড়, তবে ধাপে ধাপে চালু করুন।

Dangling record আর subdomain takeover

দল একটি campaign শেষ করে offer.example.com-এর পেছনের cloud resource মুছে দিল, কিন্তু DNS record রেখে দিল। এটি dangling record: নামটি এমন কিছুর দিকে তাকিয়ে আছে, যা আর আপনার নেই। Cloud-এর অনেক নাম ও ঠিকানা আবার অন্য ব্যবহারকারীর হাতে যেতে পারে। তখন আপনার নামের নিচে অন্য কারও বিষয়বস্তু দেখা দিতে পারে। একে বলে subdomain takeover. এতে phishing, আর cookie বা certificate-এর ঝুঁকি তৈরি হয়। Detectify-র গবেষকদের ২০১৪ সালের লেখার পর বিষয়টি ব্যাপক আলোচনায় আসে, আর Microsoft-এর docs-এও এটি প্রতিরোধের নির্দেশনা আছে।

১০ · AI-এর যুগে DNS-এর config যাচাই

AI কয়েক সেকেন্ডে record আর Terraform লিখে দিতে পারে। কিন্তু DNS-এর ভুলের ফল দেরিতে আসে, আর cache-এর কারণে ফেরানোও ধীর। একটি ভুল TTL ২৪ ঘণ্টা ধরে আপনাকে আটকে রাখতে পারে। তাই প্রয়োগের আগে যাচাই জরুরি।

প্রয়োগের আগে যাচাইয়ের চেকলিস্ট

• বর্তমান TTL দেখেছি, আর “কত আগে কমাতে হবে” নিজে হিসাব করেছি
• terraform plan বা সমতুল্য diff পড়েছি; কোনো record মোছা হলে বুঝে নিয়েছি
• dig দিয়ে authoritative আর resolver, দুই জায়গায় মিলিয়েছি
• Rollback-এর ধাপ আর তার সময় লিখে রেখেছি
• IAM অনুমতিতে * নেই, আর কোনো token prompt বা TXT-তে নেই
• প্রথমে পরীক্ষার subdomain-এ চালিয়েছি, আর খরচের alert রেখেছি