سجل نصي

سجل TXT ( اختصارًا لسجل نصي ) هو نوع من سجلات الموارد في نظام أسماء النطاقات (DNS) يُستخدم لتوفير إمكانية ربط نص عشوائي بمضيف أو اسم آخر، مثل معلومات قابلة للقراءة البشرية حول خادم أو شبكة أو مركز بيانات أو معلومات محاسبية أخرى. ^{[ 1 ]}

كما يتم استخدامه في كثير من الأحيان بطريقة أكثر تنظيماً لتسجيل كميات صغيرة من البيانات القابلة للقراءة آلياً في نظام أسماء النطاقات (DNS).

قد يرتبط نطاق واحد بسجلات نصية متعددة، شريطة أن يدعم خادم نظام أسماء النطاقات (DNS) ذلك. ^{[ 1 ]} ويمكن أن يحتوي كل سجل بدوره على سلسلة نصية واحدة أو أكثر. ^{[ 2 ]} تقليديًا، كانت هذه الحقول النصية تُستخدم لأغراض متنوعة غير قياسية، مثل اسم شركة أو مؤسسة كامل، أو عنوان مضيف.

بعض الأمثلة على استخدام ملفات TXT:

• التحقق من ملكية النطاق ^{[ 3 ] [ 4 ]}
• تنفيذ إطار سياسة المرسل (SPF) ^{[ 5 ]}
• سجلات DomainKeys Identified Mail (DKIM) للتحقق من مرسل رسائل البريد الإلكتروني ^{[ 6 ]}
• اكتشاف الخدمة القائم على نظام أسماء النطاقات (DNS) للشبكات بدون تكوين ^{[ 7 ] [ 8 ]}
• سياسات المصادقة والإبلاغ والتوافق المستندة إلى النطاق (DMARC)

لا يخلو استخدام سجلات TXT لتخزين البيانات لأغراض مختلفة من بعض المشاكل. ينص بروتوكول نظام أسماء النطاقات (DNS) على أنه عند استعلام عميل عن نوع سجل معين (مثل TXT) لاسم نطاق محدد (مثل example.com)، يجب إرجاع جميع سجلات هذا النوع في رسالة DNS واحدة. قد يؤدي ذلك إلى عمليات نقل بيانات ضخمة تتضمن الكثير من المعلومات غير الضرورية، أو إلى عدم اليقين بشأن سجل TXT المناسب. هناك حلان لهذه المشكلة: تحديد بادئة اسم نطاق لاستخدامها عند استخدام سجلات TXT لغرض معين (مثل _domainkey.example.com - في حالة DKIM)، أو إنشاء نوع سجل جديد بالكامل. يُعد الحل الأول "سهلاً" لأنه لا يتطلب أي تغييرات على نظام أسماء النطاقات. أما الحل الثاني، فيُعتبر أحيانًا "أكثر سلاسة" لأنه يتوافق بشكل أفضل مع تصميم نموذج قاعدة بيانات نظام أسماء النطاقات. في الماضي، كان يتم تجنب إنشاء أنواع سجلات جديدة نظرًا لتعقيد الإجراء في IETF . ولا يزال هذا التردد قائمًا لدى البعض رغم استبدال العملية بأخرى أبسط وأسرع.

يُحدد RFC 1035 ^{[ 2 ]} بنية سجل TXT كما يلي. تجدر الإشارة إلى أن هذا المعيار لا يتطرق إلى ترميز الأحرف في سلسلة النص. وينص صراحةً على أن تفسير السلسلة يعتمد على السياق، وأن البيانات تُعامل كبيانات ثنائية داخل نظام أسماء النطاقات (DNS). قد تتطلب معايير لاحقة (مثل RFC 6763 ^{[ 8 ]} - نظام أسماء النطاقات المستخدم لاكتشاف الخدمات) استخدام ترميزات محددة لأغراض معينة.

قد يحتوي قسم RDATA على عدة تكرارات متتالية لـ (طول النص + النص). طول البيانات هو مجموع أطوالها جميعًا.

0000 34 48 81 a0 00 01 00 02 00 00 00 01 07 65 78 61 0010 6d 70 6c 65 03 63 6f 6d 00 00 10 00 01 c0 0c 00 0020 10 00 01 00 00 54 5f 00 0c 0b 76 3d 73 70 66 31 0030 20 2d 61 6c 6c c0 0c 00 10 00 01 00 00 54 5f 00 0040 21 20 38 6a 35 6e 66 71 6 ج 64 32 30 7a 70 63 79 0050 72 38 78 6a 77 30 79 64 63 66 71 39 72 6b 38 68 0060 67 6d 00 00 29 02 00 00 00 00 00 00 00

0000 c0 0c 00 10 00 01 00 00 54 5f 00 0c 0b 76 3d 73 0010 70 66 31 20 2d 61 6c 6c

باعتبارها نصًا غير منظم، يمكن للمؤسسات استخدام سلسلة TXT بأي طريقة تحددها، على سبيل المثال:

example.com. IN TXT "هذا النطاق محجوز للاستخدام في التوثيق"

يحدد RFC 1464 تنسيقًا منظمًا يمكن استخدامه لتحديد السمات وقيمها في سجل واحد، ^{[ 1 ]} كما في هذه الأمثلة: 

host.widgets.com. IN TXT "printer=lpr5" sam.widgets.com. IN TXT "favorite drink=orange juice"

عملياً، غالباً ما لا تتبع الخدمات التي تستخدم سجلات TXT هذا المعيار RFC، بل يكون لها تنسيقها الخاص. ^{[ 9 ] [ 10 ]}

سلسلة الأحرف من سجل TXT المستخدمة في SPF :

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 ip6:2620:0:860::/46 a -all"

مثال على استخدام DMARC :

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;" 

يُستخدم للتحقق من الموقع:

"google-site-verification=6P08Ow5E-8Q0m6vQ7FMAqAYIDprkVV8fUf_7hZ4Qvc8" 

يُستخدم لخدمة البريد الإلكتروني المخصصة:

_amazonses.example.com. IN TXT "pmBGN/7MjnfhTKUZ06Enqq1PeGUaOkw8lGhcfwefcHU="

مؤشرات العلامة التجارية لتحديد الرسالة (BIMI):

default._bimi TXT "v=BIMI1; l=https://example.com/image.svg; a=https://example.com/image/certificate.pem"

يشير إلى أن اسم النطاق معروض للبيع :

_for-sale.example.com. TXT "v=FORSALE1;ftxt=This domain name is for sale"

• قائمة أنواع سجلات نظام أسماء النطاقات (DNS)
• DMARC
• DKIM
• التحقق من البريد الإلكتروني