Check-Host.cc

گلوبل TXT ریکارڈ لک اپ

1980 کی دہائی میں اصل میں سسٹم ایڈمنسٹریٹرز کے لیے زون فائل کے اندر human-readable نوٹس چھوڑنے کے لیے ایک سادہ سینڈ باکس کے طور پر ڈیزائن کیا گیا، TXT (Text) ریکارڈ جدید نیٹ ورک سیکیورٹی کے سب سے اہم ساختی اجزاء میں سے ایک بن گیا ہے۔ چونکہ DNS پروٹوکول عملی طور پر TXT پے لوڈز (Payloads) پر کوئی سنٹیکس (syntax) کی توثیق لاگو نہیں کرتا، اس لیے ڈویلپرز اور سیکیورٹی پلیٹ فارمز ان ریکارڈز کو مشین سے پڑھے جانے کے قابل ڈیٹا سٹرنگز کو ذخیرہ کرنے کے لیے استعمال کرتے ہیں۔ آج، TXT ریکارڈز بنیادی طور پر ای میل کی توثیق کے سخت فریم ورکس، کرپٹوگرافک کلید کی تقسیم، اور خودکار ڈومین ملکیت کی تصدیق کے لیے استعمال کیے جاتے ہیں۔

ای میل کی توثیق کا ٹرائیڈ: SPF، DKIM، اور DMARC

اگر آپ کی ویب ایپلیکیشن یا کارپوریٹ سرور سے جانے والی آؤٹ باؤنڈ ای میلز براہ راست سپیم فولڈرز میں جا رہی ہیں، تو غلط کنفیگر کیے گئے TXT ریکارڈز تقریباً ہمیشہ مجرم ہوتے ہیں۔ جدید موصول کرنے والے MTAs (جیسے Microsoft 365 یا Gmail) تین مخصوص TXT پالیسیوں کے ذریعے شناخت کے کرپٹوگرافک ثبوت کا مطالبہ کرتے ہیں:

  • SPF (Sender Policy Framework): ایک سختی سے فارمیٹ شدہ TXT سٹرنگ (مثلاً، v=spf1 include:_spf.google.com ~all) جو پبلک وائٹ لسٹ (whitelist) کے طور پر کام کرتی ہے۔ یہ مخصوص IP بلاکس اور فریق ثالث بھیجنے والی سروسز (جیسے Mailgun یا SendGrid) کو ڈومین کی جانب سے میل بھیجنے کا اختیار دیتا ہے۔
  • DKIM (DomainKeys Identified Mail): ایک TXT ریکارڈ جس میں ایک بڑی Base64-انکوڈ شدہ پبلک کرپٹوگرافک کلید ہوتی ہے۔ آپ کا آؤٹ باؤنڈ میل سرور ای میل ہیڈرز کو ہیش (hash) کرتا ہے اور ان پر ایک نجی کلید (private key) کے ساتھ دستخط کرتا ہے۔ موصول کرنے والا سرور ریاضیاتی طور پر دستخط کی تصدیق کرنے کے لیے اس TXT ریکارڈ سے عوامی کلید لاتا ہے، جس سے یہ یقینی بنتا ہے کہ پے لوڈ (Payload) کو راستے میں تبدیل نہیں کیا گیا تھا۔
  • DMARC (Domain-based Message Authentication, Reporting, and Conformance): نفاذ کی تہہ (enforcement layer)۔ یہ TXT ریکارڈ وصول کرنے والے سرورز کو ہدایت دیتا ہے کہ وہ ان پیغامات کو کیسے سنبھالیں جو SPF یا DKIM چیک میں ناکام ہو جاتے ہیں، یہ بتاتا ہے کہ آیا p=none (نگرانی)، p=quarantine (سپیم میں بھیجیں)، یا p=reject (مکمل طور پر گرا دیں) کی پالیسی لاگو کی جائے۔

Automated Domain Ownership اور Zero-Trust

ای میل کے علاوہ، TXT ریکارڈز ڈومین نام پر انتظامی کنٹرول ثابت کرنے کے لیے عالمگیر معیار ہیں۔ کلاؤڈ فراہم کنندہ (جیسے Google Search Console، GitHub Pages، یا AWS SES) کے ساتھ کسی ڈومین کو مربوط کرتے وقت، پلیٹ فارم ایک بے ترتیب کرپٹوگرافک ہیش تیار کرے گا۔ ایڈمنسٹریٹر کو اس ہیش کو TXT ریکارڈ کے طور پر شائع کرنے کا تقاضا کر کے، فراہم کنندہ خودکار DNS لک اپ کے ذریعے اس بات کی تصدیق کرتا ہے کہ صارف کو ڈومین کے روٹنگ انفراسٹرکچر تک روٹ لیول (root-level) تک رسائی حاصل ہے۔ اسی طرح، Let's Encrypt کے زیر استعمال ACME پروٹوکول DNS-01 چیلنج پر بہت زیادہ انحصار کرتا ہے، جہاں وائلڈ کارڈ SSL/TLS سرٹیفکیٹس کے اجراء کو اختیار دینے کے لیے ایک عارضی TXT ریکارڈ ڈپلائے کیا جاتا ہے۔

بائٹ کی حدود اور اسٹرنگ کنکٹنیشن (String Concatenation)

ایک تکنیکی حد جس کا اکثر ڈویلپرز کو سامنا کرنا پڑتا ہے وہ ہے DNS تصریح کے اندر 255 حروف کی سٹرنگ حد فی TXT چنک (chunk)۔ جب DKIM کے لیے 2048-bit RSA کلیدوں جیسے بڑے پے لوڈز (Payloads) شائع کیے جاتے ہیں، تو پے لوڈ اس بائٹ کی حد سے تجاوز کر جاتا ہے۔ اسے حل کرنے کے لیے، معیاری DNS سافٹ ویئر (جیسے BIND) طویل ریکارڈ کو خود بخود متعدد اقتباسات میں بند سٹرنگز (مثلاً، "string1" "string2") میں توڑ دیتا ہے۔ کلائنٹ ریزولور پڑھنے کے عمل کے دوران ان حصوں کو بغیر کسی رکاوٹ کے ایک ساتھ جوڑنے کا ذمہ دار ہے۔