الخلاصة

  • يضع RFC 10023 سجل TXT عند _for-sale.<domain>، ويبدأ السجل الصحيح حرفياً وبحساسية حالة الأحرف بـ v=FORSALE1;، ثم يمكن أن يضيف دليلاً واحداً من fcod أو ftxt أو furi أو fval.
  • السجل دعوة إلى التواصل لا عقداً. قيمة fval إرشادية وغير ملزمة، وURI الصحيح نحوياً قد يكون ضاراً، وDNSSEC يصادق مصدر بيانات DNS وسلامتها ولا يثبت الأهلية القانونية لبيع النطاق.
  • يلزم فصل رصد السجل، والتحكم في المنطقة، وهوية المسجل، وتفويض الممثل، والشروط، وحماية الأموال، والنقل لدى المسجل، واستمرارية DNS والبريد والشهادات والتطبيقات.

حين تصل «فرصة الشراء» قبل أن يصل سؤال السلطة

تلتقط منصة استحواذ سجلاً جديداً تحت نطاق ما يزال يشغّل البريد وتسجيل دخول العملاء. يظهر السعر 75 ألف دولار، ويظهر عنوان HTTPS، وتنجح مصادقة DNSSEC. فتمنح المنصة البطاقة وصف «معروض للبيع بعد التحقق» وتفتح مسار الشراء.

قد تكون كل قراءة تقنية في البطاقة صحيحة، من دون أن تكون النتيجة التجارية صحيحة.

فمن عدّل منطقة DNS قد يملك صلاحية تشغيلية ولا يملك حق التصرف في أصل المسجل. وربما كانت بيانات اعتماد API مخترقة. وقد يكون الوسيط حقيقياً لكن وكالته انتهت. وقد يكون السعر قديماً أو العرض متعلقاً بالإيجار لا بنقل سيطرة التسجيل. وحتى نجاح النقل لدى المسجل لا يضمن بقاء DNSSEC أو البريد أو الشهادات أو الهوية عاملة.

RFC 10023، المنشور في يوليو 2026 بوصفه RFC معلوماتياً، يعرّف عرفاً تشغيلياً محدوداً. يستطيع الحائز إضافة الورقة المحجوزة _for-sale إلى المنطقة للدلالة على أن النطاق الأب متاح للشراء. ويستعمل النص «للبيع» بمعنى واسع قد يشمل التأجير أو عرض الحق التعاقدي في الاستخدام. يمكن تشغيل الدلالة وإيقافها مع استمرار النطاق في العمل ومن دون تعديل بروتوكول DNS.

تجيب بيانات التسجيل عن كون الاسم مسجلاً، لكنها لا تجيب دائماً عن استعداد حائزه للتفاوض. هذا هو الفراغ الذي تسده الإشارة. أما التفاوض والسلطة والتنفيذ فتبقى خارجه عمداً.

سلسلة الإصدار تثبت نوع الإشارة فقط

يجب أن يبدأ السجل تماماً بـ v=FORSALE1;، من دون فراغ وبحالة الأحرف نفسها. بعد ذلك يسمح بزوج واحد فقط من وسم وقيمة:

  • fcod= يحمل رمزاً غير شفاف يتفق معناه بين معالجات متعاونة؛
  • ftxt= يحمل نصاً موجزاً يقرأه الإنسان؛
  • furi= يحمل URI أو IRI واحداً للمعلومات أو الاتصال؛
  • fval= يحمل أحرف عملة كبيرة يتبعها رقم.

يجوز أن يضم RRset عدة سجلات TXT. ويمكن تكرار الوسم بقيم مختلفة إذا كان كل زوج كاملاً فريداً. وللمعالج أن يختار سجلاً واحداً أو أكثر.

هذا الاختيار جزء من التفسير. قد يعرض سوق رمزه fcod وحده، ويأخذ مؤشر أسعار fval وحده، ويفضل تطبيق بشري ftxt ورقم الهاتف. لا تمثل أي شاشة منها RRset كاملاً. لذلك يجب حفظ الجواب كله وقاعدة الاختيار مع النتيجة المرئية.

وإذا كان وسم الإصدار صحيحاً لكن المحتوى غائباً أو غير صالح، فينبغي للمعالج عادة افتراض أن النطاق معروض، ما لم تنص سياسة محلية على غير ذلك، ثم البحث عن اتصال عبر آليات التسجيل المعتادة. أما النص التجاري من دون إصدار صحيح فلا يعد مؤشراً وفق هذا العرف؛ وإذا لم يوجد TXT صالح وجب تجاهل العقدة.

إذن يقول الإصدار: «هذه إشارة من RFC 10023». ولا يقول: «هذا الشخص مخول بإلزام الحائز».

لكل وسم جهة ثقة مختلفة

يكتسب fcod معناه خارج DNS. قد تتفق جهة سجل ومسجّلون على بادئة معينة وتحولها إلى صفحة بيع. ويمكن تغيير الوجهة مركزياً في النظام الخلفي مع بقاء قيمة DNS كما هي. يفيد ذلك في ضبط الروابط وتحديثها.

لكنه ينقل المعنى الحاسم إلى جدول خاص. لا يستطيع طرف ثالث تفسير الرمز وحده. وإذا تغير الجدول وصل المستخدم إلى مكان آخر من دون تغير السجل العام. ومن دون تاريخ مؤرخ للخريطة تصبح المنصة المصدر الوحيد لمعرفة ما كان الرمز يعنيه وقت الرصد.

يسمح ftxt بشرح بشري، لكنه مدخل غير موثوق. قد يتضمن محارف تحكم أو Unicode مضللاً أو وسوماً خطرة. وقد تظهر السلسلة ;ftxt= داخل قيمة fcod صحيحة من دون أن تنشئ حقلاً ثانياً. التقسيم الساذج عند الفاصلة المنقوطة يصنع ادعاء لم يُنشر.

يحتوي furi عنواناً واحداً قابلاً للمعالجة. توصى مخططات HTTP وHTTPS وmailto وtel، ويفضل HTTPS حيث يناسب. الصحة النحوية ليست سمعة. يحذر RFC من التصيد والبرمجيات الضارة والهجمات البرمجية، ويحظر توجيه المستخدم تلقائياً من دون موافقة صريحة.

يجعل fval السعر قابلاً للاستخراج. يوصى برموز العملات الورقية ذات الأحرف الثلاثة الكبيرة، وتسمح القواعد أيضاً باختصارات معروفة للأصول المشفرة. لكن القيمة إرشادية وغير ملزمة صراحة. لا يجوز لنظام آلي إنشاء التزام شراء استناداً إليها وحدها.

هذه الوسوم ترشد إلى الخطوة التالية. ولا تحدد الحق المباع أو هوية صاحبه أو الضمانات أو الضرائب أو القبول أو الدفع أو النقل.

الحد القصير لا يحتمل ملف صفقة

يتكون RDATA لكل TXT من character-string واحدة لا تتجاوز 255 octets. توضع الأدلة المتعددة في سجلات منفصلة. يضع RFC 1035 أساس TXT وTTL، ويضيف RFC 10023 قواعد التطبيق.

ينبغي تحليل RDATA الخام لا الشكل المهرب الذي تعرضه أداة الاستعلام. ويوصى في المحتوى غير ASCII باستخدام UTF-8 وقواعد Network Unicode. ويمكن تحييد محارف التحكم عند العرض مع الاحتفاظ بالقيمة الأصلية للتدقيق.

قِصر الصيغة فضيلة مؤسسية. تحمل الطبقة المشتركة إشارة اكتشاف صغيرة ولا تتحول إلى غرفة بيانات أو عقد. وكل معنى أوسع يضعه معالج في نص أو رمز خاص يجب أن ينسب إلى ذلك المعالج ويخضع للمراجعة.

موضع الورقة يحدد النطاق المقصود

تشير _for-sale.example إلى الأب example. أما xyz._for-sale.example فغير مطابق لأن _for-sale ليست الورقة. ولا تعرض _for-sale.*.example كل الأسماء تحت المنطقة دفعة واحدة. يشرح RFC 4592 سلوك wildcards، ويستبعد RFC 10023 هذه البنية.

مع ذلك قد تولد wildcard موجودة جواباً مضللاً، خصوصاً مع CNAME أو DNAME. يجب أن يحفظ الجامع اسم الاستعلام ومالك الجواب وسلسلة الأسماء البديلة والدليل السلطوي وسياق التركيب. نص TXT الأخير وحده قد ينسب الإشارة إلى الاسم الخطأ.

يمكن وضع الورقة عند مستويات مختلفة من DNS. وفي نطاق فرعي لا يوجد له سجل حقوق عام قد يحتاج الطرفان إلى اتفاق منفصل يعرّف ما يمكن نقله. يجب تجاهل السجلات تحت .arpa حتى لا تبدو كعرض لحيز عناوين أو أرقام E.164. كما أن الأسماء ذات الاستخدام الخاص خارج النطاق.

يشرح RFC 8552 تسجيل الأسماء العالمية التي تبدأ بشرطة سفلية لتجنب تصادم الاستخدامات. ويسجل IANA DNS Parameters الآن TXT / _for-sale / RFC 10023. يثبت ذلك تخصيص الاسم، لا صحة المحتوى أو الانتشار أو سلطة البائع.

يضم سجل تصويبات RFC 10023 العنصر التقني 9090 بحالة Reported. يعترض على وصف “Root zone” في أول صف من جدول القسم 2.6 ويقترح TLD أو zone apex. لا تعني Reported أنها Verified؛ إنها مسألة مراجعة لا تعديلاً معيارياً مؤكداً.

ساعة في TTL لا تعني ساعة في العرض

ينبغي للحائز إزالة المؤشر حين تنتهي قابلية البيع. ويوصي RFC بقيمة TTL لا تزيد على 3,600 ثانية حتى لا يوهم cache طويل مشترياً بأن النطاق أو السعر ما يزال قائماً.

لكن TTL لا يمحو فهرس crawler أو لقطة شاشة أو قاعدة وسيط. ولا يحدد مدة الإيجاب القانونية. يجب أن يحمل كل رصد الوقت وTTL والمحلل والجواب الكامل وحالة التحقق، وأن يعاد الاستعلام السلطوي عند الاتصال والعرض والقبول والإفراج عن الأموال والنقل.

وغياب السجل ليس برهاناً على عدم البيع. فقد تفشل الدقة أثناء redemption أو pendingDelete أو حالة DNSSEC bogus. يجب تفسير غياب DNS تشغيلياً قبل تحويله إلى نية تجارية.

DNSSEC لا يقرأ الوكالة القانونية

يعرّف RFC 4033 مصادقة أصل بيانات DNS وحماية سلامتها ضمن سلسلة الثقة. ولا يوفر DNSSEC السرية. تزيد النتيجة الصحيحة الثقة بأن RRset هو البيانات المصادق عليها تحت مفاتيح DNS المعنية.

لكنها لا تفسر من أمر بنشرها.

قد يحرر مزود DNS المنطقة من دون أن يسيطر على التسجيل. وقد تكتب بيانات اعتماد مخترقة سجلاً يوقعه signer المنطقة بصورة صحيحة. وقد تبقى أتمتة موظف سابق. التحكم في DNS والقدرة على بيع الأصل سلطتان مختلفتان.

يصف RFC 9083 استجابات RDAP بصيغة JSON للكيانات والحالات وخوادم الأسماء. قد تكون البيانات محجوبة أو موزعة بحسب الأدوار. ولا تثبت وحدها الملكية المستفيدة أو موافقة المؤسسة أو وكالة الوسيط أو انعدام النزاع.

لا ينبغي حساب متوسط للتناقض. سجل DNSSEC صالح وهوية غير متطابقة وحساب registrar مقفل ليست «ثقة متوسطة»، بل سبباً لإيقاف التنفيذ.

للصفقة سلسلة إثبات مستقلة

يحفظ ملف الاكتشاف الاستعلام وRRset وTTL وDNSSEC ومالك الجواب وسلسلة alias. ويحدد ملف التحكم في المنطقة الحساب والمزود وبيانات الاعتماد والتفويض وسجل التغيير.

يطابق ملف الهوية بيانات registrar أو RDAP مع شخص قانوني موثق ويحدد الحق المعروض: سيطرة التسجيل أو الإيجار أو الترخيص أو نطاق فرعي أو حزمة أصول. ويثبت ملف التمثيل نطاق تفويض المفاوض وحدوده ومدته وإلغاءه.

تستبدل الشروط الرسمية دليل DNS بسعر وعملة وأصول وضرائب وضمانات وقبول ذات إصدارات. ويقدم الدفع وescrow إثباتاً آخر. ويسجل registrar فك القفل والرموز وaccount push وحالة النقل والبيانات النهائية.

وتفحص الاستمرارية nameservers ومفاتيح DNSSEC وDS والبريد والشهادات والهوية وواجهات API والتجديد. إبرام العقد وتغيير التسجيل وبقاء الخدمة ثلاث نتائج منفصلة.

يطبق Running-Code Primacy ترتيب الأفعال: خادم DNS ينتج الرصد، وvalidator ينتج الحكم الأمني، وأنظمة الهوية والعقد تنشئ السلطة، وregistrar يغير السيطرة، والتطبيقات تنتج الاستمرارية. لا يستطيع badge تنفيذها بالإعلان.

تبرر Minimum Initial Specification طبقة مشتركة صغيرة. يمكن توحيد اكتشاف دقيق من دون فرض سوق أو وسيط أو escrow أو قانون واحد. وتبقى القرارات المحلية قابلة للتصدير والاستبدال.

تفصل Reality Layers بين TXT الرمزي، والنشر التشغيلي، والحق المؤسسي، والاتفاق التجاري، وتجربة استمرار الخدمة. تضغط عبارة «بيع موثق» هذه الطبقات وتمنح مصمم الواجهة سلطة رمزية.

وتسأل Data Sovereignty من يستطيع إعادة البناء. من يحفظ RRset وتاريخ المنطقة وخريطة fcod والهويات والتفاوض والدفع والنقل والاستمرارية يسيطر عملياً على النزاع. بطاقة النتيجة وحدها لا تمنح العميل سيادة على الدليل.

المصادر