Design a DNS Service ডিজাইন

ইন্টারনেটে প্রতিটা ক্লিকের আগে নীরবে একটা কাজ হয় — facebook.com-কে একটা IP ঠিকানায় রূপান্তর। এই অনুবাদকের নাম DNS। এটা ইন্টারনেটের ফোনবুক, আর এটা পড়ে গেলে কার্যত পুরো ইন্টারনেট থেমে যায়। চলো একটা স্কেলযোগ্য DNS সার্ভিস ডিজাইন করি।

১. সমস্যা বোঝা (Requirements)

ফাংশনাল রিকোয়ারমেন্ট:

• ডোমেইন নাম → IP রেজলিউশন (A, AAAA ইত্যাদি)।
• বিভিন্ন record type সাপোর্ট: A, AAAA, CNAME, MX, TXT, NS।
• zone ম্যানেজমেন্ট (রেকর্ড যোগ/সম্পাদনা)।
• GeoDNS — অবস্থান অনুযায়ী আলাদা উত্তর।

নন-ফাংশনাল রিকোয়ারমেন্ট:

• অত্যন্ত High availability — কার্যত ১০০%, কারণ DNS পড়লে সব পড়ে।
• খুবই Low latency — মিলিসেকেন্ড পর্যায়ে।
• বিশাল read-heavy স্কেল।
• DDoS resilience — DNS DDoS-এর প্রধান টার্গেট।

২. স্কেল আন্দাজ (Estimation)

ধরি একটা বড় recursive resolver সার্ভিস:
দৈনিক কুয়েরি          = 1 ট্রিলিয়ন = 10^12/দিন
গড় QPS               = 10^12 / 86,400 ≈ 11.6 মিলিয়ন queries/sec
পিক (3x)              ≈ 35 মিলিয়ন QPS

প্রতি কুয়েরি/রেসপন্স   ≈ 100-500 bytes (UDP packet)
ব্যান্ডউইথ (avg)       ≈ 11.6M * 300B ≈ 3.5 GB/sec ≈ 28 Gbps

cache hit ratio       ≈ 90% (TTL caching-এর কল্যাণে)
=> upstream (miss)    ≈ 10% * 11.6M ≈ 1.16M QPS authoritative-এ যায়

zone/record স্টোরেজ    = কোটি কোটি রেকর্ড, প্রতিটা ছোট
=> মোট কয়েকশো GB     (একটা ক্লাস্টারে সহজেই ধরে)

মূল শিক্ষা: লোড বিপুল কিন্তু payload ছোট, আর caching ৯০% লোড শুষে নেয়। আসল চ্যালেঞ্জ QPS আর availability, স্টোরেজ নয়।

৩. API / প্রোটোকল ডিজাইন

DNS নিজেই একটা প্রোটোকল (UDP/53, fallback TCP/53)। তার পাশে management API থাকে।

# DNS কুয়েরি (wire protocol — সরলীকৃত)
QUERY  name=api.example.com  type=A  class=IN
RESP   api.example.com  A  93.184.216.34  TTL=300

# আধুনিক ট্রান্সপোর্ট
DoH (DNS over HTTPS) : GET /dns-query?name=example.com&type=A
DoT (DNS over TLS)   : TCP/853

# Zone management API (control plane)
POST /v1/zones/{zone}/records
     body: { "name": "api", "type": "A", "value": "1.2.3.4", "ttl": 300 }
GET  /v1/zones/{zone}/records
DELETE /v1/zones/{zone}/records/{id}

৪. ডেটা মডেল

Record Type	মানে	উদাহরণ ভ্যালু
A	নাম → IPv4	93.184.216.34
AAAA	নাম → IPv6	2606:2800::1
CNAME	alias → অন্য নাম	www → example.com
MX	মেইল সার্ভার	10 mail.example.com
TXT	যেকোনো টেক্সট (SPF/verify)	"v=spf1 ..."
NS	zone-এর authoritative সার্ভার	ns1.example.com

Zone হিসেবে সংগঠন: প্রতিটা ডোমেইন একটা zone; রেকর্ডগুলো zone-এর ভেতরে থাকে। স্টোরেজ চয়েস হিসেবে authoritative-এ একটা replicated key-value store (key = name+type) ভালো, কারণ লুকআপ পুরোপুরি key-by lookup আর read-heavy।

মনে রাখো: CNAME কখনো zone apex (example.com রুট)-এ বসানো যায় না — এর জন্য ALIAS/ANAME-এর মতো বিশেষ রেকর্ড লাগে।

৫. হাই-লেভেল ডিজাইন

DNS-এর দুই স্তর বোঝা জরুরি:

1. Recursive Resolver: ক্লায়েন্ট (যেমন তোমার ফোন) এর কাছে কুয়েরি করে। resolver না জানলে root → TLD (.com) → authoritative ঘুরে উত্তর আনে, তারপর cache করে।
2. Authoritative Server: একটা নির্দিষ্ট zone-এর চূড়ান্ত মালিক; "আমি জানি example.com কোথায়" বলে।

রেজলিউশন ফ্লো:

Client --> Recursive Resolver
   cache HIT? --> হ্যাঁ: তৎক্ষণাৎ উত্তর
             --> না:
        Resolver --> Root server  (".com কোথায়?")
        Resolver --> TLD server   ("example.com-এর NS কী?")
        Resolver --> Authoritative ("example.com-এর A রেকর্ড?")
        Resolver cache করে (TTL অনুযায়ী) --> Client-কে উত্তর

স্কেলিং স্তর: authoritative ও recursive — দুটোই anycast দিয়ে বিশ্বজুড়ে অনেক জায়গায় ছড়ানো থাকে, যাতে ব্যবহারকারী নিকটতম নোড পায় আর কোনো একটা নোড পড়লেও সার্ভিস চলে।

৬. গভীরে (Deep Dive)

(ক) Caching ও TTL — পারফরম্যান্সের ভিত্তি

DNS-এর প্রায় ৯০% কুয়েরি cache থেকেই উত্তর পায়। প্রতিটা রেকর্ডের TTL বলে দেয় কতক্ষণ cache রাখা যাবে।

• বড় TTL (যেমন ২৪ ঘণ্টা): কম লোড, কিন্তু রেকর্ড বদলালে আপডেট ধীরে ছড়ায়।
• ছোট TTL (যেমন ৬০ সেকেন্ড): দ্রুত failover/পরিবর্তন, কিন্তু বেশি কুয়েরি লোড।

ব্যবহারিক কৌশল: সাধারণ রেকর্ডে বড় TTL, কিন্তু পরিবর্তন আসন্ন হলে আগে থেকে TTL কমিয়ে রাখো (pre-lowering), তারপর বদলাও।

(খ) High Availability ও Anycast

DNS-এ ডাউনটাইম মানে ব্যবসা বন্ধ, তাই:

• প্রতিটা zone-এর একাধিক NS রেকর্ড, ভিন্ন নেটওয়ার্কে।
• প্রতিটা NS আবার anycast — একই IP বিশ্বের অনেক PoP থেকে। একটা PoP পড়লে BGP ট্রাফিক অন্যটিতে সরায়, ক্লায়েন্ট কিছুই টের পায় না।
• Authoritative ডেটা multiple region-এ replicate; zone transfer (AXFR/IXFR) বা আধুনিক replication দিয়ে সিঙ্ক।

(গ) GeoDNS

একই নামের জন্য ব্যবহারকারীর অবস্থান অনুযায়ী আলাদা IP ফেরত দেওয়া — যেমন এশিয়ার ব্যবহারকারীকে সিঙ্গাপুর সার্ভার, ইউরোপের ব্যবহারকারীকে ফ্রাঙ্কফুর্ট সার্ভার। authoritative সার্ভার কুয়েরির উৎস IP (বা EDNS Client Subnet) দেখে সিদ্ধান্ত নেয়। এটা CDN/load distribution-এর ভিত্তি।

৭. বটলনেক ও স্কেলিং

• DDoS (amplification/flood): DNS DDoS-এর প্রধান লক্ষ্য। প্রতিরক্ষা: anycast দিয়ে লোড বহু নোডে ছড়ানো, rate limiting, Response Rate Limiting (RRL), আর over-provisioned ব্যান্ডউইথ।
• Cache poisoning: ভুয়া রেসপন্স ঢোকানো। প্রতিরক্ষা: randomized source port + query ID, এবং DNSSEC (রেকর্ড ক্রিপ্টোগ্রাফিকভাবে সাইন করা)।
• Hot zone: কোনো একটা জনপ্রিয় zone-এ বিপুল লোড। caching আর authoritative replication দিয়ে সামলানো।
• Propagation delay: TTL-এর কারণে পরিবর্তন তাৎক্ষণিক নয়; pre-lowering TTL দিয়ে পরিকল্পনা করো।
• UDP truncation: বড় রেসপন্স UDP-তে আঁটে না (<512 bytes ক্লাসিক সীমা), তখন TCP fallback বা EDNS0 দিয়ে বড় packet।

৮. সারসংক্ষেপ

DNS হলো ইন্টারনেটের ফোনবুক — প্রচণ্ড read-heavy, ছোট payload, কিন্তু availability-তে শূন্য সহনশীলতা। দুই স্তর মনে রাখো: recursive resolver (ক্লায়েন্টের হয়ে খুঁজে আনে ও cache করে) আর authoritative server (চূড়ান্ত উত্তরের মালিক)। স্কেল আর HA-র জন্য anycast, পারফরম্যান্সের জন্য TTL caching, রাউটিংয়ের জন্য GeoDNS, আর নিরাপত্তার জন্য DNSSEC + RRL — এই কয়টা স্তম্ভ একসাথে দাঁড় করায় পুরো সিস্টেম।