بحث سجل TXT العالمي
صُمم سجل TXT (النص) في الأصل في الثمانينيات كـ Sandbox بسيط لمسؤولي الأنظمة لترك ملاحظات يمكن للبشر قراءتها داخل ملف المنطقة، وقد تطور ليصبح أحد أهم المكونات الهيكلية لأمن الشبكات الحديثة. نظراً لأن بروتوكول DNS لا يطبق فعلياً أي تحقق من صحة بناء الجملة على الـ Payloads الخاصة بـ TXT، يستخدم المطورون ومنصات الأمان هذه السجلات لتخزين سلاسل بيانات عشوائية يمكن قراءتها آلياً. اليوم، تُستخدم سجلات TXT بشكل أساسي لإطارات عمل مصادقة البريد الإلكتروني الصارمة، وتوزيع مفاتيح التشفير، والتحقق التلقائي من ملكية النطاق.
ثلاثي مصادقة البريد الإلكتروني: SPF و DKIM و DMARC
إذا كانت رسائل البريد الإلكتروني الصادرة من تطبيق الويب أو خادم الشركة تتجه مباشرة إلى مجلدات البريد العشوائي (Spam)، فإن سجلات TXT التي تم تكوينها بشكل خاطئ هي الجاني في الغالب. تطلب وكلاء نقل البريد (MTA) المستقبلون الحديثون (مثل Microsoft 365 أو Gmail) إثبات هوية مشفر عبر ثلاث سياسات TXT محددة:
- SPF (إطار سياسة المرسل): سلسلة TXT منسقة بشكل صارم (مثل
v=spf1 include:_spf.google.com ~all) تعمل كقائمة بيضاء عامة. إنها تفوض كتل IP محددة وخدمات إرسال تابعة لجهات خارجية (مثل Mailgun أو SendGrid) لإرسال البريد نيابة عن النطاق. - DKIM (بريد محدد بمفاتيح النطاق): سجل TXT يحتوي على مفتاح تشفير عام ضخم مشفر بـ Base64. يقوم خادم البريد الصادر الخاص بك بتجزئة عناوين البريد الإلكتروني وتوقيعها بمفتاح خاص. يجلب الخادم المتلقي المفتاح العام من سجل TXT هذا للتحقق رياضياً من التوقيع، مما يضمن عدم تغيير الـ Payload أثناء النقل.
- DMARC (مصادقة الرسائل المستندة إلى النطاق وإعداد التقارير والمطابقة): طبقة الإنفاذ. يوجه سجل TXT هذا الخوادم المستقبلة حول كيفية التعامل مع الرسائل التي تفشل في فحوصات SPF أو DKIM، ويملي ما إذا كان يجب تطبيق سياسة
p=none(مراقبة)، أوp=quarantine(إرسال إلى البريد العشوائي)، أوp=reject(إسقاط تماماً).
ملكية النطاق الآلية و Zero-Trust
إلى جانب البريد الإلكتروني، تعد سجلات TXT المعيار العالمي لإثبات الرقابة الإدارية على اسم النطاق. عند دمج نطاق مع مزود سحابة (مثل Google Search Console أو GitHub Pages أو AWS SES)، ستنشئ المنصة تجزئة تشفير عشوائية (Cryptographic Hash). من خلال مطالبة المسؤول بنشر هذا التجزئة كسجل TXT، يؤكد المزود عبر بحث DNS تلقائي أن المستخدم يمتلك وصولاً على مستوى الجذر (Root) إلى البنية التحتية لتوجيه النطاق. وبالمثل، يعتمد بروتوكول ACME المستخدم بواسطة Let's Encrypt بشكل كبير على تحدي DNS-01، حيث يتم نشر سجل TXT مؤقت للإذن بإصدار شهادات SSL/TLS (Wildcard).
حدود البايت وتوصيل السلاسل (String Concatenation)
هناك قيود فنية يواجهها المطورون غالباً وهي حد السلسلة المكونة من 255 حرفاً لكل كتلة (Chunk) من TXT ضمن مواصفات DNS. عند نشر Payloads ضخمة، مثل مفاتيح RSA بـ 2048 بت لـ DKIM، يتجاوز الـ Payload هذا الحد. لحل هذه المشكلة، يقوم برنامج DNS القياسي (مثل BIND) تلقائياً بتقسيم السجل الطويل إلى سلاسل متعددة محاطة بعلامات اقتباس (مثل "string1" "string2"). محلل العميل (Resolver) مسؤول عن ربط هذه الكتل بسلاسة معاً مرة أخرى أثناء عملية القراءة.