DNS Resolution، شروع سے انجام تک

جب بھی آپ براؤزر میں کوئی ڈومین ٹائپ کرتے ہیں، آپ جس سائٹ تک پہنچنا چاہتے ہیں اس تک ایک بھی پیکٹ پہنچنے سے پہلے تلاشوں کی ایک زنجیر شروع ہو جاتی ہے۔ یہ زنجیر زیادہ تر نظروں سے اوجھل ہوتی ہے، اور اس کی زیادہ تر وضاحتیں "یہ فون بک جیسا ہے" پر رک جاتی ہیں۔ یہاں اصل میں کیا ہوتا ہے، قدم بہ قدم، ان حصوں سمیت جو لوگ عام طور پر چھوڑ دیتے ہیں۔

Stub resolver ذہین نہیں ہے

آپ کا آپریٹنگ سسٹم اپنے آپ سے حقیقی DNS resolution نہیں کرتا۔ یہ ایک stub resolver چلاتا ہے، کوڈ کا ایک سادہ ٹکڑا جو صرف آپ کی تلاش کو جو بھی DNS سرور /etc/resolv.conf میں Linux پر یا Windows پر آپ کے نیٹ ورک ایڈاپٹر کی ترتیبات میں منظم ہے وہاں بھیجتا ہے۔ یہ کمانڈ کے ذریعے اپنی جانچ کریں:

cat /etc/resolv.conf

یہ فائل عام طور پر آپ کے روٹر (جیسے 192.168.1.1)، آپ کے ISP کے resolver، یا کسی بہترین جیسے 1.1.1.1 یا 8.8.8.8 کی طرف اشارہ کرتا ہے۔ Stub resolver کے پاس اپنی کوئی cache logic نہیں ہے اس سے آگے جو OS یا ایک local daemon جیسے systemd-resolved فراہم کرتا ہے۔

Recursive resolver اصل کام کرتا ہے

ایک بار آپ کی تلاش recursive resolver تک پہنچنے کے بعد، وہ سرور جواب تلاش کرنے کا کام سنبھال لیتا ہے، یہاں تک کہ اگر اسے کہیں اور سے جواب حاصل کرنے کے لیے متعدد دوسرے سرورز سے پوچھنا پڑے۔ اگر جواب پہلے سے کسی پچھلی تلاش سے cache میں ہے، تو آپ کو فوری طور پر یہ واپس مل جاتا ہے۔ TTL کو یہ کمانڈ کے ذریعے دیکھیں:

dig example.com

ANSWER SECTION کو دیکھیں — record type سے پہلے نمبر (جیسے A سے پہلے 300) ثانیوں میں TTL ہے۔ یہ ہے کہ resolvers کو record کو دوبارہ پوچھنے سے پہلے کتنے عرصے تک cache میں رکھنے کی اجازت ہے۔

اگر کچھ بھی cache میں نہیں ہے، تو recursive resolver DNS hierarchy کے root سے نیچے کی سمت ایک چلنا شروع کرتا ہے۔

Root، TLD، اور authoritative سرورز

13 root سرور کے پتے ہیں (a.root-servers.net سے m.root-servers.net تک)، ہر ایک anycast routing کے ذریعے متعدد فزیکل مشینوں کی حمایت کے ساتھ۔ Root سرور نہیں جانتا کہ example.com کہاں رہتا ہے، لیکن یہ جانتا ہے کہ کون سے سرور .com کو سنبھالتے ہیں، تو یہ ایک referral واپس بھیجتا ہے۔

Resolver پھر .com TLD سرور سے پوچھتا ہے، جو دوبارہ حتمی جواب نہیں جانتا لیکن جانتا ہے کہ کون سے nameservers example.com کے لیے authoritative ہیں۔ آپ یہ delegation خود دیکھ سکتے ہیں:

dig +trace example.com

یہ کمانڈ ہر چھلانگ دکھاتی ہے: root، پھر TLD، پھر domain کے لیے authoritative nameservers، آخر میں اصل A یا AAAA record تک۔ یہ DNS کو نظریاتی طور پر بجائے عملی طور پر سمجھنے کے لیے واحد بہترین کمانڈ ہے۔

Authoritative nameserver آخری منزل ہے۔ یہ سرور ہے جو domain کے مالک نے اصل میں منظم کیا تھا، اکثر registrar کے DNS panel کے ذریعے یا Route 53 یا Cloudflare DNS جیسی سروس کے ذریعے۔ یہ واحد سرور ہے پوری زنجیر میں جس کے پاس حقیقی، canonical جواب ہے بجائے cache شدہ کاپی یا referral کے۔

Record types جن کا آپ سامنا کریں گے

ایک A record ایک نام کو IPv4 پتہ سے map کرتا ہے، AAAA IPv6 کے لیے یہی کام کرتا ہے۔ CNAME ایک نام کو دوسرے نام سے منسلک کرتا ہے بجائے IP کے، جو ہے کہ کیسے CDNs جیسے Cloudflare یا Fastly ٹریفک روٹ کرتے ہیں بغیر خام IPs کو ظاہر کیے۔ MX records میل routing کو سنبھالتے ہیں، اور TXT records من مانی ٹیکسٹ رکھتے ہیں، اب زیادہ تر SPF، DKIM، اور domain verification strings کے لیے استعمال ہوتے ہیں۔ NS records دنیا کو بتاتے ہیں کون سے سرور ایک zone کے لیے authoritative ہیں، اور یہ record type ہے جو delegation کو پہلے جگہ ممکن بناتا ہے۔

Caching اصل میں کہاں رہتی ہے

Caching بیک وقت متعدد سطحوں پر ہوتی ہے: براؤزر خود (Chrome کے پاس اپنی DNS cache ہے دیکھنے کے قابل chrome://net-internals/#dns پر)، OS resolver cache، local router، اور upstream recursive resolver۔ یہ ہے کہ DNS تبدیلی ایک device پر فوری طور پر کام کرتی ہے اور دوسری پر گھنٹوں لگتے ہیں — آپ ایک جیسی cache سے نہیں ٹکرا رہے۔

جب آپ planned migration سے پہلے record کی TTL کو کم کرتے ہیں، تو آپ فوری طور پر کچھ بھی تیز نہیں کر رہے۔ آپ صرف اس window کو سکڑ رہے ہیں جس میں stale ڈیٹا موجود رہ سکتا ہے ایک بار تبدیلی اصل میں ہو جانے کے بعد۔ یہ کم از کم ایک TTL cycle میں کریں، cutover سے پانچ منٹ پہلے نہیں۔

troubleshooting کے لیے یہ کیوں اہم ہے

جب کوئی سائٹ رسائی سے باہر ہو، dig +trace آپ کو بالکل بتاتا ہے کون سی سطح broken ہے: ایک root/TLD مسئلہ بالکل مختلف لگتا ہے ایک غلط منظم authoritative server یا آپ کی اپنی machine پر stale cache سے۔ dig example.com کو ایک معلوم بہترین resolver جیسے dig example.com @1.1.1.1 کے خلاف موازنہ کرنا الگ کرتا ہے کہ مسئلہ آپ کے local resolver میں ہے یا domain کے اصل DNS setup میں۔

DNS سادہ لگتا ہے باہر سے کیونکہ یہ عام طور پر 100ms سے کم میں resolve ہو جاتا ہے اور کوئی اس کے بارے میں سوچتا نہیں۔ نیچے، یہ ایک distributed، cached، hierarchical query system ہے جو 1980s سے بڑی حد تک بغیر تبدیلی کے structure میں چل رہا ہے، جو original design کے کتنی اچھی طریقے سے قائم رہی ہے اس کے لیے بہت اچھی دلیل ہے۔

اگر آپ اس کے ساتھ مزید آگے بڑھنا چاہتے ہیں، تو Korra Studio کے پاس DEFENSE_GRID پر متعلقہ segments ہیں DNS security extensions، DNS tunneling exfiltration technique کے طور پر، اور Python میں اپنا resolver بنانے پر۔