ग्लोबल TXT Record Lookup
मुळात 1980 च्या दशकात सिस्टम ॲडमिनिस्ट्रेटर्ससाठी झोन फाईलमध्ये ह्युमन-रिडेबल (human-readable) नोट्स सोडण्यासाठी एक साधा सँडबॉक्स म्हणून डिझाइन केलेले, TXT (Text) रेकॉर्ड आधुनिक नेटवर्क सिक्युरिटीच्या सर्वात स्ट्रक्चरली क्रिटिकल कंपोनंट्सपैकी एक म्हणून विकसित झाले आहे. कारण DNS प्रोटोकॉल TXT पेलोड्सवर प्रत्यक्षतः कोणतेही सिंटॅक्स व्हॅलिडेशन लागू करत नाही, डेव्हलपर्स आणि सिक्युरिटी प्लॅटफॉर्म्स या रेकॉर्ड्सचा वापर अर्बिट्ररी (arbitrary) मशीन-रिडेबल डेटा स्ट्रिंग्स साठवण्यासाठी करतात. आज, TXT रेकॉर्ड्स प्रामुख्याने कठोर ईमेल ऑथेंटिकेशन फ्रेमवर्क्स, क्रिप्टोग्राफिक की (key) डिस्ट्रीब्यूशन आणि ऑटोमेटेड डोमेन ओनरशिप व्हेरिफिकेशनसाठी वापरले जातात.
ईमेल ऑथेंटिकेशनचे त्रिकूट: 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-एनकोडेड पब्लिक क्रिप्टोग्राफिक की (key) असते. तुमचा आऊटबाउंड मेल सर्व्हर ईमेल हेडर्स हॅश करतो आणि त्यांना प्रायव्हेट की ने साईन (sign) करतो. रिसीव्हिंग सर्व्हर हा सिग्नेचर गणितीयदृष्ट्या व्हेरिफाय करण्यासाठी या TXT रेकॉर्डमधून पब्लिक की फेच करतो, ज्यामुळे ट्रान्झिटमध्ये पेलोड बदलला गेला नसल्याची खात्री होते.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): एन्फोर्समेंट लेयर. हे TXT रेकॉर्ड रिसीव्हिंग सर्व्हर्सना निर्देश देते की SPF किंवा DKIM चेक्समध्ये फेल होणाऱ्या मेसेजेसचे काय करायचे आहे,
p=none(मॉनीटर),p=quarantine(स्पॅममध्ये पाठवणे), किंवाp=reject(संपूर्णपणे ड्रॉप करणे) पॉलिसी लागू करायची की नाही हे ठरवते.
ऑटोमेटेड डोमेन ओनरशिप आणि Zero-Trust
ईमेलच्या पलीकडे, TXT रेकॉर्ड्स हे डोमेन नेमवरील ॲडमिनिस्ट्रेटिव्ह कंट्रोल सिद्ध करण्यासाठी एक युनिव्हर्सल स्टँडर्ड आहेत. क्लाउड प्रोव्हायडर (जसे की Google Search Console, GitHub Pages, किंवा AWS SES) सोबत डोमेन इंटिग्रेट करताना, प्लॅटफॉर्म एक रँडम क्रिप्टोग्राफिक हॅश (hash) जनरेट करेल. ॲडमिनिस्ट्रेटरला हा हॅश TXT रेकॉर्ड म्हणून पब्लिश करणे बंधनकारक करून, प्रोव्हायडर ऑटोमेटेड DNS लुकअपद्वारे कन्फर्म करतो की युजरकडे डोमेनच्या राउटिंग इन्फ्रास्ट्रक्चरवर रूट-लेव्हल ॲक्सेस आहे. त्याचप्रमाणे, Let's Encrypt द्वारे वापरला जाणारा ACME प्रोटोकॉल DNS-01 चॅलेंजवर मोठ्या प्रमाणावर अवलंबून असतो, जिथे वाईल्डकार्ड (wildcard) SSL/TLS सर्टिफिकेट्स जारी करण्यासाठी अधिकृत करण्यासाठी एक तात्पुरते TXT रेकॉर्ड डिप्लॉय केले जाते.
बाइट लिमिट्स आणि String Concatenation
डेव्हलपर्सना वारंवार येणारी एक टेक्निकल मर्यादा म्हणजे DNS स्पेसिफिकेशनमधील प्रति TXT चंक (chunk) 255-कॅरेक्टर स्ट्रिंगची मर्यादा. जेव्हा मोठे पेलोड्स पब्लिश केले जातात, जसे की DKIM साठी 2048-bit RSA कीज, तेव्हा पेलोड या बाइट लिमिटच्या पलीकडे जातो. हे सोडवण्यासाठी, स्टँडर्ड DNS सॉफ्टवेअर (जसे की BIND) स्वयंचलितपणे लांब रेकॉर्डला कोट (quote) केलेल्या मल्टिपल स्ट्रिंग्समध्ये मोडते (उदा. "string1" "string2"). क्लायंट रिझॉल्व्हर रीडिंग प्रक्रियेदरम्यान हे चंक्स (chunks) अखंडपणे एकत्र जोडण्यासाठी (concatenate) जबाबदार असतो.