MR (Mail Rename) لیگیسی DNS چیکر
MR (Mail Rename) ریکارڈ ابتدائی RFC 1035 کے دنوں کا ایک اور تجرباتی نمونہ ہے، جسے تبدیل شدہ ای میل ایڈریسز کے لیے DNS لیول پر عرفی (alias) میکانزم کے طور پر کام کرنے کے لیے ڈیزائن کیا گیا تھا۔ جب کارپوریٹ نیٹ ورکس پہلی بار آن لائن آئے، تو صارف کا ای میل ایڈریس تبدیل کرنا حیرت انگیز طور پر ایک پیچیدہ روٹنگ مسئلہ تھا۔ MR ریکارڈ کو براہ راست DNS لک اپ کے مرحلے کے اندر ایک مستقل فارورڈنگ لوپ (forwarding loop) بنانے کے لیے متعارف کرایا گیا تھا، تاکہ جب ملازمین محکمے تبدیل کریں یا اپنے صارف نام (usernames) تبدیل کریں تو جائز میل کو باؤنس ہونے سے روکا جا سکے۔
پری کنکشن عرفی ریزولوشن (Pre-Connection Alias Resolution)
اگر کسی ملازم نے اپنا صارف نام jsmith سے john.smith میں تبدیل کر دیا، تو سسٹم ایڈمنسٹریٹر پرانے نوڈ پر نئے میل باکس کی طرف اشارہ کرتے ہوئے ایک MR ریکارڈ شائع کرے گا۔ جب کوئی بیرونی میل سرور پرانی ای میل پر مخاطب کوئی پیغام وصول کرتا، تو وہ DNS کو کیوری کرتا۔ MR ریکارڈ کا سامنا کرنے پر، بھیجنے والے سرور کو ہدایت دی گئی تھی کہ وہ ای میل کے لفافے کے ہیڈرز (envelope headers) کو جسمانی طور پر دوبارہ لکھے (rewrite)، پرانی منزل کو نئی منزل سے بدل دے، اس سے پہلے کہ وہ پے لوڈ پہنچانے کے لیے SMTP کنکشن شروع کرے۔ یہ بالکل اسی طرح کام کرتا تھا جیسے CNAME ریکارڈ ہوسٹ ناموں کے لیے کام کرتا ہے، لیکن یہ خاص طور پر میل باکس کے مقامی حصوں (local-parts) تک محدود تھا۔
روٹنگ میں تاخیر اور آپریشنل اوور ہیڈ
MB اور MG ریکارڈز کی طرح، MR ریکارڈ بھی اپنے آپریٹنگ اوور ہیڈ کے بوجھ تلے دب کر ناکام ہو گیا۔ چونکہ DNS کیوریز کا انحصار متعدد ایج (edge) نیٹ ورکس کو عبور کرنے والے UDP پیکٹس پر ہوتا ہے، اس لیے محض ایک مقامی عرف (alias) کو حل کرنے کے لیے بیرونی DNS لک اپس پر انحصار کرنے سے میل کی قطاروں (mail queues) میں بہت زیادہ تاخیر (latency) کا اضافہ ہوا۔ مزید برآں، اس نے پبلک انٹرنیٹ پر اندرونی کارپوریٹ ڈھانچے کو بے نقاب کر دیا۔ اگر کسی بدنیتی پر مبنی ہیکر نے MR ریکارڈز کی کیوری کی، تو وہ آسانی سے کسی تنظیم کی ملازمین کی مکمل ہسٹری اور محکمے کی تبدیلیوں کا نقشہ بنا سکتے ہیں، جس سے سوشل انجینئرنگ اور فشنگ (phishing) حملوں کے لیے ایک انتہائی مفصل روسٹر (roster) بن سکتا ہے۔
جدید سرور سائیڈ الیاسنگ (Server-Side Aliasing)
صارف کے عرفی ناموں کو DNS لیئر کے سامنے لانا غیر ضروری اور غیر محفوظ سمجھا جاتا تھا۔ میل سرورز کے مزید پیچیدہ ہونے کے ساتھ ہی اس پروٹوکول کو مکمل طور پر متروک (deprecated) کر دیا گیا۔ آج، مقامی Mail Transfer Agent (MTA) کنفیگریشنز کے اندر الیاسنگ (aliasing) کو فوری اور محفوظ طریقے سے سنبھالا جاتا ہے۔ Postfix میں /etc/aliases فائل، Exim میں ورچوئل عرفی نقشے (virtual alias maps)، یا Microsoft Active Directory میں پراکسی ایڈریسز جیسی ٹیکنالوجیز صارف نام کی تبدیلیوں کو ملی سیکنڈز میں اندرونی طور پر ہینڈل کرتی ہیں۔ بیرونی بھیجنے والا سرور آسانی سے MX ریکارڈ سے جڑتا ہے، پے لوڈ چھوڑ دیتا ہے، اور DNS لیئر کو مکمل طور پر نظر انداز کرتے ہوئے وصول کرنے والے سرور کو اندرونی نام تبدیل کرنے کی منطق کو ہینڈل کرنے دیتا ہے۔