DNS: জিরো টু মাস্টারি · ইন্টারমিডিয়েট · ২২ মিনিট · 06 / 16

ডোমেইন, রেজিস্ট্রার ও রেজিস্ট্রি

একটা ডোমেইনের পেছনে চারটা আলাদা পক্ষ থাকতে পারে। delegation, glue, WHOIS থেকে RDAP, EPP status, এক্সপায়ারির জীবনচক্র, ট্রান্সফার, আর ডাউনটাইম ছাড়া DNS হোস্ট বদলানো।

dnsregistrarregistrydelegationgluerdapeppdomain transfer

গল্পে বুঝি

কিন্দি সাভারে এক টুকরো জমি কিনবে। বিক্রেতা ফারাবি। দুজনে মিলে দলিল লেখক (মুহুরি) খোয়ারিজমির কাছে যায়, সে দলিল তৈরি করে সাব-রেজিস্ট্রি অফিসে জমা দেয়। সরকারি খতিয়ানে, মানে সরকারের মূল খাতায়, জমিটা কিন্দির নামে ওঠে, নামজারি হয়। কিন্দি নিজে কখনো সরকারি খাতায় হাত দেয় না; খাতা রাখে ভূমি অফিস, আর তাতে এন্ট্রি তোলে শুধু অনুমোদিত মুহুরিরা।

জমি তো হলো, কিন্তু কিন্দি থাকে ঢাকায়। তাই সে স্থানীয় কেয়ারটেকার ফাতিমাকে দায়িত্ব দেয়: কেউ জমির খোঁজে এলে ফাতিমা দেখিয়ে দেবে কোন প্লটে কী আছে, কোথায় গেট, কার কাছে চাবি। ভূমি অফিসের খাতায় শুধু লেখা থাকে “এই জমির মালিক কিন্দি, তথ্যের জন্য যোগাযোগ: ফাতিমা”। বিস্তারিত জমির নকশা থাকে ফাতিমার কাছে। কিন্দি পরে কেয়ারটেকার বদলাতে চাইলে, নতুন জনকে নকশা বুঝিয়ে দেওয়া যথেষ্ট না; ভূমি অফিসের খাতায় “যোগাযোগ: ফাতিমা” বদলে নতুন নাম তুলতে হবে, নইলে লোকে ফাতিমার কাছেই যেতে থাকবে।

খাজনা দিতে ভুলে গেলে কী হয়? সাথে সাথে জমি চলে যায় না। প্রথমে কিছুদিন জরিমানা ছাড়াই দেওয়ার সুযোগ, তারপর জরিমানাসহ উদ্ধারের সুযোগ, তারপর নিলাম। আর জমিতে কোনো মামলা থাকলে খাতায় একটা “হস্তান্তর নিষেধ” চিহ্ন বসে যায়, তখন কেউ চাইলেও বিক্রি করতে পারে না।

মিলিয়ে নিই: সরকারি খতিয়ান রাখা ভূমি অফিস হলো registry (.com-এর জন্য Verisign, .bd-এর জন্য BTCL), অনুমোদিত মুহুরি খোয়ারিজমি হলো registrar, মালিক কিন্দি হলো registrant, আর কেয়ারটেকার ফাতিমা হলো DNS host (authoritative nameserver)। খাতার “যোগাযোগ: ফাতিমা” লাইনটা হলো delegation NS রেকর্ড, আর কেয়ারটেকার বদলালে খাতা বদলানো মানে রেজিস্ট্রারে nameserver আপডেট। খাজনার ধাপগুলো হলো grace period, redemption, pending delete, আর “হস্তান্তর নিষেধ” চিহ্ন হলো clientTransferProhibited-এর মতো EPP status। বাস্তবে “আমার DNS কাজ করছে না” টিকেটের বড় একটা অংশ আসলে এই চার পক্ষের কোনটা কী করে তা গুলিয়ে ফেলা।

চারটা ভূমিকা, চারটা কোম্পানি হতে পারে

ভূমিকা	কী করে	উদাহরণ
Registry	একটা TLD-এর মূল ডেটাবেস রাখে, TLD-এর nameserver চালায়	`.com`/`.net`: Verisign; `.org`: PIR; `.bd`: BTCL
Registrar	রেজিস্ট্রি থেকে আপনার হয়ে ডোমেইন কেনে, রিনিউ করে, NS বসায়	যেকোনো ডোমেইন বিক্রেতা কোম্পানি
Registrant	ডোমেইনের আইনি মালিক	আপনি বা আপনার কোম্পানি
DNS host	authoritative nameserver চালায়, যেখানে আপনার রেকর্ড থাকে	রেজিস্ট্রার নিজে, CDN কোম্পানি, বা নিজের সার্ভার

ওপরে ICANN — gTLD (.com, .org, নতুন .dev-ধরনের) জগতের নিয়ম বানায় আর রেজিস্ট্রারদের অনুমোদন দেয়। ccTLD (.bd, .uk, .de) দেশের নিজস্ব নিয়মে চলে, ICANN-এর gTLD নীতি সেখানে খাটে না।

.bd সম্পর্কে: IANA-র রেকর্ড অনুযায়ী .bd-এর রেজিস্ট্রি Bangladesh Telecommunications Company Limited (BTCL), রেজিস্ট্রেশন পোর্টাল bdia.btcl.com.bd (২০২৬ সালের অক্টোবর অনুযায়ী)। ঐতিহ্যগতভাবে নাম নিতে হতো তৃতীয় স্তরে (example.com.bd, example.org.bd), সরাসরি example.bd-এর নিয়ম আর দাম সময়ের সাথে বদলেছে। এখনকার শর্ত BTCL-এর পোর্টালেই যাচাই করুন।

সবচেয়ে গুরুত্বপূর্ণ কথা: রেজিস্ট্রার আর DNS host এক জায়গায় হতেই হবে এমন না। অনেকে ডোমেইন কেনে এক কোম্পানি থেকে, DNS রাখে আরেকটায়। তখন দুটো প্যানেল থাকে, আর রেকর্ড এডিট গোনা হয় শুধু সেই প্যানেলে যেখানে NS পয়েন্ট করা। রেজিস্ট্রারের প্যানেলেও হয়তো একটা “DNS records” পাতা আছে, কিন্তু NS অন্য কোথাও পয়েন্ট করা থাকলে সেই পাতার এডিট কেউ দেখবেই না।

# Who is actually serving my records right now?
dig +short baytalhikma.org NS

এই উত্তর যে কোম্পানির nameserver দেখায়, শুধু সেখানের এডিট কাজে লাগে।

Delegation: parent কীভাবে child-কে চেনায়

.org zone-এর ভেতরে baytalhikma.org-এর কোনো A রেকর্ড নেই। আছে শুধু একটা ইঙ্গিত: “এই নামের উত্তর দেবে অমুক nameserver”। এটাই delegation।

# Ask one of the .org TLD servers directly, recursion off
dig +norecurse @$(dig +short org NS | head -n 1) baytalhikma.org A

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

;; AUTHORITY SECTION:
baytalhikma.org.	3600	IN	NS	ns1.dnshost.example.
baytalhikma.org.	3600	IN	NS	ns2.dnshost.example.

aa নেই, ANSWER খালি, AUTHORITY-তে NS। এটা একটা referral: “আমি জানি না, ওদের জিজ্ঞেস করো”। এই NS রেকর্ডগুলো আপনি রেজিস্ট্রারের প্যানেলে “Nameservers” ঘরে বসান; রেজিস্ট্রার EPP প্রোটোকল দিয়ে সেটা রেজিস্ট্রিতে পাঠায়, রেজিস্ট্রি নিজের zone-এ তোলে।

একই NS রেকর্ড আপনার নিজের zone-এর apex-এও থাকে। দুই জায়গার NS মেলা উচিত। না মিললে resolver কখনো এটা, কখনো ওটা বিশ্বাস করবে, আর আচরণ resolver সফটওয়্যারভেদে আলাদা হবে।

# Parent's view (what the registry publishes)
dig +trace +nodnssec baytalhikma.org NS | grep -E '^baytalhikma' | head -n 4

# Child's view (what your own zone says)
dig +short @ns1.dnshost.example baytalhikma.org NS

Glue: মুরগি আগে না ডিম আগে

ধরুন আপনার nameserver-এর নাম ns1.baytalhikma.org, মানে nameserver আপনার নিজের zone-এর ভেতরে (in-bailiwick)। resolver-কে .org বলল ”baytalhikma.org-এর জন্য ns1.baytalhikma.org-কে জিজ্ঞেস করো”। কিন্তু ns1.baytalhikma.org-এর IP জানতে হলে তো baytalhikma.org-কেই জিজ্ঞেস করতে হবে। চক্র।

সমাধান glue record: parent referral-এর সাথে ADDITIONAL সেকশনে nameserver-এর IP-ও দিয়ে দেয়।

; illustrative output — referral with glue
;; AUTHORITY SECTION:
baytalhikma.org.	3600	IN	NS	ns1.baytalhikma.org.
baytalhikma.org.	3600	IN	NS	ns2.baytalhikma.org.

;; ADDITIONAL SECTION:
ns1.baytalhikma.org.	3600	IN	A	203.0.113.53
ns2.baytalhikma.org.	3600	IN	A	198.51.100.53

রেজিস্ট্রারের প্যানেলে এটা সাধারণত “Register nameserver”, “Child nameserver” বা “Host records” নামে থাকে। আপনি সেখানে ns1.baytalhikma.org → 203.0.113.53 বসান, রেজিস্ট্রার রেজিস্ট্রিতে একটা host object বানায়।

glue-এর ফাঁদ: nameserver সার্ভারের IP বদলালেন, নিজের zone-এ ns1-এর A রেকর্ডও বদলালেন, কিন্তু রেজিস্ট্রারে glue বদলালেন না। parent এখনো পুরনো IP দিচ্ছে, resolver পুরনো IP-তে যাচ্ছে, টাইমআউট। নিজের zone-এর ভেতরে nameserver রাখলে IP বদলানোর চেকলিস্টে রেজিস্ট্রারের glue রাখুন। যাদের nameserver অন্য ডোমেইনে (ns1.dnshost.example), তাদের glue লাগে না, এই ঝামেলাও নেই।

রেজিস্ট্রার থেকে resolver পর্যন্ত delegation কীভাবে যায়

WHOIS থেকে RDAP

ডোমেইনের মালিকানা, রেজিস্ট্রার, তারিখ আর status জানার পুরনো উপায় ছিল WHOIS (পোর্ট 43, সাদা টেক্সট, প্রতিটা রেজিস্ট্রির আলাদা ফরম্যাট)। এর জায়গা নিয়েছে RDAP: HTTPS-এর ওপর JSON, নির্দিষ্ট ফরম্যাট।

ICANN-এর ২০২৩ সালের চুক্তি সংশোধন অনুযায়ী, gTLD রেজিস্ট্রার আর বেশিরভাগ gTLD রেজিস্ট্রির WHOIS চালু রাখার বাধ্যবাধকতা শেষ হয়েছে ২৮ জানুয়ারি ২০২৫; এখন RDAP হলো বাধ্যতামূলক উৎস। অনেকে এখনো WHOIS সমান্তরালে চালায়, আর ccTLD-গুলো এই নিয়মের বাইরে, তাই .bd বা অন্য দেশের ডোমেইনে আচরণ আলাদা হতে পারে।

# RDAP via a bootstrap redirector (finds the right registry for you)
curl -sL https://rdap.org/domain/baytalhikma.org | jq '{status, events, nameservers: [.nameservers[].ldhName]}'

# Old-school, still works for many TLDs
whois baytalhikma.org

; illustrative output (trimmed)
{
  "status": ["client transfer prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "2019-04-11T08:12:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-04-11T08:12:00Z" }
  ],
  "nameservers": ["NS1.DNSHOST.EXAMPLE", "NS2.DNSHOST.EXAMPLE"]
}

ডিবাগিংয়ে RDAP তিনটা প্রশ্নের উত্তর দেয় যা dig দেয় না: মেয়াদ কবে শেষ, ডোমেইনে কোনো hold আছে কিনা, আর রেজিস্ট্রি কোন nameserver রেকর্ড করেছে। মালিকের নাম-ঠিকানা এখন প্রায় সবসময় privacy-র কারণে লুকানো থাকে।

EPP status code: ডোমেইনের গায়ের চিহ্ন

রেজিস্ট্রি প্রতিটা ডোমেইনে কিছু status বসায়। client দিয়ে শুরু মানে রেজিস্ট্রার বসিয়েছে (আপনি অনুরোধ করে সরাতে পারেন), server দিয়ে শুরু মানে রেজিস্ট্রি বসিয়েছে (রেজিস্ট্রারের মাধ্যমে রেজিস্ট্রিকে বলতে হবে)।

status	মানে	DNS-এ প্রভাব
`ok` / active	কোনো বিধিনিষেধ নেই	স্বাভাবিক
`clientTransferProhibited`	রেজিস্ট্রার লক; অন্য রেজিস্ট্রারে নেওয়া যাবে না	কিছু না — এটা থাকাই উচিত
`clientUpdateProhibited`	NS বা কন্টাক্ট বদলানো যাবে না	কিছু না, কিন্তু NS বদলাতে আগে সরাতে হবে
`clientDeleteProhibited`	মুছে ফেলা যাবে না	কিছু না
`serverTransferProhibited` ইত্যাদি	একই, রেজিস্ট্রি স্তরে (“registry lock”)	কিছু না — দামি ডোমেইনে সুরক্ষা
`clientHold`	রেজিস্ট্রার ডোমেইন zone থেকে নামিয়ে দিয়েছে	পুরো ডোমেইন NXDOMAIN
`serverHold`	রেজিস্ট্রি zone থেকে নামিয়ে দিয়েছে	পুরো ডোমেইন NXDOMAIN
`autoRenewPeriod`	মেয়াদ শেষ, রেজিস্ট্রি অটো-রিনিউ করেছে, এখনো ফেরানো যায়	রেজিস্ট্রারের নীতিভেদে চলতে বা থামতে পারে
`redemptionPeriod`	মুছে ফেলার প্রক্রিয়ায়, ফি দিয়ে উদ্ধার সম্ভব	সাধারণত resolve হয় না
`pendingDelete`	চূড়ান্ত মুছে যাওয়ার অপেক্ষা, উদ্ধার আর সম্ভব না	resolve হয় না
`pendingTransfer`	ট্রান্সফার চলছে	সাধারণত স্বাভাবিক

clientHold বা serverHold দেখলে DNS প্যানেলে কিছু ঠিক করার নেই। ডোমেইন রেজিস্ট্রির zone থেকেই নেই, আপনার nameserver যত নিখুঁতই হোক। সাধারণ কারণ: রিনিউ বাকি, রেজিস্ট্রেন্টের ইমেইল ভেরিফাই হয়নি (ICANN-এর নিয়মে নতুন বা বদলানো কন্টাক্ট যাচাই করতে হয়), পেমেন্ট বিবাদ, বা অ্যাবিউজ রিপোর্ট। রেজিস্ট্রারের সাপোর্টে যোগাযোগ করুন, আর রেজিস্ট্রেন্ট ইমেইলের ইনবক্স আর স্প্যাম ফোল্ডার দেখুন।

এক্সপায়ারির জীবনচক্র

মেয়াদ শেষ হওয়ার দিনই ডোমেইন হারায় না। gTLD-এ সাধারণ ধাপগুলো এমন (সময়কাল আনুমানিক এবং রেজিস্ট্রারভেদে আলাদা; ২০২৬ সালের অক্টোবর অনুযায়ী সাধারণ চিত্র, নিজের রেজিস্ট্রারের নীতি দেখে নিন):

মেয়াদ শেষ — রেজিস্ট্রার হয়তো তখনই ওয়েবসাইট বন্ধ করে নিজের “পার্কিং” পেজ দেখাতে শুরু করে, NS বদলে দিয়ে। আপনার সাইট আর ইমেইল তখনই ভাঙতে পারে।
Auto-renew grace period — রেজিস্ট্রারভেদে কয়েক দিন থেকে প্রায় ৪৫ দিন পর্যন্ত। সাধারণ দামে রিনিউ করা যায়।
Redemption grace period — সাধারণত ৩০ দিন। ডোমেইন মুছে ফেলার প্রক্রিয়ায়; উদ্ধার করা যায় কিন্তু সাধারণ দামের চেয়ে অনেক বেশি ফি দিয়ে।
Pending delete — সাধারণত ৫ দিন। কিছুই করা যায় না।
মুছে যায় — যে কেউ কিনতে পারে। দামি নাম প্রায়ই সেকেন্ডের মধ্যে “drop catching” সার্ভিস কিনে নেয়।

ccTLD-এর নিয়ম সম্পূর্ণ আলাদা হতে পারে। শিক্ষা একটাই: অটো-রিনিউ চালু রাখুন, রেজিস্ট্রেন্ট ইমেইল এমন ঠিকানায় রাখুন যেটা ওই ডোমেইনের ওপর নির্ভর করে না (নইলে ডোমেইন বন্ধ হলে সতর্কবার্তার ইমেইলও আর পৌঁছাবে না), আর মেয়াদের তারিখ মনিটর করুন (চ্যাপ্টার ১৫)।

রেজিস্ট্রার ট্রান্সফার

ডোমেইন এক রেজিস্ট্রার থেকে আরেকটায় নেওয়া:

পুরনো রেজিস্ট্রারে clientTransferProhibited (রেজিস্ট্রার লক) বন্ধ করুন।
auth code (EPP authInfo, “transfer code”, “EPP code”) সংগ্রহ করুন।
নতুন রেজিস্ট্রারে ট্রান্সফার শুরু করুন, auth code দিন।
পুরনো রেজিস্ট্রার কয়েক দিনের মধ্যে অনুমোদন দেয় বা নিজে থেকে হয়ে যায়।
নতুন রেজিস্ট্রারে লক আবার চালু করুন।

কিছু বিষয় খেয়াল রাখুন:

ট্রান্সফারে nameserver সাধারণত বদলায় না — রেজিস্ট্রি NS রেকর্ড যেমন ছিল তেমনই রাখে। কিন্তু যদি আপনার DNS পুরনো রেজিস্ট্রারের ফ্রি DNS-এ থাকে, আর ট্রান্সফারের পর তারা সেই zone মুছে দেয়, সাইট পড়ে যাবে। ট্রান্সফারের আগে DNS অন্য কোথাও সরিয়ে নিন (নিচের অংশ), অথবা নিশ্চিত হন পুরনো zone থাকবে।
লক পিরিয়ড — gTLD-এ নতুন রেজিস্ট্রেশন আর ট্রান্সফারের পর দীর্ঘদিন ধরে ৬০ দিনের ট্রান্সফার লক চালু আছে। ICANN এই নীতি সংশোধনের প্রক্রিয়ায় আছে (লক ছোট করা আর রেজিস্ট্রেন্ট বদলানোর পরের লক তুলে দেওয়ার সুপারিশ অনুমোদিত হয়েছে, কিন্তু ২০২৬ সালের অক্টোবর অনুযায়ী তা কার্যকর হয়নি)। আপনার ক্ষেত্রে এখন কী খাটে, রেজিস্ট্রারকে জিজ্ঞেস করুন।
DNSSEC — DNS host-ও বদলালে DNSSEC সাবধানে সামলাতে হবে, নইলে পুরো ডোমেইন SERVFAIL দেবে (চ্যাপ্টার ১২)।

ডাউনটাইম ছাড়া DNS host বদলানো

এটা রেজিস্ট্রার ট্রান্সফার থেকে আলাদা, আর বেশি ঝুঁকিপূর্ণ। পুরনো DNS host: ns1/ns2.oldhost.example। নতুন: ns1/ns2.newhost.example।

ধাপ ১ — সব রেকর্ড কপি করুন। পুরনো প্রোভাইডার থেকে zone ফাইল এক্সপোর্ট করুন। এক্সপোর্ট না থাকলে প্রতিটা নাম আর টাইপ হাতে তালিকা করুন। সবচেয়ে বেশি বাদ পড়ে: MX, TXT (SPF, DKIM, ভেরিফিকেশন), _dmarc, CAA, আর ভুলে যাওয়া সাবডোমেইন।

ধাপ ২ — নতুন প্রোভাইডারে zone বানিয়ে সরাসরি যাচাই করুন। তখনো NS বদলাননি, তাই বাইরের কেউ নতুন zone দেখছে না, কিন্তু আপনি সরাসরি জিজ্ঞেস করতে পারবেন:

for name in baytalhikma.org www.baytalhikma.org _dmarc.baytalhikma.org; do
  for type in A AAAA CNAME MX TXT CAA; do
    old=$(dig +short @ns1.oldhost.example "$name" "$type" | sort)
    new=$(dig +short @ns1.newhost.example "$name" "$type" | sort)
    [ "$old" = "$new" ] || printf 'MISMATCH %s %s\n  old: %s\n  new: %s\n' "$name" "$type" "$old" "$new"
  done
done

কোনো MISMATCH না আসা পর্যন্ত এগোবেন না।

ধাপ ৩ — নতুন zone-এর apex NS নতুন প্রোভাইডারের দিকে রাখুন। নতুন প্রোভাইডার সাধারণত নিজে করে দেয়। পুরনো zone-এর NS-ও চাইলে নতুনগুলোর দিকে বদলে দিতে পারেন, তাতে পুরনো zone-এ আসা resolver-রাও নতুন দিকে যেতে শিখবে।

ধাপ ৪ — DNSSEC থাকলে আগে সামলান। সহজ পথ: পুরনো প্রোভাইডারে DNSSEC বন্ধ করে রেজিস্ট্রার থেকে DS রেকর্ড সরান, parent-এর DS TTL পেরোনো পর্যন্ত অপেক্ষা করুন, তারপর এগোন। দুই প্রোভাইডারের key একসাথে রাখার পথও আছে (চ্যাপ্টার ১২)।

ধাপ ৫ — রেজিস্ট্রারে nameserver বদলান। রেজিস্ট্রি দ্রুত আপডেট করে, কিন্তু resolver-রা parent-এর delegation TTL পর্যন্ত (.com-এ সাধারণত দুই দিন) পুরনো NS মনে রাখতে পারে।

ধাপ ৬ — অপেক্ষা করুন, দুই জায়গা সিঙ্কে রাখুন। অন্তত দুই দিন (বা আপনার TLD-এর delegation TTL, যেটা বড়) পুরনো প্রোভাইডারের zone মুছবেন না, আর এর মধ্যে কোনো রেকর্ড বদলাতে হলে দুই জায়গাতেই বদলান।

ধাপ ৭ — যাচাই করে পুরনোটা বন্ধ করুন।

dig +trace baytalhikma.org NS | tail -n 6     # parent now points to newhost
dig +short @1.1.1.1 baytalhikma.org NS
dig +short @8.8.8.8 baytalhikma.org NS

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

“DNS প্যানেলে রেকর্ড বদলাচ্ছি, কিছুই হচ্ছে না।” নিশ্চিত হন: dig +short name NS দিয়ে দেখুন NS কোন প্রোভাইডারে। সেটা আপনার এডিট করা প্যানেল না হলে আপনি ভুল জায়গায় এডিট করছেন। সমাধান: হয় সঠিক প্রোভাইডারে এডিট করুন, নয় রেজিস্ট্রারে NS বদলে এই প্রোভাইডারের দিকে আনুন।

“পুরো ডোমেইন হঠাৎ NXDOMAIN, সব সাবডোমেইনসহ।” নিশ্চিত হন: curl -sL https://rdap.org/domain/name | jq .status দিয়ে clientHold/serverHold/redemptionPeriod দেখুন, আর expiration তারিখ। dig +trace-এ TLD যদি নিজেই NXDOMAIN দেয়, ডোমেইন zone থেকে নামানো। সমাধান: রেজিস্ট্রারে রিনিউ বা ইমেইল ভেরিফাই; DNS প্যানেলে কিছু করার নেই।

“nameserver বদলালাম, আর এখন SERVFAIL।” নিশ্চিত হন: dig +cd name চলে কিন্তু dig name চলে না? তাহলে parent-এ পুরনো DS রয়ে গেছে। dig +short name DS দেখুন। সমাধান: রেজিস্ট্রার থেকে DS সরান অথবা নতুন প্রোভাইডারের DS বসান (চ্যাপ্টার ১২)। DNSSEC না থাকলে নতুন nameserver-কে সরাসরি জিজ্ঞেস করুন; REFUSED দিলে zone সেখানে বানানোই হয়নি (একে lame delegation বলে)।

“নিজের nameserver-এর IP বদলানোর পর ডোমেইন টাইমআউট।” নিশ্চিত হন: dig +norecurse @tld-server name NS চালিয়ে ADDITIONAL-এ কোন glue IP আসছে দেখুন। পুরনো IP হলে glue আপডেট হয়নি। সমাধান: রেজিস্ট্রারের “child nameserver” অংশে IP আপডেট করুন।

“ট্রান্সফার আটকে আছে বা প্রত্যাখ্যাত।” নিশ্চিত হন: RDAP-এ clientTransferProhibited এখনো আছে কিনা, সাম্প্রতিক রেজিস্ট্রেশন বা ট্রান্সফারের তারিখ লক পিরিয়ডের মধ্যে কিনা, auth code ঠিক কিনা। সমাধান: লক খুলুন, নতুন auth code নিন, লক পিরিয়ড শেষ হতে দিন।

“রেজিস্ট্রার বদলানোর পরদিন সাইট আর ইমেইল বন্ধ।” নিশ্চিত হন: dig +short name NS এখনো পুরনো রেজিস্ট্রারের DNS দেখায়, আর তাদের সার্ভার এখন REFUSED দেয়। সমাধান: নতুন DNS host-এ zone বানিয়ে NS বদলান; ভবিষ্যতে DNS আগে সরান, রেজিস্ট্রার পরে।

মূল শিক্ষা

registry, registrar, registrant, DNS host — চারটা আলাদা ভূমিকা। রেকর্ড এডিট গোনা হয় শুধু সেখানে, যেখানে NS পয়েন্ট করা।
delegation থাকে parent-এ, রেজিস্ট্রারের মাধ্যমে বসানো। parent আর child-এর NS মেলান।
nameserver নিজের zone-এর ভেতরে হলে glue লাগে, আর IP বদলালে glue-ও বদলাতে হয়।
RDAP বলে যা dig বলে না: মেয়াদ, hold, আর রেজিস্ট্রির রেকর্ড করা NS। gTLD-এ ২৮ জানুয়ারি ২০২৫ থেকে RDAP-ই বাধ্যতামূলক উৎস।
clientHold/serverHold মানে পুরো ডোমেইন zone থেকে নেই। সমাধান রেজিস্ট্রারে, DNS প্যানেলে না।
DNS host বদলানো = সব কপি, সরাসরি যাচাই, DNSSEC সামলানো, NS বদল, delegation TTL পর্যন্ত দুই জায়গা সিঙ্কে।
অটো-রিনিউ চালু, রেজিস্ট্রার লক চালু, আর রেজিস্ট্রেন্ট ইমেইল অন্য ডোমেইনে।