DNS কী: আপনার domain কেন VPS-এ পৌঁছাচ্ছে না

DNS কী এবং আপনার domain এখনও VPS-এ পৌঁছাচ্ছে না কেন

DNS (domain name system) example.com-এর মতো একটি নামকে 203.0.113.10-এর মতো IP (internet protocol) address-এ রূপান্তর করে। Browser কোনো নামের সঙ্গে সংযোগ করতে পারে না। এটি একটি address-এর সঙ্গে সংযোগ করে। তাই প্রতিটি page load একটি DNS প্রশ্ন এবং উত্তরের মাধ্যমে শুরু হয়। আপনি যদি সম্প্রতি একটি domain এবং নিজের VPS কিনে থাকেন, কিন্তু কিছুই load না হয়, তাহলে দুটি কারণের একটি সত্যি: এখনও এমন কোনো record নেই যা নামটিকে আপনার server-এর address-এর সঙ্গে যুক্ত করে, অথবা record আছে কিন্তু সংযোগের কোনো স্তর এখনও পুরোনো উত্তর প্রদান করছে।

দুটি পরিস্থিতিই স্বাভাবিক। কোনোটিই কিছু নষ্ট হয়েছে এমন অর্থ বহন করে না। নিচের section-গুলোতে আপনি যে ক্রমে বিষয়গুলোর মুখোমুখি হবেন, সেই ক্রমেই অংশগুলো ব্যাখ্যা করা হয়েছে। শুরু করা হয়েছে সবচেয়ে বেশি সময় নষ্ট করে এমন বিষয় দিয়ে: আপনার record আসলে কোন control panel-এ রয়েছে।

এখানে প্রতিটি পরীক্ষা dig ব্যবহার করে। নতুন Ubuntu বা Debian machine-এ এটি default হিসেবে installed থাকে না।

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameserver এবং DNS host: কোনটি সম্পাদনা করবেন

এই তিনটি নাম আলাদা কাজ বোঝায়। এগুলো গুলিয়ে ফেললে সম্পাদনা করার পরও কোনো পরিবর্তন না হওয়াই সবচেয়ে সাধারণ সমস্যা।

• registrar হলো যে কোম্পানি থেকে আপনি domain কিনেছেন। এর গুরুত্বপূর্ণ কাজ হলো delegation: এটি আপনার TLD (top-level domain, অর্থাৎ .com অংশ) পরিচালনাকারী registry-কে জানায়, আপনার domain-এর জন্য কোন nameserver-গুলো authoritative।
• authoritative nameserver আপনার zone-এর প্রকৃত record সংরক্ষণ করে। zone হলো আপনার domain এবং এর অধীনে থাকা নামগুলো।
• DNS host হলো যে প্রতিষ্ঠান বা সিস্টেম ওই nameserver-গুলো পরিচালনা করে। এটি registrar নিজেই হতে পারে, আলাদা provider হতে পারে, অথবা আপনার মালিকানাধীন কোনো server-এ চলা bind9 হতে পারে।

আপনি registrar-এর কাছ থেকে domain কিনবেন। সম্পাদনা করবেন DNS host-এ। আপনি যদি domain-টি অন্য কোনো provider-এর nameserver-এ স্থানান্তর করে থাকেন, registrar-এর নিজস্ব DNS panel-এ একটি zone এখনও দেখা যাবে এবং আপনার সম্পাদনাও সংরক্ষিত হবে। কিন্তু Internet-এর কেউ কখনও ওই zone-কে প্রশ্ন করবে না। record-গুলো বাস্তব। শুধু সেগুলো কখনও ব্যবহার করা হয় না।

বিশ্ব আসলে কোথায় query পাঠাচ্ছে, তা খুঁজে বের করুন:

dig example.com NS +short
dig +trace example.com

প্রথম command-টি বর্তমানে domain-এর জন্য উত্তর দিচ্ছে এমন nameserver-গুলো দেখায়। দ্বিতীয়টি root server থেকে শুরু করে chain অনুসরণ করে এবং TLD server-গুলো যে referral দেয়, তা দেখায়। এই referral-ই registrar নিয়ন্ত্রণ করা delegation। ওই nameserver-গুলোর নাম যদি আপনার পরিচিত কোনো provider-এর না হয়, তাহলে আপনার প্রয়োজনীয় panel সেই provider-ই পরিচালনা করে।

একটি lookup কীভাবে ধাপে ধাপে যায়

এখানে চারটি পক্ষ জড়িত। প্রত্যেকটি পক্ষ নিজের শেখা তথ্যের একটি কপি সংরক্ষণ করে।

1. আপনার মেশিনের stub resolver। এটি নিজে কোনো অনুসন্ধান করে না। এটি একটি configured server-কে জিজ্ঞেস করে এবং সেই উত্তরই গ্রহণ করে। Ubuntu-তে, /etc/resolv.conf সাধারণত /run/systemd/resolve/stub-resolv.conf-এর একটি symlink এবং এটি 127.0.0.53-এর নাম নির্দেশ করে; systemd-resolved লোকালভাবে নিজস্ব cache-সহ চলছে।
2. recursive resolver। এটি আপনার ISP (internet service provider) পরিচালিত resolver হতে পারে, 1.1.1.1-এর মতো কোনো public resolver হতে পারে, অথবা আপনার নিজের পরিচালিত resolver হতে পারে। উত্তর খুঁজে বের করার প্রকৃত কাজটি এটি করে।
3. root এবং TLD server। recursive resolver একটি root server-কে জিজ্ঞেস করে। root server আপনার address জানে না, তবে .com server-গুলোর কাছে যাওয়ার নির্দেশনা দেয়। ওই server-গুলো আপনার nameserver-গুলোর কাছে যাওয়ার নির্দেশনা দেয়।
4. authoritative nameserver। এটি অন্য কাউকে জিজ্ঞেস করে না। এটি আপনার zone থেকে উত্তর দেয় এবং উত্তরটিকে authoritative হিসেবে চিহ্নিত করে।

dig +trace example.com এই প্রক্রিয়াটি দেখায়। কারণ এটি সরাসরি root থেকে শুরু করে এবং cache ব্যবহার না করে প্রতিটি referral মুদ্রণ করে। delegation এবং zone-এর তথ্য একে অপরের সঙ্গে সামঞ্জস্যপূর্ণ কি না দেখার এটিই দ্রুততম উপায়।

সার্ভার চালানোর সময় গুরুত্বপূর্ণ DNS record

• A: একটি নামকে IPv4 address-এর সঙ্গে যুক্ত করে। example.com. A 203.0.113.10। এই record আপনার domain-কে VPS-এর দিকে নির্দেশ করে।
• AAAA: একটি নামকে IPv6 address-এর সঙ্গে যুক্ত করে, যেমন 2001:db8::10। আপনার service সত্যিই ওই address-এ listen করলেই এটি publish করুন। IPv6 network-এর client-গুলো প্রথমে AAAA উত্তর ব্যবহার করার চেষ্টা করে। তাই কোনো service সাড়া দেয় না এমন address যোগ করলে প্রতিটি visit-এ বিলম্ব হয়।
• CNAME: একটি নাম থেকে অন্য নামের alias তৈরি করে। www.example.com. CNAME example.com., www-এর visitor-দের সেই নামের দিকে পাঠায় যেটিতে bare domain resolve হয়। apex-এ CNAME রাখা যায় না, অর্থাৎ bare example.com-এ নয়। কারণ apex-এ নিজস্ব SOA (start of authority) এবং NS record থাকতে হয়, আর CNAME একই নামের সঙ্গে অন্য কোনো record ভাগ করতে পারে না। Provider-গুলো ALIAS, ANAME বা CNAME flattening নামে workaround দেয়।
• MX: domain-এর mail কোথায় deliver হবে তা নির্ধারণ করে। এতে একটি hostname এবং একটি preference number থাকে। কম number আগে চেষ্টা করা হয়। MX এমন একটি নামের দিকে নির্দেশ করতেই হবে, যার address record আছে। CNAME-এর দিকে নির্দেশ করা invalid, এবং কিছু sending server এটি reject করবে।
• TXT: verification এবং policy-এর জন্য ব্যবহৃত free text। Mail authentication record (SPF, DKIM, DMARC) এখানে থাকে। wildcard certificate issue করার ACME (automatic certificate management environment) token-ও এখানে থাকে।
• NS: কোন nameserver zone পরিবেশন করে তা নির্ধারণ করে। বিশ্ব কোন nameserver-এ query করবে, সেই সিদ্ধান্ত নেওয়া copy parent zone-এ থাকে এবং আপনার registrar-এর delegation থেকে আসে। আপনার নিজের zone-এর ভেতরের copy থেকে নয়।

Record type-এর চেয়েও দুটি বিষয় বেশি বিভ্রান্তি তৈরি করে। Dot দিয়ে শেষ হওয়া নাম absolute। তাই www.example.com.-এর অর্থ ঠিক সেটিই, এর বেশি কিছু নয়। বেশিরভাগ panel relative name প্রত্যাশা করে এবং আপনার হয়ে domain যোগ করে। তাই name box-এ www.example.com লিখলে www.example.com.example.com তৈরি হয়, যা কোনো client-এর জন্য resolve হয় না। অন্য বিষয়টি হলো @। প্রায় সব panel-এ এর অর্থ apex: কোনো subdomain ছাড়া শুধু domain-এর নাম।

VPS-এর দিকে একটি A record নির্দেশ করুন

প্রথমে Internet-এ আপনার server-এর যে address দেখা যায়, সেটি বের করুন:

curl -4 https://ifconfig.me
ip -brief -4 address show

এরপর আপনার DNS host-এ একটি record তৈরি করুন: type A, name @, value হিসেবে ওই address এবং TTL (time to live) 300 নির্ধারণ করুন। www-এর জন্য দ্বিতীয় একটি record যোগ করুন। এটি একই address-সহ আরেকটি A হতে পারে, অথবা apex-এর দিকে নির্দেশ করা একটি CNAME হতে পারে।

এখন এটি resolve হচ্ছে কি না যাচাই করুন। সম্ভব হলে server থেকে নয়, আপনার laptop থেকে পরীক্ষা করুন:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

প্রথম command-টি cache-সহ আপনার machine-এর স্বাভাবিক path ব্যবহার করে। দ্বিতীয় command-টি আপনার local cache এড়িয়ে একটি public recursive resolver-কে জিজ্ঞাসা করে। তৃতীয় command-টি সরাসরি আপনার authoritative nameserver-কে জিজ্ঞাসা করে। তাই path-এর কোথাও cache ছাড়া এটি বর্তমান সঠিক উত্তর দেয়। তৃতীয় command-টি আপনার address ফেরত দিলেও প্রথমটি না দিলে DNS সঠিকভাবে configured আছে। সে ক্ষেত্রে cached পুরোনো উত্তরের মেয়াদ শেষ হওয়ার অপেক্ষা চলছে।

রেজলভ হচ্ছে, কিন্তু লোড হচ্ছে না

নাম রেজলভ হওয়া প্রমাণ করে যে DNS কাজ করছে। এটি আপনার web server সম্পর্কে কিছুই প্রমাণ করে না। dig সঠিক address ফেরত দিলে connection পরীক্ষা করুন:

curl -I http://example.com

curl: (6) Could not resolve host: example.com একটি DNS সমস্যা। curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused DNS সমস্যা নয়: নামটি রেজলভ হয়েছে এবং packet পৌঁছেছে, তাই সমস্যা হলো ওই port-এ কোনো কিছু listening অবস্থায় ছিল না। কোনো request অপেক্ষা করতে করতে পরে timeout হলে সাধারণত বোঝায়, firewall packet-টি নীরবে drop করেছে; connection প্রত্যাখ্যান করেনি। এখানেই DNS আর আলোচনার বিষয় থাকে না, এবং ports ও listening sockets ও আপনার VPS-এর ufw firewall rules কার্যকর হয়। connection সম্পন্ন হওয়ার পরে page load-এর বাকি অংশ HTTP-এর কাজ।

ব্রাউজারে এখনও পুরোনো host কেন দেখা যাচ্ছে

কোনো তথ্য স্বয়ংক্রিয়ভাবে ছড়িয়ে পড়ে না। আপনার পরিবর্তন কোনো server অন্যদের কাছে পাঠায় না। আপনি পরিবর্তন সংরক্ষণ করার সঙ্গে সঙ্গেই authoritative nameserver নতুন মান ধরে রাখে। তবে আগের উত্তরের প্রতিটি cached copy তার নিজস্ব timer শেষ না হওয়া পর্যন্ত বৈধ থাকে। এই timer-ই TTL, যা record বিতরণের সময় seconds-এ নির্ধারিত থাকে।

প্রত্যাশার চেয়ে বেশি জায়গায় এই copy থাকে: browser-এর নিজস্ব short cache, machine-এর stub resolver, সেই network ব্যবহৃত recursive resolver এবং client-এ VPN ইনস্টল করা কোনো resolver। প্রত্যেকটি resolver প্রাপ্ত TTL পর্যন্ত তার copy ধরে রাখে। দুটি network-এর দুইজন ব্যবহারকারী ঘণ্টার পর ঘণ্টা দুটি ভিন্ন উত্তর দেখতে পারেন। উভয় machine-ই তখন সঠিকভাবে কাজ করছে।

একটি caching resolver-এর TTL countdown দেখুন:

dig @1.1.1.1 example.com +noall +answer

কয়েক seconds ব্যবধানে এটি দুইবার চালান। উত্তরের TTL কমে যাবে। TTL শূন্যে পৌঁছালে resolver record বাতিল করে আপনার nameserver-কে আবার জিজ্ঞাসা করবে।

আরেকটি cache আছে, যা প্রায় কেউ হিসাবের মধ্যে রাখে না: negative answer। কোনো resolver-কে বলা হলে যে একটি name নেই, সেটিও NXDOMAIN হিসেবে cache করা হয়। আপনার zone-এর SOA record-এর শেষ field-এ নির্ধারিত সময় পর্যন্ত এটি cache থাকে।

dig example.com SOA +short

সেই line-এর শেষ number-টি negative TTL; এটি প্রায়ই 3600 হয়। তাই staging.example.com তৈরি করার আগে সেটি lookup করলে, তৈরি করার পরও পুরো এক ঘণ্টা record-টি আপনার কাছ থেকে আড়াল থাকতে পারে। আগে record তৈরি করুন, তারপর query করুন।

nameserver পরিবর্তন করা record পরিবর্তনের চেয়ে ধীর। এর কারণ সরাসরি প্রযুক্তিগত। .com zone-এর delegation record-গুলো 172800 seconds TTL-সহ পরিবেশিত হয়, যা দুই দিন। তাই কোনো resolver আপনার পুরোনো nameserver cache করে রাখলে, সেটি ওই সময় পর্যন্ত পুরোনো nameserver-কে query করতে পারে। "allow up to 48 hours" পরামর্শটির কারণ এটাই। এটি nameserver পরিবর্তনের ক্ষেত্রে প্রযোজ্য, সাধারণ record edit-এর ক্ষেত্রে নয়।

TTL-এর ভিত্তিতে migration পরিকল্পনা করুন:

1. Record-এর TTL 300-এ কমিয়ে সংরক্ষণ করুন।
2. পুরোনো TTL-এর চেয়ে বেশি সময় অপেক্ষা করুন, যাতে পুরোনো মান বহনকারী সব cached copy-এর মেয়াদ শেষ হয়।
3. Address পরিবর্তন করুন।
4. Traffic নতুন address-এ চলে গেলে TTL আবার 3600 বা তার বেশি করুন। Low TTL থাকলে প্রতিটি resolver আপনার nameserver-কে অনেক বেশি বার query করে।

আপনার নিজের machine-এ থাকা cache পরিষ্কার করতে:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics hit এবং miss counter-সহ একটি cache section দেখায়। তাই flush করার পরের lookup-টি miss হিসেবে দেখা যাবে। Browser আলাদা cache রাখে। ফলে system cache খালি করার পরও Chrome পুরোনো উত্তর ব্যবহার করতে পারে। chrome://net-internals/#dns-এ সেই cache-ও পরিষ্কার করুন। /etc/hosts-ও পরীক্ষা করুন। কারণ সেখানে থাকা কোনো পুরোনো line ওই machine-এ DNS-এর পরিবর্তে কার্যকর হবে, অন্য machine-এ নয়। getent hosts example.com system বাস্তবে যে উত্তর ব্যবহার করবে তা দেখায়, /etc/hosts-সহ।

Wildcard certificate TXT record দিয়ে প্রমাণিত হয়

কোনো CA (certificate authority) certificate issue করার আগে একটি name-এর ওপর আপনার নিয়ন্ত্রণ যাচাই করে। HTTP-01 challenge নির্দিষ্ট hostname-এর port 80-এ একটি file সরবরাহ করে। একটি name-এর জন্য এটি ভালোভাবে কাজ করে। একটি wildcard certificate *.example.com কভার করে। এটি এমন hostnames-এর একটি উন্মুক্ত সেট, যেখান থেকে CA কোনো file fetch করতে পারে না। তাই Let's Encrypt শুধু DNS-01 challenge-এর মাধ্যমে wildcard certificate issue করে। আপনি _acme-challenge.example.com-এ একটি TXT record publish করেন। এতে CA-প্রদত্ত token থাকে। Zone-এর ওপর নিয়ন্ত্রণই এখানে প্রমাণ।

এর ফলে certificate renewal-এর অংশ হয়ে যায় আপনার DNS host। প্রতিটি renewal-এর সময় Certbot-কে আপনার পক্ষ থেকে ওই TXT record তৈরি ও মুছে ফেলতে হয়। তাই provider-এর জন্য একটি API এবং তার সঙ্গে সামঞ্জস্যপূর্ণ plugin প্রয়োজন। Validation ব্যর্থ হলে সাধারণত DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com বার্তা দেখা যায়। এর অর্থ, record visible হওয়ার আগে CA সেটি query করেছে। Record হয় সংরক্ষিত হয়নি, অথবা negative answer এখনও cache-এ ছিল। সম্পূর্ণ প্রক্রিয়াটি DNS-01 challenge ব্যবহার করে wildcard certificate-এর নির্দেশিকায় রয়েছে।

VPN আপনার resolver নিয়ন্ত্রণ করলে

একটি VPN (virtual private network) client সংযুক্ত থাকা অবস্থায় সাধারণত system resolver প্রতিস্থাপন করে। কারণ local network-এ lookup পাঠালে আপনি যে প্রতিটি site-এ যান, সেই network site-এর নাম জানতে পারে। এটি সঠিক আচরণ। তবে দুই ধরনের সমস্যা হতে পারে।

Tunnel চালু হওয়ার পর যদি address কাজ করে কিন্তু name resolve বন্ধ হয়ে যায়, তাহলে client যে resolver ইনস্টল করেছে সেটি tunnel-এর ভেতর থেকে reachable নয়। ping 1.1.1.1 সফল হয় এবং curl https://example.com curl: (6) Could not resolve host: example.com ফেরত দেয়। অন্যদিকে, tunnel চালু হওয়ার পরও যদি lookup আপনার বর্তমান network-এ যেতে থাকে, তাহলে আপনার traffic tunnel-এর মধ্য দিয়ে যাচ্ছে, কিন্তু local resolver আপনার প্রতিটি চাওয়া name দেখতে পাচ্ছে।

resolvectl status

এটি প্রতিটি link-এর জন্য ব্যবহৃত resolver দেখায়। ফলে tunnel কোন resolver ইনস্টল করেছে এবং সেটিই আপনার প্রত্যাশিত resolver কি না, তা যাচাই করতে পারবেন। WireGuard tunnel client config-এর DNS = line থেকে এই মান নির্ধারণ করে। WireGuard resolver নিয়ন্ত্রণ করলে DNS ঠিক করা-এ systemd-resolved এবং resolvconf-এর ক্ষেত্রে বিস্তারিত নির্দেশনা রয়েছে।

উত্তরের কোড এবং প্রতিটি কোডের অর্থ

• NXDOMAIN: একটি authoritative server জানায় যে নামটি বিদ্যমান নয়। বানান পরীক্ষা করুন, domain suffix দুবার লেখা হয়েছে কি না পরীক্ষা করুন, এবং delegation যে zone-এ নির্দেশ করে সেটি সম্পাদনা করেছেন কি না যাচাই করুন।
• NOERROR-এর সঙ্গে খালি ANSWER SECTION: নামটি বিদ্যমান, কিন্তু আপনি যে ধরনের record চেয়েছেন সেই ধরনের কোনো record নেই। শুধু A থাকা অবস্থায় AAAA-এর জন্য query করলে ঠিক এই ফল পাওয়া যায়।
• SERVFAIL: resolver চেষ্টা করেও কোনো উত্তর তৈরি করতে পারেনি। সাধারণত এর দুটি কারণ থাকে: authoritative server কোনো উত্তর দেয় না, অথবা DNSSEC (domain name system security extensions) validation ব্যর্থ হয়। validation নিষ্ক্রিয় করে dig @1.1.1.1 example.com A +cd দিয়ে পরীক্ষা করুন। এটি ছাড়া +cd এবং SERVFAIL-সহ উত্তর পাওয়া গেলে বোঝা যায় যে সমস্যাটি signature-এ। nameserver পরিবর্তনের পরে parent এখনও পুরোনো DS (delegation signer) record প্রকাশ করলে এমনটি ঘটে।
• REFUSED: আপনি যে server-কে জিজ্ঞাসা করেছেন, সেটি সাধারণত ওই প্রশ্নের উত্তর দেবে না। এর কারণ হতে পারে, আপনি dig-কে এমন একটি domain-এর authoritative server-এ নির্দেশ করেছেন, যে domain serverটি serve করে না।
• ;; connection timed out; no servers could be reached: dig কোনো resolver-এ পৌঁছাতে পারেনি। এটি আপনার দিকের network বা resolver সমস্যা; তাই domain-টি সমস্যার বিষয় নয়।

dig-এর পরিবর্তে glibc যে একই শ্রেণির ব্যর্থতা report করে, সেটি হলো ping: example.com: Temporary failure in name resolution।

নিজের VPS-এ nameserver চালানো উচিত কি?

আপনি তা করতে পারেন। bind9, knot অথবা nsd সার্ভার থেকে আপনার zone serve করবে, এবং যেকোনো panel-এর তুলনায় এটি আপনাকে DNS সম্পর্কে বেশি শেখাবে। আপত্তিগুলো মূলত ব্যবহারিক। একটি domain-এর অন্তত দুটি nameserver আলাদা network-এ থাকা উচিত। তাই একটি VPS ওই domain-এর প্রতিটি service-এর জন্য, mail-সহ, একটি single point of failure হয়ে যায়। যে domain serve করে, সেই domain-এর ভেতর নাম দেওয়া nameserver-এর জন্য registrar-এ glue record প্রয়োজন। এটি parent zone-এ সংরক্ষিত ns1.example.com-এর address, কারণ এটি না থাকলে lookup শুরু করার কোনো উপায় থাকে না। কোনো resolver আপনার nameserver-এ পৌঁছাতে না পারলে সেটি আপনার website-এ fallback করে না। সেই user-এর কাছে পুরো domain-ই অদৃশ্য হয়ে যায়। অধিকাংশ মানুষের জন্য API-সহ hosted DNS কম ঝুঁকিপূর্ণ পছন্দ। নিজের machine-গুলোর জন্য VPS-এ caching resolver চালানো আলাদা কাজ এবং এর দায়বদ্ধতাও অনেক কম।

FAQ

আমার DNS পরিবর্তন এখনও propagate হয়নি কেন?

কিছুই propagate হয় না। আপনি নতুন value save করার সঙ্গে সঙ্গেই আপনার authoritative nameserver-গুলো সেটি ধরে রাখে। যে resolver-গুলো আগে থেকেই তথ্যটি জিজ্ঞাসা করেছে, তারা প্রাপ্ত TTL শেষ না হওয়া পর্যন্ত cached copy ব্যবহার করে। dig @ns1.your-dns-host.net example.com A +short দিয়ে সরাসরি authoritative server-কে জিজ্ঞাসা করুন। সেটি নতুন address ফেরত দিলে পরিবর্তনটি কার্যকর হয়েছে; বাকি সমস্যা শুধু caching-সংক্রান্ত। আপনি record পরিবর্তনের বদলে nameserver পরিবর্তন করে থাকলে, অনেক বেশি সময় লাগতে পারে। কারণ TLD delegation দুই দিনের TTL সহ বিতরণ করা হয়।

আমার domain আসলে কোন nameserver ব্যবহার করছে তা কীভাবে জানব?

dig example.com NS +short বর্তমানে domain-এর জন্য উত্তর দেওয়া nameserver-গুলো দেখায়। dig +trace example.com root থেকে referral chain দেখায়, যার মধ্যে TLD server-গুলো যে delegation প্রদান করে সেটিও থাকে। ওই nameserver-গুলোর নাম যদি সেই provider-এর না হয় যার panel-এ আপনি record edit করেছেন, তাহলে সমস্যাটি সেখানেই। delegation-এ উল্লেখ করা provider-এর কাছে record edit করুন, অথবা registrar-এ delegation পরিবর্তন করে আপনার পছন্দের provider-এ নির্দেশ করুন।

আমার domain resolve হচ্ছে, কিন্তু site এখনও load হচ্ছে না। এখন কী করব?

dig example.com A +short আপনার server-এর address ফেরত দিলেই DNS-এর কাজ শেষ। এরপর সমস্যাটি connection-এ। curl -I http://example.com যদি Connection refused ফেরত দেয়, তার অর্থ ওই port-এ কোনো service listening করছে না। কোনো request timeout হওয়া পর্যন্ত অপেক্ষা করলে বুঝবেন firewall packet-টি drop করেছে। আপনার web server চলছে এবং public address-এ bind করা আছে কি না পরীক্ষা করুন। এরপর server-এর firewall এবং provider-এর control panel-এর আলাদা network firewall পরীক্ষা করুন।

আমার root domain-এ CNAME দিতে পারি না কেন?

CNAME জানায় যে একটি name অন্য একটি name-এর alias। যে name-এর CNAME আছে, সেটিতে অন্য কোনো record রাখা যায় না। Zone হিসেবে থাকতে আপনার root domain-এ SOA এবং NS record থাকতে হয়। তাই root domain একই সঙ্গে CNAME হতে পারে না। Root domain-এ address রাখার জন্য একটি A record ব্যবহার করুন। অথবা provider-এর ALIAS, ANAME বা CNAME flattening নামে দেওয়া feature ব্যবহার করুন। এই feature একটি name সংরক্ষণ করে এবং সেই name বর্তমানে যে address-এ resolve হয়, query-এর উত্তরে সেই address দেয়।