Global TXT Record Lookup
মূলত 1980-এর দশকে সিস্টেম অ্যাডমিনিস্ট্রেটরদের জন্য জোন ফাইলের ভেতরে হিউম্যান-রিডেবল (human-readable) নোট রেখে যাওয়ার জন্য একটি সিম্পল স্যান্ডবক্স হিসেবে ডিজাইন করা হলেও, TXT (Text) রেকর্ড আধুনিক নেটওয়ার্ক সিকিউরিটির অন্যতম স্ট্রাকচারালি ক্রিটিক্যাল কম্পোনেন্ট হিসেবে বিবর্তিত হয়েছে। যেহেতু DNS প্রোটোকল TXT পে-লোডের ওপর কার্যত কোনো সিনট্যাক্স ভ্যালিডেশন অ্যাপ্লাই করে না, তাই ডেভেলপার এবং সিকিউরিটি প্ল্যাটফর্মগুলো মেশিন-রিডেবল ডেটা স্ট্রিং স্টোর করার জন্য এই রেকর্ডগুলো ব্যবহার করে। বর্তমানে, TXT রেকর্ডগুলো মূলত কড়া ইমেইল অথেন্টিকেশন ফ্রেমওয়ার্ক, ক্রিপ্টোগ্রাফিক কি (key) ডিস্ট্রিবিউশন এবং অটোমেটেড ডোমেইন ওনারশিপ ভেরিফিকেশনের জন্য কাজে লাগানো হয়।
ইমেইল অথেন্টিকেশন ট্রায়াড: SPF, DKIM, এবং DMARC
যদি আপনার ওয়েব অ্যাপ্লিকেশন বা কর্পোরেট সার্ভার থেকে আউটবাউণ্ড ইমেইলগুলো সরাসরি স্প্যাম ফোল্ডারে চলে যায়, তবে মিসকনফিগার করা TXT রেকর্ড প্রায় সবসময়ই এর জন্য দায়ী। আধুনিক রিসিভিং MTA-গুলো (যেমন Microsoft 365 বা Gmail) তিনটি নির্দিষ্ট TXT পলিসির মাধ্যমে আইডেন্টিটির ক্রিপ্টোগ্রাফিক প্রুফ ডিমাণ্ড করে:
- SPF (Sender Policy Framework): একটি কঠোরভাবে ফরম্যাট করা TXT স্ট্রিং (যেমন,
v=spf1 include:_spf.google.com ~all) যা একটি পাবলিক হোয়াইটলিস্ট হিসেবে কাজ করে। এটি ডোমেইনের পক্ষে মেইল পাঠানোর জন্য নির্দিষ্ট IP ব্লক এবং থার্ড-পার্টি সেন্ডিং সার্ভিসগুলোকে (যেমন Mailgun বা SendGrid) অথরাইজ করে। - DKIM (DomainKeys Identified Mail): একটি বড় Base64-এনকোডেড পাবলিক ক্রিপ্টোগ্রাফিক কি (key) ধারণকারী একটি TXT রেকর্ড। আপনার আউটবাউণ্ড মেইল সার্ভার ইমেইল হেডারগুলোকে হ্যাশ করে এবং একটি প্রাইভেট কি (key) দিয়ে সেগুলোতে সাইন (sign) করে। রিসিভিং সার্ভার সিগনেচারটি গাণিতিকভাবে ভেরিফাই করার জন্য এই TXT রেকর্ড থেকে পাবলিক কি-টি ফেচ করে, এটি নিশ্চিত করে যে ট্রানজিটের সময় পে-লোডে কোনো পরিবর্তন করা হয়নি।
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): এনফোর্সমেন্ট লেয়ার। এই TXT রেকর্ড রিসিভিং সার্ভারগুলোকে নির্দেশ দেয় যে SPF বা DKIM চেক ফেইল করা মেসেজগুলো কীভাবে হ্যান্ডেল করতে হবে, এবং একটি
p=none(monitor),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 কি (keys), পে-লোডটি এই বাইট লিমিট অতিক্রম করে। এর সমাধানের জন্য, স্ট্যান্ডার্ড DNS সফটওয়্যার (যেমন BIND) স্বয়ংক্রিয়ভাবে লম্বা রেকর্ডটিকে একাধিক কোট-এনক্লোজড স্ট্রিংয়ে (যেমন, "string1" "string2") ভেঙে ফেলে। রিড প্রসেসের সময় এই চাঙ্কগুলোকে (chunks) আবার একসাথে কনক্যাটেনেট (concatenate) করার দায়িত্ব ক্লায়েন্ট রিজলভারের।