Global TXT Record Lookup
मूल रूप से 1980 के दशक में सिस्टम एडमिनिस्ट्रेटर के लिए ज़ोन फ़ाइल के अंदर मानव-पठनीय (Human-readable) नोट्स छोड़ने के लिए एक साधारण सैंडबॉक्स के रूप में डिज़ाइन किया गया, TXT (Text) रिकॉर्ड आधुनिक नेटवर्क सुरक्षा के सबसे संरचनात्मक रूप से महत्वपूर्ण घटकों में से एक के रूप में विकसित हुआ है। चूँकि DNS प्रोटोकॉल वस्तुतः TXT पेलोड पर कोई सिंटैक्स सत्यापन लागू नहीं करता है, इसलिए डेवलपर्स और सुरक्षा प्लेटफ़ॉर्म मनमाने मशीन-पठनीय डेटा स्ट्रिंग को स्टोर करने के लिए इन रिकॉर्ड्स का उपयोग करते हैं। आज, TXT रिकॉर्ड का उपयोग मुख्य रूप से कड़े ईमेल प्रमाणीकरण फ़्रेमवर्क, क्रिप्टोग्राफ़िक कुंजी वितरण और स्वचालित डोमेन स्वामित्व सत्यापन के लिए किया जाता है।
The Email Authentication Triad: SPF, DKIM, और DMARC
यदि आपके वेब एप्लिकेशन या कॉर्पोरेट सर्वर से आउटबाउंड ईमेल सीधे स्पैम फ़ोल्डर में जा रहे हैं, तो ग़लत कॉन्फ़िगर किए गए TXT रिकॉर्ड लगभग हमेशा अपराधी होते हैं। आधुनिक प्राप्त करने वाले MTA (जैसे Microsoft 365 या Gmail) को तीन विशिष्ट TXT नीतियों के माध्यम से पहचान के क्रिप्टोग्राफ़िक प्रमाण की आवश्यकता होती है:
- SPF (Sender Policy Framework): एक कड़ाई से स्वरूपित TXT स्ट्रिंग (उदा.,
v=spf1 include:_spf.google.com ~all) जो एक सार्वजनिक श्वेतसूची (Whitelist) के रूप में कार्य करती है। यह विशिष्ट IP ब्लॉक और थर्ड-पार्टी प्रेषण सेवाओं (जैसे Mailgun या SendGrid) को डोमेन की ओर से मेल भेजने के लिए अधिकृत करता है। - DKIM (DomainKeys Identified Mail): एक बड़े Base64-एन्कोडेड सार्वजनिक क्रिप्टोग्राफ़िक कुंजी वाला एक TXT रिकॉर्ड। आपका आउटबाउंड मेल सर्वर ईमेल हेडर को हैश करता है और उन्हें एक निजी कुंजी के साथ साइन करता है। प्राप्त करने वाला सर्वर इस TXT रिकॉर्ड से सार्वजनिक कुंजी लाता है ताकि हस्ताक्षर को गणितीय रूप से सत्यापित किया जा सके, यह सुनिश्चित करते हुए कि पेलोड को पारगमन (Transit) में बदला नहीं गया था।
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): एन्फोर्समेंट लेयर। यह TXT रिकॉर्ड प्राप्त करने वाले सर्वर को निर्देश देता है कि उन संदेशों को कैसे हैंडल किया जाए जो SPF या DKIM जांच में विफल रहते हैं, यह तय करते हुए कि क्या
p=none(निगरानी),p=quarantine(स्पैम में भेजें), याp=reject(पूरी तरह से ड्रॉप करें) नीति लागू करनी है।
Automated Domain Ownership और Zero-Trust
ईमेल के अलावा, TXT रिकॉर्ड डोमेन नाम पर प्रशासनिक नियंत्रण साबित करने के लिए सार्वभौमिक मानक हैं। जब किसी क्लाउड प्रदाता (जैसे Google Search Console, GitHub Pages, या AWS SES) के साथ डोमेन को एकीकृत किया जाता है, तो प्लेटफ़ॉर्म एक यादृच्छिक क्रिप्टोग्राफ़िक हैश उत्पन्न करेगा। व्यवस्थापक को इस हैश को TXT रिकॉर्ड के रूप में प्रकाशित करने की आवश्यकता करके, प्रदाता एक स्वचालित DNS लुकअप के माध्यम से पुष्टि करता है कि उपयोगकर्ता के पास डोमेन के रूटिंग बुनियादी ढांचे तक रूट-स्तरीय पहुंच है। इसी तरह, Let's Encrypt द्वारा उपयोग किया जाने वाला ACME प्रोटोकॉल DNS-01 चैलेंज पर बहुत अधिक निर्भर करता है, जहां वाइल्डकार्ड SSL/TLS प्रमाणपत्र जारी करने को अधिकृत करने के लिए एक अस्थायी TXT रिकॉर्ड तैनात किया जाता है।
Byte Limits और String Concatenation
डेवलपर्स द्वारा अक्सर सामना की जाने वाली एक तकनीकी सीमा DNS विनिर्देश के भीतर प्रति TXT चंक 255-अक्षर की स्ट्रिंग सीमा है। बड़े पेलोड प्रकाशित करते समय, जैसे कि DKIM के लिए 2048-बिट RSA कुंजी, पेलोड इस बाइट सीमा से अधिक हो जाता है। इसे हल करने के लिए, मानक DNS सॉफ़्टवेयर (जैसे BIND) स्वचालित रूप से लंबे रिकॉर्ड को कई उद्धरण-संलग्न स्ट्रिंग (उदा., "string1" "string2") में तोड़ देता है। क्लाइंट रिज़ॉल्वर पढ़ने की प्रक्रिया के दौरान इन चंक्स को सहजता से वापस जोड़ने (Concatenate) के लिए ज़िम्मेदार है।