DNS کیا ہے؟ VPS تک domain نہ پہنچنے کی وجہ

DNS کیا ہے، اور آپ کا domain ابھی تک اپنے VPS تک کیوں نہیں پہنچ رہا

DNS (domain name system) example.com جیسے نام کو 203.0.113.10 جیسے IP (internet protocol) address میں تبدیل کرتا ہے۔ browser کسی نام سے connect نہیں کر سکتا۔ وہ address سے connect کرتا ہے، اس لیے ہر page load کا آغاز DNS سوال اور جواب سے ہوتا ہے۔ اگر آپ نے ابھی domain خریدا ہے اور اپنا VPS حاصل کیا ہے، لیکن کچھ load نہیں ہو رہا، تو دو میں سے ایک بات درست ہے: ابھی تک کوئی record نام کو آپ کے server کے address سے connect نہیں کرتا، یا record موجود ہے لیکن راستے میں کوئی چیز اب بھی پرانا جواب فراہم کر رہی ہے۔

دونوں صورتیں معمول کی ہیں، اور ان میں سے کسی کا مطلب یہ نہیں کہ کچھ خراب ہے۔ ذیل کے sections ان حصوں کو اسی ترتیب سے بیان کرتے ہیں جس ترتیب سے آپ ان کا سامنا کریں گے۔ آغاز اس مرحلے سے ہوتا ہے جو سب سے زیادہ وقت ضائع کرتا ہے: آپ کے records اصل میں کس control panel میں موجود ہیں۔

یہاں ہر check میں dig استعمال ہوتا ہے، جو نئی Ubuntu یا Debian machine پر default طور پر installed نہیں ہوتا۔

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

Registrar، nameservers، DNS host: کس میں ترمیم کرنی ہے

یہ تین نام مختلف کاموں کو ظاہر کرتے ہیں۔ ان میں فرق نہ کرنا اس بات کی سب سے عام وجہ ہے کہ ترمیم کے بعد کوئی تبدیلی نظر نہیں آتی۔

• registrar وہ کمپنی ہے جس سے آپ نے domain خریدا ہے۔ اس کا اہم کام delegation ہے: یہ آپ کے TLD (top-level domain، یعنی .com حصے) کو چلانے والی registry کو بتاتا ہے کہ آپ کے domain کے لیے کون سے nameservers authoritative ہیں۔
• authoritative nameservers آپ کے zone کے اصل records رکھتے ہیں۔ zone سے مراد آپ کا domain اور اس کے تحت آنے والے نام ہیں۔
• DNS host وہ فریق ہے جو ان nameservers کو چلاتا ہے۔ یہ registrar خود، کوئی الگ provider، یا bind9 ہو سکتا ہے جو آپ کے اپنے server پر چل رہا ہو۔

خریداری registrar سے کریں۔ ترمیم DNS host پر کریں۔ اگر آپ نے اپنے domain کو کسی دوسرے provider کے nameservers پر منتقل کر دیا ہے تو registrar کا اپنا DNS panel اب بھی آپ کو ایک zone دکھائے گا، آپ کی ترمیم محفوظ بھی کرے گا، لیکن internet پر کوئی بھی اس zone سے معلومات حاصل نہیں کرے گا۔ records حقیقی ہیں۔ بس ان سے کبھی رجوع نہیں کیا جاتا۔

معلوم کریں کہ دنیا کس جگہ سے معلومات حاصل کر رہی ہے:

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

پہلی command اس وقت domain کے لیے جواب دینے والے nameservers دکھاتی ہے۔ دوسری command root servers سے شروع کر کے chain کی پیروی کرتی ہے اور وہ referral دکھاتی ہے جو TLD servers فراہم کرتے ہیں۔ یہی delegation ہے جسے آپ کا registrar control کرتا ہے۔ اگر ان ناموں کا تعلق کسی ایسے provider سے ہے جسے آپ نہیں پہچانتے تو مطلوبہ panel اسی provider کا ہے۔

ایک lookup کیسے سفر کرتا ہے

اس عمل میں چار فریق شامل ہوتے ہیں، اور ہر فریق سیکھی ہوئی معلومات کی ایک نقل رکھتا ہے۔

1. آپ کی مشین پر موجود stub resolver۔ یہ خود تلاش نہیں کرتا۔ یہ ایک configured server سے سوال کرتا ہے اور جواب پر اعتماد کرتا ہے۔ Ubuntu پر /etc/resolv.conf عموماً /run/systemd/resolve/stub-resolv.conf کی symbolic link ہوتا ہے اور 127.0.0.53 کو نامزد کرتا ہے، جو locally چلنے والا systemd-resolved ہے اور اپنا cache رکھتا ہے۔
2. recursive resolver۔ یہ آپ کے ISP (internet service provider) کا چلایا ہوا resolver ہوتا ہے، یا 1.1.1.1 جیسا public resolver، یا وہ resolver جسے آپ خود چلاتے ہیں۔ جواب تلاش کرنے کا اصل کام یہی کرتا ہے۔
3. root اور TLD servers۔ recursive resolver کسی root server سے سوال کرتا ہے۔ root server آپ کا address نہیں جانتا، لیکن .com servers کی طرف referral واپس کرتا ہے۔ یہ servers آپ کے nameservers کی طرف referral دیتے ہیں۔
4. authoritative nameserver۔ یہ کسی سے سوال نہیں کرتا۔ یہ آپ کے zone سے جواب دیتا ہے اور جواب کو authoritative قرار دیتا ہے۔

dig +trace example.com اس عمل کو دکھاتا ہے، کیونکہ یہ خود root سے شروع ہوتا ہے اور cache سے سوال کرنے کے بجائے ہر referral print کرتا ہے۔ delegation اور zone کے باہم مطابقت رکھنے کی جانچ کا یہ تیز ترین طریقہ ہے۔

سرور چلاتے وقت اہم DNS records

• A: کسی نام کو IPv4 address سے جوڑتا ہے۔ example.com. A 203.0.113.10۔ یہی وہ record ہے جو آپ کے domain کو آپ کے VPS کی طرف point کرتا ہے۔
• AAAA: کسی نام کو IPv6 address سے جوڑتا ہے، جیسے 2001:db8::10۔ اسے صرف اسی وقت publish کریں جب آپ کی service واقعی اس address پر listen کرتی ہو۔ IPv6 network پر موجود clients پہلے AAAA answer آزماتے ہیں، اس لیے ایسے address پر، جہاں کوئی service جواب نہیں دیتی، ہر visit میں تاخیر پیدا ہوتی ہے۔
• CNAME: ایک نام کو دوسرے نام کا alias بناتا ہے۔ www.example.com. CNAME example.com.، www کے visitors کو اس مقام پر بھیجتا ہے جہاں bare domain resolve ہوتا ہے۔ CNAME apex (bare example.com) پر نہیں ہو سکتا، کیونکہ apex میں اپنے SOA (start of authority) اور NS records ہونے چاہییں، جبکہ CNAME ایک ہی نام پر کسی دوسرے record کے ساتھ موجود نہیں ہو سکتا۔ Providers اس مسئلے کے حل کے لیے ALIAS، ANAME یا CNAME flattening جیسے نام استعمال کرتے ہیں۔
• MX: بتاتا ہے کہ domain کی mail کہاں deliver کی جائے۔ اس میں hostname اور preference number ہوتا ہے، اور پہلے کم number والے target کو آزمایا جاتا ہے۔ MX کو ایسے نام کی طرف point کرنا چاہیے جس کا address record موجود ہو۔ اسے CNAME کی طرف point کرنا invalid ہے، اور کچھ sending servers اسے reject کر دیں گے۔
• TXT: آزاد متن ہوتا ہے، جو verification اور policy کے لیے استعمال ہوتا ہے۔ Mail authentication records (SPF، DKIM، DMARC) یہاں موجود ہوتے ہیں، اسی طرح ACME (automatic certificate management environment) token بھی، جو wildcard certificate جاری کرتا ہے۔
• NS: بتاتا ہے کہ zone کو کون سے nameservers serve کرتے ہیں۔ وہ copy جو یہ طے کرتی ہے کہ دنیا کہاں query کرے گی، parent zone میں موجود ہوتی ہے اور آپ کے registrar کی delegation سے آتی ہے، نہ کہ آپ کی اپنی zone کے اندر موجود copy سے۔

دو تفصیلات record types سے بھی زیادہ confusion پیدا کرتی ہیں۔ Dot پر ختم ہونے والا نام absolute ہوتا ہے، اس لیے www.example.com. کا مطلب صرف وہی نام ہے، اس سے زیادہ کچھ نہیں۔ زیادہ تر panels relative name کی توقع کرتے ہیں اور domain خود append کر دیتے ہیں۔ اس لیے name box میں www.example.com لکھنے سے www.example.com.example.com بنتا ہے، جو کسی کے لیے resolve نہیں ہوتا۔ دوسری تفصیل @ ہے، جس کا تقریباً ہر panel میں مطلب apex ہوتا ہے: خود domain، بغیر کسی subdomain کے۔

اپنے VPS کی طرف A record کی نشاندہی کریں

پہلے وہ address معلوم کریں جو internet آپ کے server کے لیے دیکھتا ہے:

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 آپ کی machine کا معمول کا path استعمال کرتا ہے، جس میں caches بھی شامل ہیں۔ دوسرا command آپ کے local cache کو bypass کرتا ہے اور public recursive resolver سے پوچھتا ہے۔ تیسرا command آپ کے authoritative nameserver سے براہِ راست پوچھتا ہے۔ اس لیے اس کا جواب موجودہ حقیقت ہوتا ہے اور path میں کہیں بھی cache شامل نہیں ہوتا۔ جب تیسرا command آپ کا address واپس دے اور پہلا نہ دے، تو آپ کا DNS درست configure ہے اور آپ پرانے جواب کی cached copy ختم ہونے کا انتظار کر رہے ہیں۔

نام حل ہو رہا ہے لیکن صفحہ لوڈ نہیں ہو رہا

نام کا resolve ہونا ثابت کرتا ہے کہ 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 کا مسئلہ نہیں ہے: نام resolve ہو گیا اور packet پہنچ گیا، اس لیے مسئلہ یہ ہے کہ اس port پر کوئی چیز listening نہیں کر رہی۔ جو request رک جاتی ہے اور پھر timeout ہو جاتی ہے، اس کا عموماً مطلب یہ ہوتا ہے کہ firewall نے packet کو خاموشی سے drop کر دیا، اسے reject نہیں کیا۔ یہاں DNS کا موضوع ختم ہو جاتا ہے، اور ports اور listening sockets کے ساتھ آپ کے VPS کے ufw firewall rules کام میں آتے ہیں۔ Connection مکمل ہونے کے بعد صفحہ load ہونے کا باقی عمل HTTP کے ذریعے جاری رہتا ہے۔

براؤزر اب بھی پرانا host کیوں دکھا رہا ہے

کچھ بھی خودکار طور پر propagate نہیں ہوتا۔ کوئی server آپ کی تبدیلی کو باہر موجود دوسرے clients تک push نہیں کرتا۔ آپ کا authoritative nameserver تبدیلی save کرتے ہی نئی value رکھتا ہے، جبکہ پچھلے جواب کی ہر cached copy اپنے timer کے ختم ہونے تک valid رہتی ہے۔ یہ timer TTL ہے، جو seconds میں ہوتا ہے اور record کے فراہم کیے جانے کے وقت اس کے ساتھ شامل ہوتا ہے۔

Copies توقع سے زیادہ جگہوں پر موجود ہوتی ہیں: browser کی اپنی مختصر cache، machine پر موجود stub resolver، اس network کا استعمال ہونے والا recursive resolver، اور client پر VPN کی جانب سے نصب کیا گیا کوئی resolver۔ ہر copy اسے ملنے والے TTL تک برقرار رہتی ہے۔ دو networks پر موجود دو افراد کئی گھنٹوں تک دو مختلف جوابات دیکھ سکتے ہیں، اور دونوں machines درست طور پر کام کر رہی ہوتی ہیں۔

Caching resolver کے خلاف countdown monitor کریں:

dig @1.1.1.1 example.com +noall +answer

اسے چند seconds کے وقفے سے دو بار چلائیں۔ جواب میں TTL کم ہو جائے گا۔ جب یہ zero تک پہنچتا ہے تو resolver record کو discard کر کے آپ کے nameserver سے دوبارہ پوچھتا ہے۔

ایک دوسری cache بھی ہے جسے تقریباً کوئی account نہیں کرتا: negative answers۔ جب resolver کو بتایا جاتا ہے کہ کوئی name موجود نہیں، تو وہ اس NXDOMAIN کو بھی cache کر لیتا ہے۔ یہ آپ کے zone کے SOA record کے آخری field میں مقررہ مدت تک رہتا ہے۔

dig example.com SOA +short

اس line پر آخری number negative TTL ہے، جو اکثر 3600 ہوتا ہے۔ اس لیے staging.example.com کو create کرنے سے پہلے lookup کرنے پر، record create کرنے کے بعد بھی یہ ایک پورے گھنٹے تک نظر نہیں آ سکتا۔ پہلے record create کریں، پھر اسے query کریں۔

Nameservers تبدیل کرنا record تبدیل کرنے سے زیادہ سست ہوتا ہے، اور اس کی وجہ نظام کا طریقۂ کار ہے۔ .com zone میں delegation records 172800 seconds کے TTL کے ساتھ serve ہوتے ہیں، جو دو days کے برابر ہے۔ اس لیے ایسا resolver جس نے آپ کے پرانے nameservers cache کیے ہوں، اتنی مدت تک انہی سے پوچھتا رہ سکتا ہے۔ "allow up to 48 hours" کا مشورہ اسی وجہ سے دیا جاتا ہے۔ یہ nameserver changes پر لاگو ہوتا ہے، عام record edits پر نہیں۔

Migration کو TTL کے مطابق plan کریں، اس کے خلاف کام نہ کریں:

1. Record کا TTL کم کر کے 300 کریں اور اسے save کریں۔
2. پرانے TTL سے زیادہ وقت انتظار کریں، تاکہ پرانی value رکھنے والی ہر cached copy expire ہو جائے۔
3. Address تبدیل کریں۔
4. Traffic منتقل ہونے کے بعد TTL دوبارہ 3600 یا اس سے زیادہ کر دیں، کیونکہ کم TTL کا مطلب ہے کہ ہر resolver آپ کے nameservers سے کہیں زیادہ بار پوچھے گا۔

اپنی machine پر موجود cache صاف کرنے کے لیے:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics hit اور miss counters کے ساتھ cache section print کرتا ہے، اس لیے flush کے فوراً بعد اگلی lookup miss کے طور پر ظاہر ہوتی ہے۔ Browsers الگ cache رکھتے ہیں، جس کا مطلب ہے کہ system cache خالی ہونے کے بعد بھی Chrome پرانا جواب استعمال کر سکتا ہے۔ اسے chrome://net-internals/#dns پر clear کریں۔ /etc/hosts بھی check کریں، کیونکہ وہاں موجود بچی ہوئی line اس machine پر DNS کو override کرتی ہے، اور صرف اسی machine پر۔ getent hosts example.com وہ جواب دکھاتا ہے جسے system حقیقت میں استعمال کرے گا، /etc/hosts سمیت۔

وائلڈ کارڈ certificates کی تصدیق TXT record سے ہوتی ہے

CA (certificate authority) certificate جاری کرنے سے پہلے نام پر اختیار کی تصدیق کرتا ہے۔ HTTP-01 challenge میں اسی hostname پر port 80 کے ذریعے ایک file فراہم کی جاتی ہے، جو ایک نام کے لیے مؤثر طریقہ ہے۔ وائلڈ کارڈ certificate میں *.example.com شامل ہوتا ہے، یعنی hostnames کا ایک غیر محدود مجموعہ جس سے CA file حاصل نہیں کر سکتا۔ اسی لیے Let's Encrypt وائلڈ کارڈ certificates صرف DNS-01 challenge کے ذریعے جاری کرتا ہے۔ آپ _acme-challenge.example.com پر ایک TXT record شائع کرتے ہیں جس میں CA کی فراہم کردہ token ہوتی ہے، اور zone پر اختیار اسی کا ثبوت ہوتا ہے۔

اس طرح آپ کا DNS host certificate renewal کا حصہ بن جاتا ہے۔ ہر renewal پر Certbot کو آپ کی مداخلت کے بغیر یہ TXT record بنانا اور حذف کرنا ہوتا ہے، اس لیے اسے آپ کے provider کے لیے API اور متعلقہ plugin درکار ہوتا ہے۔ validation ناکام ہونے پر عام پیغام DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com ہوتا ہے۔ اس کا مطلب ہے کہ CA نے record کے visible ہونے سے پہلے درخواست کی: یا تو record کبھی محفوظ نہیں کیا گیا، یا negative answer ابھی cache میں موجود تھا۔ مکمل طریقۂ کار DNS-01 challenge کے ساتھ وائلڈ کارڈ certificates کی رہنمائی میں موجود ہے۔

جب VPN آپ کے resolver کا کنٹرول سنبھال لے

VPN (virtual private network) client کے connected ہونے کے دوران عموماً system resolver کو تبدیل کر دیتا ہے، کیونکہ lookups کو local network پر بھیجنے سے اس network کو آپ کی دیکھی ہوئی ہر site کا نام معلوم ہو جاتا۔ یہ درست رویہ ہے، لیکن اس میں دو طرح کی خرابی ہو سکتی ہے۔

اگر tunnel قائم ہو جائے اور addresses پھر بھی کام کر رہے ہوں، لیکن names resolve ہونا بند ہو جائیں، تو client کا نصب کردہ resolver tunnel کے اندر سے قابل رسائی نہیں ہے۔ ping 1.1.1.1 کامیاب ہوتا ہے اور curl https://example.com، curl: (6) Could not resolve host: example.com واپس کرتا ہے۔ اس کے برعکس، اگر tunnel قائم ہونے کے بعد بھی lookups اسی network کو بھیجے جائیں جس سے آپ connected ہیں، تو آپ کا traffic tunnel کے اندر سے گزر رہا ہے، جبکہ local resolver آپ کی ہر مطلوبہ name دیکھ رہا ہے۔

resolvectl status

یہ ہر link کے لیے زیر استعمال resolver دکھاتا ہے۔ اس سے آپ دیکھ سکتے ہیں کہ tunnel نے کون سا resolver نصب کیا اور آیا وہی resolver استعمال ہو رہا ہے جس کا آپ نے ارادہ کیا تھا۔ WireGuard tunnel میں یہ client config کی DNS = line سے set ہوتا ہے، اور WireGuard کے resolver کا کنٹرول سنبھالنے پر DNS درست کرنا میں systemd-resolved اور resolvconf کے cases کی تفصیلی وضاحت موجود ہے۔

جوابی codes، اور ہر code آپ کو کیا بتاتا ہے

• NXDOMAIN: authoritative server بتاتا ہے کہ یہ نام موجود نہیں ہے۔ spelling چیک کریں، domain suffix کے دہرے اندراج کو چیک کریں، اور تصدیق کریں کہ آپ نے اسی zone میں ترمیم کی ہے جس کی طرف آپ کی delegation اشارہ کرتی ہے۔
• NOERROR اور خالی ANSWER SECTION: نام موجود ہے، لیکن اس میں آپ کی مطلوبہ type کا کوئی record نہیں ہے۔ اگر صرف A موجود ہو اور آپ AAAA کے بارے میں پوچھیں، تو یہی نتیجہ ملتا ہے۔
• SERVFAIL: resolver نے کوشش کی، لیکن جواب تیار نہیں کر سکا۔ اس کی دو عام وجوہات یہ ہیں کہ authoritative servers کبھی جواب نہیں دیتے، یا DNSSEC (domain name system security extensions) validation ناکام ہو رہی ہے۔ dig @1.1.1.1 example.com A +cd کے ذریعے test کریں، جو validation کو disable کرتا ہے۔ اگر اس کے بغیر +cd اور SERVFAIL کے ساتھ جواب ملے، تو مسئلہ signatures میں ہے۔ یہ عموماً nameserver منتقل کرنے کے بعد ہوتا ہے، جب parent اب بھی پرانا DS (delegation signer) record publish کر رہا ہو۔
• REFUSED: جس server سے آپ نے پوچھا ہے وہ اس سوال کا جواب نہیں دے گا۔ عموماً وجہ یہ ہوتی ہے کہ آپ نے dig کو ایسے domain کے authoritative server کی طرف point کیا ہے جسے وہ serve نہیں کرتا۔
• ;; connection timed out; no servers could be reached: dig کسی resolver تک نہیں پہنچ سکا۔ یہ آپ کی طرف network یا resolver کا مسئلہ ہے، اس لیے domain اس مسئلے کا موضوع نہیں ہے۔

ping: example.com: Temporary failure in name resolution اسی نوعیت کی failure ہے، لیکن اسے dig کے بجائے glibc report کرتا ہے۔

اپنے VPS پر nameserver چلانے چاہییں؟

آپ ایسا کر سکتے ہیں۔ bind9، knot یا nsd آپ کے server سے zone فراہم کریں گے، اور اس سے آپ کسی بھی panel کے مقابلے میں DNS کے بارے میں زیادہ سیکھیں گے۔ اعتراضات عملی نوعیت کے ہیں۔ کسی domain کے لیے کم از کم دو nameserver الگ networks پر ہونے چاہییں، اس لیے ایک VPS domain کی ہر service، بشمول mail، کے لیے واحد failure point بن جاتا ہے۔ جس domain کی service nameserver فراہم کر رہے ہوں، اگر nameserver کا نام بھی اسی domain کے اندر ہو تو registrar پر glue records درکار ہوتے ہیں۔ یہ parent zone میں ns1.example.com کا address محفوظ کرتے ہیں، کیونکہ بصورت دیگر lookup شروع کرنے کا کوئی طریقہ نہیں ہوتا۔ جب کوئی resolver آپ کے nameserver تک نہیں پہنچ پاتا تو وہ آپ کی website پر fallback نہیں کرتا؛ اس user کے لیے پورا domain غائب ہو جاتا ہے۔ زیادہ تر لوگوں کے لیے API والی hosted DNS کم خطرے والا انتخاب ہے۔ اپنے machines کے لیے اپنے VPS پر caching resolver چلانا الگ کام ہے، اور اس کے لیے بہت کم انتظامی وابستگی درکار ہوتی ہے۔

FAQ

میری DNS تبدیلی ابھی تک propagate کیوں نہیں ہوئی؟

کچھ بھی propagate نہیں ہوتا۔ آپ کے authoritative nameservers نیا value محفوظ کرتے ہی اسے رکھ لیتے ہیں، جبکہ ہر وہ resolver جس نے پہلے ہی query کی تھی، موصول شدہ TTL ختم ہونے تک اپنی cached copy استعمال کرتا رہتا ہے۔ dig @ns1.your-dns-host.net example.com A +short کے ذریعے authoritative server سے براہ راست پوچھیں۔ اگر اس سے نیا address واپس آتا ہے تو تبدیلی live ہے، اور باقی مسئلہ caching کا ہے۔ اگر آپ نے records کے بجائے nameservers تبدیل کیے ہیں تو اس میں زیادہ وقت لگے گا، کیونکہ TLD delegations دو دن کے TTL کے ساتھ جاری کی جاتی ہیں۔

میں کیسے معلوم کروں کہ میری domain حقیقت میں کون سے nameservers استعمال کرتی ہے؟

dig example.com NS +short اس وقت domain کے لیے جواب دینے والے nameservers دکھاتا ہے، جبکہ dig +trace example.com root سے referral chain دکھاتا ہے، جس میں TLD servers کی دی ہوئی delegation بھی شامل ہوتی ہے۔ اگر یہ names provider کے اس panel سے مطابقت نہیں رکھتے جس میں آپ editing کر رہے ہیں، تو یہی مسئلہ ہے۔ یا تو delegation میں درج provider پر records edit کریں، یا اپنے registrar پر delegation تبدیل کریں تاکہ وہ آپ کے مطلوبہ مقام کی طرف اشارہ کرے۔

میری domain resolve ہو رہی ہے، لیکن site پھر بھی load نہیں ہوتی۔ اب کیا کروں؟

جیسے ہی dig example.com A +short آپ کے server کا address واپس کرتا ہے، DNS کا کام مکمل ہو جاتا ہے۔ اس کے بعد مسئلہ connection کا ہوتا ہے۔ curl -I http://example.com کا Connection refused واپس کرنا اس بات کی علامت ہے کہ اس port پر کوئی چیز listening نہیں کر رہی۔ اگر request timeout ہونے تک معلق رہے تو firewall نے packet drop کیا ہے۔ تصدیق کریں کہ آپ کا web server چل رہا ہے اور public address پر bind ہے۔ پھر server کے firewall اور provider کے control panel میں موجود الگ network firewall، دونوں کو check کریں۔

میں اپنی root domain پر CNAME کیوں نہیں رکھ سکتا؟

CNAME یہ بتاتا ہے کہ ایک name دوسرے name کا alias ہے، اور جس name پر CNAME ہو وہاں کوئی دوسرا record رکھنا allowed نہیں ہوتا۔ آپ کی root domain کے zone کے طور پر موجود رہنے کے لیے SOA اور NS records ضروری ہیں، اس لیے وہ بیک وقت CNAME نہیں ہو سکتی۔ root پر address رکھنے والا A record استعمال کریں، یا provider کی وہ feature استعمال کریں جو ALIAS، ANAME یا CNAME flattening کے نام سے فراہم کی جاتی ہے۔ یہ feature ایک name محفوظ کرتی ہے اور queries کا جواب اس address سے دیتی ہے جس پر وہ name اس وقت resolve ہو رہی ہو۔