DNS (Domain Name System) انٹرنیٹ کی فون بک ہے: یہ example.com جیسے انسان کے پڑھنے کے قابل نام کو 93.184.216.34 جیسے IP address میں ترجمہ کرتا ہے۔ Resolution ایک درجہ بندی والا lookup ہے، جو عموماً آپ کے لیے ایک recursive resolver (آپ کے ISP کا یا 8.8.8.8 جیسا کوئی عوامی) انجام دیتا ہے، جو آپ کی جانب سے authoritative name servers کے درخت میں چلتا ہے:
Browser ──▶ Recursive Resolver ──▶ Root (.) "ask .com's servers"
│ ◀──
├────────▶ TLD (.com) "ask example.com's servers"
│ ◀──
└────────▶ Authoritative "example.com = 93.184.216.34"
(example.com) ◀──
Browser ◀── 93.184.216.34
Resolver پہلے root servers سے پوچھتا ہے (جو TLD servers جانتے ہیں)، پھر .com کے لیے TLD servers سے (جو جانتے ہیں کہ example.com کے لیے کون authoritative ہے)، پھر authoritative server سے (جو اصل record رکھتا ہے)۔ ہر بار اس کو دہرانے سے بچنے کے لیے، نتائج کو ہر سطح پر cache کیا جاتا ہے — براؤزر، OS، اور resolver — اور ہر ایک record کے TTL (time-to-live) کا احترام کرتا ہے۔ ایک گرم cache مائیکرو سیکنڈوں میں resolve کرتا ہے؛ ایک ٹھنڈے lookup پر کئی round trips لگ سکتے ہیں۔
عام record types: A (name → IPv4)، AAAA (name → IPv6)، CNAME (کسی اور نام کا عرف)، MX (mail servers)، TXT (کوئی بھی متن، SPF/تصدیق کے لیے استعمال ہوتا ہے)، اور NS (کسی zone کو تفویض کرتا ہے)۔ آپ resolution کو براہِ راست دیکھ سکتے ہیں:
dig example.com A # A record اور یہ دکھاتا ہے کہ کس server نے جواب دیا
DNS ہر اُس request کے تنقیدی راستے پر بیٹھتا ہے جو کسی نام سے شروع ہوتی ہے، اس لیے ایک سست یا غلط کنفیگر شدہ resolver ہر چیز میں latency کا اضافہ کر دیتا ہے۔ انٹرویو لینے والوں کو یہ سوال پسند ہے کیونکہ یہ ظاہر کرتا ہے کہ آیا آپ درجہ بندی اور caching کو سمجھتے ہیں — وہ دو خیالات جو ایک عالمی، تقسیم شدہ نظام کو اربوں queries کا تیزی سے جواب دینے دیتے ہیں۔ یہ حقیقی production واقعات کا بھی ایک عام سبب ہے ("مسئلہ ہمیشہ DNS ہوتا ہے"): میعاد ختم شدہ records، غلط TTLs، یا کسی تبدیلی کے بعد propagation میں تاخیر — چنانچہ caching اور TTL کے کام کرنے کا طریقہ جاننا براہِ راست عملی ہے۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں