TXT रिकॉर्ड 255 अक्षर तक सीमित क्यों है?

रिकॉर्ड की हर स्ट्रिंग के आगे एक बाइट की लंबाई होती है, जो एक स्ट्रिंग को 255 बाइट तक बाँधती है। पूरा रिकॉर्ड कई स्ट्रिंग रख सकता है, इसलिए असली सीमा DNS संदेश का आकार है।

रिज़ॉल्वर बँटी हुई TXT स्ट्रिंगें कैसे जोड़ता है?

वह उन्हें क्रम में, बिना किसी विभाजक के जोड़ता है। DKIM, SPF और सत्यापन टोकन इसी व्यवहार पर टिके हैं।

DKIM कुंजी कहाँ काटनी चाहिए?

कहीं भी, बस हर टुकड़ा 255 बाइट से ज़्यादा न हो। सत्यापक के लिए जुड़ने के बाद कुंजी एक ही Base64 स्ट्रिंग है।

पूरा TXT रिकॉर्ड कितना बड़ा हो सकता है?

व्यवहार में कुछ किलोबाइट, पर लगभग 512 बाइट से बड़े उत्तर को EDNS या TCP पुनःप्रयास चाहिए। कुछ रिज़ॉल्वर इसे ठीक से नहीं संभालते।

क्या SPF रिकॉर्ड भी इसी तरह बाँटना पड़ता है?

तभी जब एक स्ट्रिंग 255 बाइट पार करे, जो कई include के साथ होता है। SPF की दस DNS लुकअप वाली अपनी सीमा अलग है।

DNS TXT रिकॉर्ड स्प्लिटर

लंबी TXT वैल्यू को DNS की 255-बाइट स्ट्रिंग में काटिए, ज़ोन फ़ाइल के लिए तैयार।

DNS TXT रिकॉर्ड स्प्लिटर पूरी तरह आपके ब्राउज़र में चलता है। कुंजियाँ और सत्यापन टोकन आपके डिवाइस पर ही कटते हैं।

DKIM रिकॉर्ड बनाइए

DNS TXT रिकॉर्ड स्प्लिटर के बारे में

TXT रिकॉर्ड एक लंबी स्ट्रिंग नहीं है। RFC 1035 उसे अधिकतम 255 बाइट की स्ट्रिंगों की शृंखला की तरह रखता है, और रिज़ॉल्वर उन्हें बीच में कुछ डाले बिना जोड़ देता है। इसीलिए 2048-बिट DKIM कुंजी को ज़ोन फ़ाइल में कई उद्धृत टुकड़ों में देना पड़ता है, और इसीलिए ग़लत जगह काटना — या टुकड़ों को स्पेस से जोड़ना — मेल हस्ताक्षर को ऐसे तोड़ता है जिसे ढूँढ़ना मुश्किल होता है। यह उपकरण बाइट सीमा पर काटता है, कभी अक्षर के बीच नहीं।

विशेषताएँ

255-बाइट सीमा पर काटता है, अक्षर नहीं बाइट गिनता है
बहु-बाइट अक्षर या सरोगेट जोड़ी कभी नहीं तोड़ता
BIND एक पंक्ति, कोष्ठक वाला, सिर्फ़ उद्धृत स्ट्रिंग या JSON सरणी प्रारूप
हर टुकड़े की बाइट गिनती, ताकि भरी हुई स्ट्रिंग दिखें
अतिरिक्त खाली जगह, पहले से लगे उद्धरण और 512 बाइट से बड़े रिकॉर्ड की चेतावनी
ज़ोन फ़ाइल या dig के उत्तर की स्ट्रिंगें वापस जोड़ता है
2048-बिट DKIM, लंबे SPF और सत्यापन टोकन के नमूने

DNS TXT रिकॉर्ड स्प्लिटर का उपयोग कैसे करें

पूरी TXT वैल्यू चिपकाइए — उद्धरण अपने आप लगते हैं
पूरी ज़ोन पंक्ति चाहिए तो रिकॉर्ड नाम और TTL डालिए
अपने DNS प्रदाता के हिसाब से आउटपुट प्रारूप चुनिए
रिकॉर्ड कॉपी कीजिए, या जोड़ने वाले टैब से बँटी वैल्यू वापस जोड़िए

उदाहरण

इनपुट

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A… (392 bytes)

आउटपुट

default._domainkey 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIja…" "…QIDAQAB"

दो उद्धृत स्ट्रिंग, जिन्हें रिज़ॉल्वर बीच में कुछ डाले बिना जोड़ देता है।

सामान्य त्रुटियाँ और समस्या निवारण

DNS प्रदाता रिकॉर्ड को बहुत लंबा कहकर मना कर देता है। — वह 255-बाइट सीमा एक ही स्ट्रिंग पर लगा रहा है। बँटा हुआ रूप चिपकाइए, हर टुकड़ा अलग उद्धरण में।
बाँटने के बाद DKIM सत्यापन विफल होता है। — लगभग हमेशा टुकड़ों के बीच स्पेस होता है। रिज़ॉल्वर स्ट्रिंगों को बिना कुछ डाले जोड़ते हैं, इसलिए कोई भी स्पेस कुंजी का हिस्सा बन जाता है।
रिकॉर्ड वैल्यू में पहले से उद्धरण हैं। — कच्ची वैल्यू चिपकाइए। उद्धरण प्रारूप बनाते समय लगते हैं, और पहले से उद्धृत वैल्यू दो बार उद्धृत हो जाती है।
टुकड़े 255 अक्षर से छोटे हैं। — सीमा 255 बाइट की है, अक्षरों की नहीं। कोई भी ग़ैर-ASCII अक्षर दो से चार बाइट लेता है।

अक्सर पूछे जाने वाले प्रश्न

TXT रिकॉर्ड 255 अक्षर तक सीमित क्यों है?: रिकॉर्ड की हर स्ट्रिंग के आगे एक बाइट की लंबाई होती है, जो एक स्ट्रिंग को 255 बाइट तक बाँधती है। पूरा रिकॉर्ड कई स्ट्रिंग रख सकता है, इसलिए असली सीमा DNS संदेश का आकार है।
रिज़ॉल्वर बँटी हुई TXT स्ट्रिंगें कैसे जोड़ता है?: वह उन्हें क्रम में, बिना किसी विभाजक के जोड़ता है। DKIM, SPF और सत्यापन टोकन इसी व्यवहार पर टिके हैं।
DKIM कुंजी कहाँ काटनी चाहिए?: कहीं भी, बस हर टुकड़ा 255 बाइट से ज़्यादा न हो। सत्यापक के लिए जुड़ने के बाद कुंजी एक ही Base64 स्ट्रिंग है।
पूरा TXT रिकॉर्ड कितना बड़ा हो सकता है?: व्यवहार में कुछ किलोबाइट, पर लगभग 512 बाइट से बड़े उत्तर को EDNS या TCP पुनःप्रयास चाहिए। कुछ रिज़ॉल्वर इसे ठीक से नहीं संभालते।
क्या SPF रिकॉर्ड भी इसी तरह बाँटना पड़ता है?: तभी जब एक स्ट्रिंग 255 बाइट पार करे, जो कई include के साथ होता है। SPF की दस DNS लुकअप वाली अपनी सीमा अलग है।