DNS কী, কেন

গল্পে বুঝি

ধরুন রাজশাহী থেকে খোয়ারিজমি তার বন্ধু সিনাকে একটা চিঠি পাঠাবে। খামের ওপর সে লেখে: “সিনা, বাড়ি ১২, লালবাগ মহল্লা, লালবাগ থানা, ঢাকা জেলা, বাংলাদেশ।” রাজশাহীর পোস্ট অফিসের কেরানি ফাতিমা পুরো ঠিকানাটা পড়েই না। সে শুধু দেখে শেষের অংশটা: “ঢাকা”। ব্যস, চিঠিটা ঢাকার বস্তায় চলে গেল। রাজশাহীর পোস্ট অফিসকে লালবাগের কোন গলিতে সিনার বাড়ি সেটা জানতে হয় না; তার কাজ শুধু ঠিক জেলায় পাঠানো।

ঢাকার জিপিও-তে বিরুনি বস্তা খুলে আবার একই কাজ করে, এবার এক ধাপ ভেতরে: “লালবাগ থানা”। চিঠি গেল লালবাগ পোস্ট অফিসে। সেখানে পোস্টম্যান রাজি জানে লালবাগ মহল্লার কোন বাড়ি কোথায়, কারণ এই মহল্লার দায়িত্ব শুধু তার। সে বাড়ি ১২-তে চিঠি পৌঁছে দেয়। পুরো দেশের কোনো একজন মানুষের কাছে সব বাড়ির তালিকা নেই। প্রত্যেকে শুধু নিজের অংশটুকু জানে, আর জানে পরের অংশের দায়িত্ব কার।

অনেক আগে অবশ্য ব্যবস্থাটা এমন ছিল না। তখন পুরো এলাকায় বাড়ি ছিল হাতে গোনা, আর একজন মুনশি একটা মোটা খাতায় সবার ঠিকানা লিখে রাখতেন। নতুন কেউ এলে মুনশির কাছে গিয়ে নাম লেখাতে হতো, আর সবাই মাসে একবার মুনশির খাতার একটা কপি নিয়ে যেত। বাড়ি যখন লাখে লাখে হলো, মুনশির খাতা আর কপি করে কুলানো গেল না, প্রতিদিন হাজারটা পরিবর্তন, আর খাতা একটা হারালে পুরো দেশ অন্ধ।

মিলিয়ে নিই: মুনশির মোটা খাতা হলো HOSTS.TXT, ইন্টারনেটের শুরুর দিকের একটা মাত্র ফাইল। “বাংলাদেশ → ঢাকা → লালবাগ → বাড়ি ১২” এই স্তরগুলো হলো DNS-এর নামের গাছ (namespace), যেখানে ডান দিক থেকে বাম দিকে পড়লে সাধারণ থেকে নির্দিষ্টে যাওয়া যায়, ঠিক www.baytalhikma.org.-এর মতো। প্রতিটা স্তরের দায়িত্বের এলাকা হলো একটা zone, আর “লালবাগের দায়িত্ব রাজির” এভাবে দায়িত্ব নিচে দিয়ে দেওয়াটাই delegation। রাজি, যে আসলেই উত্তর জানে, সে হলো authoritative nameserver। আর পুরো ঠিকানা, দেশের নাম পর্যন্ত, শেষ পর্যন্ত লেখা হলো FQDN। বাস্তবে এই নকশার কারণেই DNS প্রতি সেকেন্ডে বিশ্বজুড়ে অগণিত লুকআপ সামলায় অথচ কোনো একটা সার্ভারের কাছে পুরো ইন্টারনেটের তালিকা নেই।

DNS কেন দরকার

কম্পিউটার একে অপরকে খোঁজে IP অ্যাড্রেস দিয়ে: 192.0.2.10 বা 2001:db8::10। মানুষ মনে রাখে নাম: baytalhikma.org। DNS (Domain Name System) হলো সেই সিস্টেম যেটা নাম দিলে নাম্বার দেয়, আর আরও অনেক কিছু দেয়: কোন সার্ভার এই ডোমেইনের মেইল নেয়, কোন CA সার্টিফিকেট দিতে পারবে, কোন সার্ভিস কোন পোর্টে চলছে।

শুধু মনে রাখার সুবিধাই না, DNS একটা indirection layer। আপনার সার্ভার বদলালে IP বদলায়, কিন্তু নাম একই থাকে। ইউজার, মোবাইল অ্যাপ, অন্য সার্ভিস সবাই নাম ধরে রাখে; আপনি শুধু DNS-এ রেকর্ডটা বদলে দেন। ক্লাউডে যেখানে IP প্রায়ই বদলায়, সেখানে এই indirection ছাড়া কিছুই চলত না।

ইতিহাস: একটা ফাইল থেকে একটা সিস্টেম

১৯৭০-এর দশকে ARPANET-এ কয়েকশো হোস্ট ছিল। সব হোস্টের নাম আর অ্যাড্রেস থাকত একটা ফাইলে, HOSTS.TXT, যেটা রাখত Stanford Research Institute-এর Network Information Center (SRI-NIC)। কেউ নতুন হোস্ট যোগ করতে চাইলে SRI-NIC-কে জানাত, আর সবাই নিয়মিত FTP দিয়ে ফাইলটার নতুন কপি নামাত।

হোস্ট বাড়তে থাকায় তিনটা সমস্যা দেখা দিল:

• স্কেল: প্রতিটা হোস্ট পুরো ফাইল নামায়, আর ফাইল প্রতিদিন বড় হয়। SRI-NIC-এর লোড আর নেটওয়ার্ক ট্রাফিক দুটোই অসহনীয়।
• নামের সংঘর্ষ: দুজন একই নাম চাইলে কে পাবে? একটা ফ্ল্যাট লিস্টে নাম ফুরিয়ে যায়।
• কনসিস্টেন্সি: নতুন কপি সব জায়গায় পৌঁছানোর আগেই ফাইল আবার বদলে যায়।

১৯৮৩ সালে Paul Mockapetris RFC 882 ও 883-এ DNS-এর প্রস্তাব দেন, আর ১৯৮৭ সালের RFC 1034 ও 1035 আজও DNS-এর মূল স্পেসিফিকেশন। মূল আইডিয়া তিনটা: নামকে একটা গাছে সাজাও, গাছের একেকটা অংশের দায়িত্ব একেকজনকে দাও, আর উত্তর ক্যাশ করো।

মজার ব্যাপার, HOSTS.TXT-এর বংশধর আজও আপনার কম্পিউটারে আছে: /etc/hosts (Windows-এ C:\Windows\System32\drivers\etc\hosts)। আট নম্বর চ্যাপ্টারে দেখবেন, এই ফাইল এখনো DNS-এর আগে চেক হয়, আর এটা অনেক “অদ্ভুত” বাগের উৎস।

নামের গাছ (Namespace)

DNS-এর সব নাম একটা উল্টো গাছের অংশ। গাছের গোড়া হলো root, যার নাম খালি, লেখা হয় একটা ডট দিয়ে: .

গাছের প্রতিটা নোডের একটা label আছে। একটা ডোমেইন নাম হলো নোড থেকে root পর্যন্ত সব label, ডট দিয়ে জোড়া, বাম থেকে ডানে নির্দিষ্ট থেকে সাধারণে:

www.baytalhikma.org.
│   │           │  └── root (empty label)
│   │           └───── TLD (top-level domain)
│   └───────────────── second-level domain (SLD)
└───────────────────── subdomain / host label

স্তর	উদাহরণ	কে চালায়
Root	.	IANA (ICANN-এর একটা ফাংশন) zone-টা ম্যানেজ করে, ১২টা অপারেটর ১৩টা root server নাম চালায়
TLD	org, com, bd, dev	একেকটা registry (যেমন .org-এর জন্য Public Interest Registry, .bd-এর জন্য BTCL)
Second-level	baytalhikma.org	যে ডোমেইনটা কিনেছে, মানে আপনি
Subdomain	api.baytalhikma.org	আপনি, যত খুশি বানাতে পারেন

TLD কয়েক রকম:

• gTLD (generic): .com, .org, .net, এবং ২০১২-র পরের নতুন gTLD যেমন .dev, .app, .shop।
• ccTLD (country code): দুই অক্ষরের দেশের কোড, .bd, .uk, .tr। প্রতিটা দেশের নিজস্ব নিয়ম।
• IDN ccTLD: দেশের নিজের লিপিতে TLD, যেমন বাংলাদেশের .বাংলা।
• Infrastructure TLD: .arpa, যেটা রিভার্স লুকআপের (IP থেকে নাম) জন্য। তিন নম্বর চ্যাপ্টারে PTR রেকর্ডে আসবে।

FQDN আর শেষের অদৃশ্য ডট

FQDN (Fully Qualified Domain Name) হলো এমন নাম যেটা root পর্যন্ত পুরোটা বলে দেয়, তাই এর মানে নিয়ে কোনো দ্বিধা থাকে না। টেকনিক্যালি একটা FQDN শেষ হয় একটা ডট দিয়ে: www.baytalhikma.org.

ব্রাউজারে আপনি ডটটা লেখেন না, কারণ সফটওয়্যার ধরে নেয়। কিন্তু দুটো জায়গায় এই ডট সত্যিই গুরুত্বপূর্ণ:

১. Zone ফাইলে। সাত নম্বর চ্যাপ্টারে আমরা zone ফাইল লিখব। সেখানে ডট ছাড়া নাম মানে “এই zone-এর নামের সাথে জুড়ে দাও”। নিচের ভুলটা প্রতি বছর অসংখ্য মানুষ করে:

$ORIGIN baytalhikma.org.

; correct: ends with a dot, means exactly this name
www     IN  CNAME  cdn.example.net.

; wrong: no dot, becomes cdn.example.net.baytalhikma.org.
www     IN  CNAME  cdn.example.net

২. Search domain-এ। আপনার OS-এ একটা “search list” থাকতে পারে (যেমন অফিস নেটওয়ার্কে corp.example)। আপনি ping db লিখলে OS চেষ্টা করে db.corp.example। শেষে ডট দিলে (db.) search list পুরো বাদ যায়। Kubernetes-এ এই আচরণ বড় পারফরম্যান্স সমস্যা তৈরি করে, যেটা আট নম্বর চ্যাপ্টারে বিস্তারিত দেখব।

# Ask for the exact name, no search-list expansion
dig www.baytalhikma.org.

নামের নিয়ম

DNS-এর নাম নিয়ে কয়েকটা কঠিন সীমা আছে (RFC 1035):

নিয়ম	সীমা
একটা label-এর দৈর্ঘ্য	সর্বোচ্চ ৬৩ অক্ষর (বাইট)
পুরো নাম (ওয়্যার ফরম্যাটে)	সর্বোচ্চ ২৫৫ বাইট, যা লেখায় মোটামুটি ২৫৩ অক্ষর
গাছের গভীরতা	সর্বোচ্চ ১২৭ স্তর (২৫৫ বাইটের সীমা থেকেই আসে)
বড়-ছোট হাতের অক্ষর	case-insensitive: BaytAlHikma.ORG আর baytalhikma.org একই

Hostname-এর নিয়ম আরও কড়া (RFC 952 / 1123, “LDH rule”): শুধু অক্ষর (letter), সংখ্যা (digit) আর হাইফেন (hyphen), আর হাইফেন দিয়ে শুরু বা শেষ হতে পারবে না। DNS নিজে কিন্তু যেকোনো বাইট মেনে নেয়; তাই _dmarc.baytalhikma.org বা _443._tcp.api.baytalhikma.org-এর মতো আন্ডারস্কোর দেওয়া নাম বৈধ DNS নাম, শুধু hostname না। এই আন্ডারস্কোর নামগুলো ইচ্ছা করেই ব্যবহার হয় যাতে কোনো আসল হোস্টের নামের সাথে সংঘর্ষ না হয়। নয় নম্বর চ্যাপ্টারে ইমেইলের রেকর্ডে এগুলো দেখবেন।

Domain বনাম Zone

এই দুটো শব্দ অনেকে একই অর্থে ব্যবহার করেন, কিন্তু ডিবাগিংয়ের সময় পার্থক্যটা খুব কাজে লাগে।

• Domain হলো গাছের একটা ডাল এবং তার নিচের সবকিছু। baytalhikma.org domain-এর মধ্যে www.baytalhikma.org, api.baytalhikma.org, eu.api.baytalhikma.org সবই আছে।
• Zone হলো গাছের সেই অংশ যেটা একটা নির্দিষ্ট authoritative সার্ভার (বা সার্ভার গ্রুপ) চালায়। যেখানে দায়িত্ব অন্য কাউকে দিয়ে দেওয়া হয়, সেখানে zone শেষ। এই সীমানাকে বলে zone cut বা delegation point।

উদাহরণ: baytalhikma.org zone-এ আপনি www আর mail রাখলেন, কিন্তু eu.baytalhikma.org-এর দায়িত্ব দিলেন ইউরোপের টিমকে, যারা অন্য DNS প্রোভাইডার ব্যবহার করে:

; inside the baytalhikma.org zone
www     IN  A    192.0.2.10
mail    IN  A    192.0.2.20

; delegation: eu.baytalhikma.org is now a separate zone
eu      IN  NS   ns1.eu-dns.example.
eu      IN  NS   ns2.eu-dns.example.

এখন baytalhikma.org domain-টা দুইটা zone-এ ভাগ হয়ে গেল। api.eu.baytalhikma.org খুঁজলে আপনার সার্ভার উত্তর দেবে না, বলবে “ওদিকে যাও”, ঠিক যেমন জিপিও লালবাগের চিঠি লালবাগ পোস্ট অফিসে পাঠিয়ে দেয়। এই “ওদিকে যাও” উত্তরকে বলে referral, পরের চ্যাপ্টারের মূল বিষয়।

ডিবাগিংয়ের সময় প্রথম প্রশ্নই হবে: “এই নামের জন্য কোন zone authoritative?” কারণ আপনি হয়তো ভুল প্রোভাইডারের ড্যাশবোর্ডে রেকর্ড বদলাচ্ছেন।

বাংলা ডোমেইন: IDN আর Punycode

DNS প্রোটোকল মূলত ASCII-র জন্য বানানো। তাহলে .বাংলা কীভাবে কাজ করে? উত্তর: IDNA (Internationalized Domain Names in Applications)। ব্রাউজার বা অ্যাপ নামটাকে DNS-এ পাঠানোর আগে Punycode দিয়ে ASCII-তে রূপান্তর করে, আর সামনে xn-- জুড়ে দেয়।

python3 -c "print('বাংলা'.encode('idna'))"
# b'xn--54b7fta0cc'

python3 -c "print('ঢাকা'.encode('idna'))"
# b'xn--p5bz3fb'

DNS সার্ভার কখনো বাংলা অক্ষর দেখে না; সে দেখে শুধু xn--54b7fta0cc। .বাংলা TLD-টা আসলেই root zone-এ আছে, আর এর nameserver দেখতে পারেন:

$ dig +short NS xn--54b7fta0cc.
ekushey.btcl.net.bd.
bayanno.btcl.net.bd.
bd-ns.anycast.pch.net.

(nameserver-এর নামগুলো ২০২৬ সালের অক্টোবরে নেওয়া; সময়ের সাথে বদলাতে পারে, নিজে চালিয়ে দেখুন।) ekushey আর bayanno নাম দুটো ভালো করে খেয়াল করুন।

DNS কী না

নতুনদের অনেক বিভ্রান্তি আসে DNS-কে এমন কাজের দায় দেওয়া থেকে যেটা সে করে না:

• DNS ট্রাফিক রাউট করে না। DNS শুধু একটা IP বলে দেয়। প্যাকেট কোন পথে যাবে সেটা ঠিক করে IP রাউটিং (BGP)। DNS ঠিক থাকলেও সার্ভারে না পৌঁছাতে পারলে সমস্যা নেটওয়ার্কে।
• DNS পোর্ট জানে না। A রেকর্ডে শুধু IP থাকে। baytalhikma.org:8080 লিখলে 8080 DNS-এর কাছে যায়ই না। (SRV আর HTTPS রেকর্ড এর ব্যতিক্রম, তিন নম্বর চ্যাপ্টারে।)
• DNS HTTP redirect করে না। ”baytalhikma.org থেকে www.baytalhikma.org-এ redirect” এটা ওয়েব সার্ভারের কাজ। DNS শুধু দুটো নামকে কোনো IP দিতে পারে; URL বদলানো HTTP-র 301/308 দিয়ে হয়। কিছু DNS প্রোভাইডার “URL redirect record” দেয়, সেটা আসলে তাদের একটা ওয়েব সার্ভার যেটা redirect পাঠায়।
• DNS পাথ জানে না। baytalhikma.org/books আর baytalhikma.org/api এর জন্য আলাদা IP দেওয়া DNS দিয়ে সম্ভব না। DNS-এর কাছে আসে শুধু hostname।
• DNS পরিবর্তন সঙ্গে সঙ্গে সব জায়গায় পৌঁছায় না। ক্যাশ আছে, চার নম্বর চ্যাপ্টারে বিস্তারিত।

https://api.baytalhikma.org:8443/books?id=7
        └──────┬──────────┘
     only this part goes to DNS

একটু হাতে-কলমে

টার্মিনাল খুলে চালান:

# The simplest question: what is the IPv4 address of this name?
dig +short example.com A

# The same for IPv6
dig +short example.com AAAA

# Who is authoritative for this zone?
dig +short example.com NS

# Who runs the .org TLD?
dig +short org. NS

# And the root itself
dig +short . NS

শেষ কমান্ডটা আপনাকে a.root-servers.net. থেকে m.root-servers.net. পর্যন্ত ১৩টা নাম দেবে। root-servers.org অনুযায়ী (২০২৬ সালের অক্টোবর) এই ১৩টা নাম চালায় ১২টা স্বাধীন অপারেটর (Verisign একাই A আর J চালায়), আর anycast-এর মাধ্যমে পৃথিবীজুড়ে এদের দুই হাজারের বেশি instance আছে। সংখ্যাটা নিয়মিত বাড়ে, তাই root-servers.org-এ সর্বশেষটা দেখে নিন। “১৩টা root server” কথাটা তাই বিভ্রান্তিকর: ১৩টা হলো নাম, মেশিন নয়। দশ নম্বর চ্যাপ্টারে anycast বুঝলে এটা পরিষ্কার হবে।

ডিবাগিং: এই চ্যাপ্টারের সমস্যাগুলো

লক্ষণ: CNAME বা MX সেট করলাম, কিন্তু অদ্ভুত নাম ফেরত আসছে, যেমন cdn.example.net.baytalhikma.org। নিশ্চিত হোন:

dig +short www.baytalhikma.org CNAME
# cdn.example.net.baytalhikma.org.   <- zone name got appended

কারণ: zone ফাইলে বা প্রোভাইডারের ফর্মে টার্গেটের শেষে ডট নেই, তাই origin জুড়ে গেছে। ঠিক করুন: টার্গেটকে FQDN হিসেবে লিখুন, শেষে ডট দিয়ে। কিছু প্রোভাইডারের ওয়েব UI নিজেই ডট বসায়, কিছু বসায় না; UI-র ডকুমেন্টেশন দেখুন।

লক্ষণ: আমার মেশিনে db রিজলভ হয়, সার্ভারে হয় না (বা উল্টো)। নিশ্চিত হোন:

cat /etc/resolv.conf     # look at the "search" line
dig db.                  # exact name, no search list
dig db.corp.example.     # what the search list was actually expanding to

কারণ: দুই মেশিনের search domain আলাদা। ঠিক করুন: কনফিগে সবসময় পূর্ণ FQDN ব্যবহার করুন, ছোট নাম না।

লক্ষণ: রেকর্ড বদলালাম কিন্তু কোনো পরিবর্তন দেখছি না। নিশ্চিত হোন: আপনি কি আসলেই authoritative zone-এ বদলাচ্ছেন?

dig +short baytalhikma.org NS
# compare with the provider whose dashboard you are editing

কারণ: অনেকে ডোমেইন কেনেন এক জায়গা থেকে আর DNS চালান অন্য জায়গায়; রেজিস্ট্রারের ড্যাশবোর্ডে রেকর্ড বদলালে কিছু হয় না যদি NS অন্য প্রোভাইডারের দিকে থাকে। ছয় নম্বর চ্যাপ্টারে বিস্তারিত। আর যদি NS ঠিকই থাকে, তাহলে সম্ভবত ক্যাশ (চার নম্বর চ্যাপ্টার)।

লক্ষণ: সাবডোমেইনে রেকর্ড যোগ করলাম, কিন্তু উত্তর আসছে অন্য কোথাও থেকে বা আসছেই না। নিশ্চিত হোন:

dig +short eu.baytalhikma.org NS

কারণ: সাবডোমেইনটা আলাদা zone হিসেবে delegate করা আছে; আপনার parent zone-এ রাখা রেকর্ড কেউ দেখবে না। ঠিক করুন: রেকর্ডটা যে zone authoritative সেখানে রাখুন, অথবা delegation সরিয়ে দিন।

লক্ষণ: বাংলা বা অন্য লিপির ডোমেইন কোনো টুলে কাজ করে, কোনোটায় করে না। নিশ্চিত হোন: টুলটা কি IDNA রূপান্তর করে? সরাসরি Punycode দিয়ে চেষ্টা করুন:

dig xn--54b7fta0cc. NS

কারণ: পুরনো টুল বা লাইব্রেরি Unicode নাম সরাসরি পাঠায়, যেটা কোনো রেকর্ডের সাথে মেলে না। ঠিক করুন: কোডে নাম পাঠানোর আগে IDNA এনকোড করুন।

মূল শিক্ষা

1. DNS নাম থেকে ডেটা দেয়, আর এটা একটা indirection layer: IP বদলায়, নাম একই থাকে।
2. নাম একটা গাছ। ডান থেকে বামে পড়লে root → TLD → second-level → subdomain।
3. FQDN শেষ হয় ডট দিয়ে। Zone ফাইলে ডট ভুলে গেলে origin জুড়ে যায়, এটা সবচেয়ে কমন কনফিগ বাগ।
4. Domain হলো গাছের ডাল, zone হলো দায়িত্বের এলাকা। Delegation দিয়ে একটা domain একাধিক zone-এ ভাগ হয়।
5. সীমা: label ৬৩, পুরো নাম ২৫৫ বাইট, case-insensitive।
6. বাংলা ডোমেইন Punycode হয়ে যায় (.বাংলা = xn--54b7fta0cc)। DNS শুধু ASCII দেখে।
7. DNS রাউটিং, পোর্ট, পাথ বা HTTP redirect জানে না। এগুলো নিয়ে সমস্যা হলে DNS-এর বাইরে খুঁজুন।