قبل أن يصبح WHOIS دليلاً: السلطة الهشة لسجلات جهات الاتصال

الملخص

• عرّف RFC 812 خدمة NICNAME/WHOIS في عام 1982 كدليل مقروء بشريًا لتحديد مواقع مستخدمي الشبكة. قام RFC 954 بتوسيع قاعدة البيانات القابلة للبحث في عام 1985، لكن لم تقدم أي من المواصفتين دليلاً على أن الاسم أو المعرف أو المؤسسة أو المضيف أو حقل الاتصال المرسل يشكل إثباتًا للحق القانوني أو التحكم التشغيلي الحالي.
• تطورت أربع عائلات من السجلات بمسارات مختلفة: إدخالات الدليل الشخصي، جهات اتصال المضيف والشبكة في DDN، تسجيلات النطاقات وعروضها العامة في WHOIS، وسجلات سجل موارد الأرقام. لم تحول واجهة الاستعلام المشتركة بينهم إلى نظام ملكية موحد.
• يوفر حادث وقع في ديسمبر 1990 دليلاً مباشرًا على الاعتماد التشغيلي والإسناد المحدود للمسؤولية: قام سجل شبكة DDN NIC بتوجيه المواقع المتضررة وCERT/CC نحو مؤسسة، بينما ظلت السجلات والإدارة المحلية والتحقيق المباشر ضرورية لتحديد الجهاز والمشغل.
• يقدم نزاع فبراير 1996 حول تسجيل CLUE.COM حالة مكتملة للمكانة الإدارية في إجراءات التسجيل الأساسية لشركة Network Solutions. تلقى المسجل المسجل إشعارًا، واعترض على التغيير المهدد، وحصل على أمر قضائي يحفظ التسجيل. لا يُظهر السجل القضائي أن استعلام WHOIS العام أنشأ هذه المكانة بشكل مستقل.
• توثق دعوى Kremen اصطدامًا آخر في أكتوبر 1995: قامت Network Solutions بتغيير قاعدة بيانات التسجيل الرسمية بعد تلقي تعليمات مزورة، مما أدى إلى عواقب استخدام عملية. يمكن لـ WHOIS العام أن يعكس الحالة المتغيرة، لكن الأدلة لا تُظهر أن استعلامًا عامًا تسبب في التغيير أو منح الملكية.
• بحلول عام 1996، كانت بيانات تسجيل موارد الأرقام وإعادة التخصيص مدخلات موصوفة لقرارات الاتصال التشغيلي والتخصيص الإضافي. ومع ذلك، طالب RFC 2050 بوثائق داعمة، وحماية المواد الحساسة التي يحددها مقدم الطلب، وتوفير مراجعة عبر التسلسل الهرمي للسجل. لا تُظهر أي حالة تم فحصها هنا أن صفًا عامًا لمورد أرقام قرر الاستحقاق بمفرده.

قراءة المخطط قبل قراءة السلطة فيه

من الأفضل مقاربة المواصفات المبكرة على أنها علم آثار المخطط. قبل السؤال عن متى أصبحت WHOIS دليلاً، من الضروري أن نسأل ما صُممت سجلاتها لتحتويه، ومن كان متوقعًا أن يظهر، وما الذي كانت تدّعي الاستجابة تقديمه.

وصفRFC 812، الذي كتبه كين هارنستين وفيك وايت بتاريخ 1 مارس 1982، خدمة NICNAME/WHOIS كخادم استعلام واستجابة قائم على المعاملات على جهاز SRI-NIC. قدم دليلًا شبكيًا لمستخدمي ARPANET نيابة عن وكالة اتصالات الدفاع. كان المستخدم يرسل سطر أوامر واحدًا، ويتلقى استجابة، وينقطع الاتصال. وكان الرد مخصصًا لقارئ بشري وليس للتفسير الآلي.

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

احتفظRFC 954، الذي كتبه ك. هارنستين، م. ك. ستال، وإ. ج. فاينلر بتاريخ أكتوبر 1985، بالمنفذ 43 وبنية الاستعلام الواحد والاستجابة الواحدة. ووصف الخدمة بأنها دليل لمستخدمي الإنترنت، وذكر مرة أخرى أن مخرجاتها كانت قابلة للقراءة البشرية. كان الجمهور القابل للبحث أوسع: الأشخاص وصناديق البريد المسجلين، ومنظمات الشبكة، وعُقد DDN والمضيفين المرتبطين بها، ومستخدمي الوصول الطرفي لـ MILNET المسجلين.

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

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

يكمن الفرق بين الدليل والنظام الإثباتي جزئيًا في ما يحيط بالحقول المعروضة. يثير النظام الإثباتي أسئلة حول المصدر، وسلطة التقديم، والمصادقة، وتواريخ السريان، والإصدارات الملغاة، والتصحيحات المتنازع عليها، وأسباب التغيير، والمراجعة. حدد كل من RFC 812 وRFC 954 خدمة الاستعلام العامة. ولم يحددا سجل تدقيق عام يجيب على تلك الأسئلة.

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

لذلك يجب أن تبقى خمسة مكونات منفصلة:

1. قاعدة بيانات التسجيل أو التعريف الأساسية للمؤسسة؛
2. استجابة WHOIS العامة المولدة من قاعدة البيانات تلك؛
3. الإجراء الذي تتم من خلاله إضافة تسجيل أو جهة اتصال أو تغييرها أو حذفها؛
4. الأنظمة التشغيلية المرتبطة بالمعرف، بما في ذلك إدارة المضيف والتوجيه وتفويض DNS؛
5. العقود ومراسلات التخصيص والتعيينات التنظيمية والموافقة والسجلات القانونية خارج قاعدة البيانات.

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

السلم الإثباتي المفحوص هنا هو:

الراحة الدليلية -> الاعتماد التشغيلي -> إسناد المسؤولية -> المكانة الإدارية -> استدلال شبيه بالاستحقاق

تتطلب كل خطوة صعودية أكثر من مجرد مواصفة تظهر وجود حقل. إنها تتطلب فاعلاً مؤرخًا، وسجلاً معينًا، وقرارًا، ومصدر حقيقة منافسًا، ونتيجة قابلة للملاحظة. حيث يقدم الأرشيف إجراءً موصوفًا فقط، يجب أن يبقى الاستنتاج توقعًا موثقًا بدلاً من فعل اعتماد مكتمل.

الاسم والمعرف: سجل الدليل الشخصي

كانت عائلة السجلات الأولى دليلًا للأشخاص.

ما كانت الحقول من أجله

أجاب حقل الاسم عن أبسط سؤال: أي شخص يُبحث عنه؟ جعل المعرف تلك الإجابة أكثر استقرارًا داخل قاعدة البيانات. يمكن للمستخدم البحث على نطاق واسع ثم اختيار إدخال معين بواسطة معرفه. ويمكن أن تشير السجلات الأخرى إلى المعرف دون إعادة إنتاج كل حقل اتصال.

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

لم يكن وثيقة هوية. لم يصف RFC 812 ولا RFC 954 إثبات هوية وثائقي، أو توقيع مرتبط بالمعرف، أو سلطة خارجية تصادق على كل انتماء. أثبت المعرف الاستمرارية في قاعدة البيانات بشكل أوضح من الاستمرارية في وظيفة الشخص أو مسؤولياته أو أهليته القانونية.

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

التقديم والتحديث والمصادقة

أمر RFC 812 الأفراد بإرسال معلومات التسجيل إلى NIC. استخدم RFC 954 قناة مسجل للتقديمات المماثلة. تحدد المواصفات الموضوع والوجهة المتوقعين للمعلومات، لكنها لا تصف بروتوكول تحديث موثق منفصل.

تدعم المواصفات الباقية التدقيق المحدود التالي:

• المقدم والمصدر:جاءت المعلومات من فرد يسعى أو يُطلب منه التسجيل لدى NIC.
• سلطة التحديث:لا تذكر طلبات التعليقات RFCs قاعدة شاملة لتحديد من يمكنه استبدال سجل شخص موجود.
• المصادقة:لا توجد طريقة موحدة للتحقق من الهوية محددة في وثائق البروتوكول العامة.
• التصحيح:وجدت قنوات مساعدة وتسجيل، لكن طلبات التعليقات لا تصف إجراء تصحيح متنازع عليه.
• الاستبدال والوقت الحالي:مثل الرد العام الإجابة الحالية لقاعدة البيانات؛ لا تحدد المواصفات تاريخ سريان لكل سجل.
• الاحتفاظ التاريخي:لا توجد سلسلة عامة للقيم السابقة محددة.
• مراجعة النزاع:لا تشرح طلبات التعليقات كيف سيقرر الموظفون بين المطالبات غير المتوافقة المتعلقة بنفس الإدخال الشخصي.
• حد الخصوصية:تم كشف معلومات الوصول الشخصية عن قصد لأن الاكتشاف الشخصي كان الغرض الأصلي للخدمة.

غير معروف لا يعني غير موجود. ربما وفرت المراسلات الداخلية أو ممارسات الموظفين ضوابط لم توثقها طلبات التعليقات. النتيجة التي يمكن الدفاع عنها هي أن تلك الضوابط لم تكن جزءًا من الإثبات المقدم لمستخدم الرد العام.

الدرجة التي تدعمها هذه العائلة

يثبت سجل الدليل الشخصي مباشرة الراحة الدليلية. في عامي 1982 و1985، كان المستخدم المحدد مشاركًا في ARPANET أو DDN يبحث عن شخص أو صندوق بريد أو مؤسسة أو ارتباط مضيف. كان القرار هو أين يوجه رسالة أو استفسار. تضمنت المصادر المنافسة دليل صاحب العمل، حساب المضيف، قائمة الموقع، الاتصال الهاتفي، أو تأكيد من الشخص أو المؤسسة.

لا توثق المصادر المفحوصة هنا حالة قبل عام 1997 حيث قرر وجود معرف NIC شخصي، بمفرده، الاستحقاق القانوني أو السلطة التنظيمية أو التحكم التقني. يمكن أن تدعو ديمومة الحقل إلى تلك الاستدلالات، لكن وظيفتها الموثقة بقيت اكتشافًا.

المضيف والشبكة: سجل جهة الاتصال التشغيلية لـ DDN

ربطت العائلة الثانية الأشخاص بالآلات والشبكات والأدوار التشغيلية المحددة. هنا بدأ السجل يحمل أكثر من مجرد إمكانية الوصول.

من الانتماء إلى واجب التصرف

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

تحدد المصادر المعاصرة تلك المسؤولية. ميزدليل إداريي النطاقات، RFC 1032، بتاريخ نوفمبر 1987، بين إداري النطاق وجهات الاتصال الفنية وجهات اتصال النطاق. كان من المتوقع أن ينسق الإداري النطاق ويديره وأن يمتلك سلطة التصرف أو التفويض. وكانت جهات الاتصال الفنية وجهات اتصال النطاق تحافظ على برامج وبيانات خادم الأسماء وتعمل مع الموظفين الفنيين في أماكن أخرى.

وصفRFC 1173، بتاريخ أغسطس 1990، مسؤوليات مديري المضيفين والشبكات. كان صراحة ملخصًا إعلاميًا لـ "التقاليد الشفهية" للإنترنت، وليس معيارًا من IAB. حتى مع هذا القيد، فإن اختباره الموضوعي كاشف. فقد طلب تسجيل الأفراد المسؤولين عن الشبكات المتصلة لدى NIC المناسب وإبقائهم محدثين. كان من المتوقع أن يمتلك مدير الشبكة صلاحية إدارة النظام أو سلطة تعطيل أو فصل أو إيقاف إعادة توجيه البيانات من نظام مسيء. وبالمثل، كان مدير المضيف بحاجة إلى السلطة والوصول والأدوات اللازمة للتحكم في المضيف.

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

يقدمدليل 2011 لسجلات SRI ARC/NICخريطة استعادية للمجموعة ويحدد المواد المتعلقة بالاتصالات الفنية وإداريي المضيفين ومنسقي مواقع العُقد ومجموعات الاتصال الأخرى. وهو يساعد في تحديد موقع السجلات ذات الصلة؛ ولا يُعامل كدليل معاصر على سبب إنشاء كل دور أو بالضبط ما هي السلطة التي يمتلكها كل حامل. تلك الافتراضات تتطلب وثائق تلك الفترة مثل RFC 1032 وRFC 1173 والتوجيهات ومواد التسجيل والتقارير التشغيلية.

سرد مؤرخ لكيفية صيانة ملفات جهات الاتصال

بقي سجل تشغيلي أكثر دقة في تقرير ماري ك. ستالأوصاف جداول وقوائم NIC، وهو تقرير نهائي بتاريخ 5 أبريل 1991. أعده مركز أنظمة معلومات الشبكة التابع لـ SRI International لوكالة اتصالات الدفاع بموجب العقد DCA200-90-C-0027، مشروع SRI ECU 1050، CDRL رقم 027. يظهر في مجموعة متحف تاريخ الحاسوب بعنوانمواد وكالة اتصالات الدفاع، 9 من 13.

يحدد التقرير عدة مشتقات متميزة بدلاً من ملف WHOIS واحد غير متمايز.

يصف القسم 3.1، في صفحة التقرير 7، ملفات إداريي مضيفي MILNET. تم استخراج بياناتها من قاعدة بيانات WHOIS الخاصة بـ NIC. جاءت المعلومات الأولية من توجيهات تغيير الشبكة، وبعد ذلك كان مضيف NIC يطلب التصحيحات من إداريي المضيفين كل شهر. وكان يُولد الملف المشتق أسبوعيًا.

يصف القسم 3.7، في صفحة التقرير 10، ملفًا ينظم إداريي المضيفين حسب عنوان الشبكة. ويقول بالمثل أن البيانات الأولية جاءت من توجيهات تغيير الشبكة وتم تحديثها من خلال طلبات شهرية للتصحيحات عبر الإنترنت. وكان يُولد الملف أسبوعيًا.

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

بالنسبة لسجلات مضيف وشبكة DDN، يصبح التدقيق أكثر تجسيدًا:

• المقدم والمصدر:يمكن أن تنشأ معلومات المضيف الأولية في توجيهات تغيير الشبكة؛ وجاءت التغييرات اللاحقة من إداريي المضيفين المعترف بهم، أو منسقي مواقع العُقد، أو موظفي الشبكة.
• سلطة التحديث:كان من المتوقع أن يقدم حاملو الأدوار تصحيحات، وكان مضيف NIC يطلبها. لا يحدد التقرير كل اختبار استُخدم عندما ادعى مراسل جديد استبدال حامل دور موجود.
• المصادقة:خلق الدور الثابت وقناة المراسلة ثقة إجرائية، لكن التقرير لا يصف نظامًا موحدًا للتحقق من الهوية أو مصادقة الرسائل لجميع التحديثات.
• التصحيح:وفرت الطلبات الشهرية والتقديمات الطوعية مسارات تصحيح متكررة.
• الاستبدال والوقت الحالي:أظهرت الملفات المجددة أسبوعيًا وإصدارات مستوى الملف دورات نشر، وليس بالضرورة تاريخ سريان كل تغيير تنظيمي خارجي.
• الاحتفاظ التاريخي:يصف التقرير المشتقات الحالية وتوليدها. ولا يثبت تسلسلًا عامًا كاملاً لكل سجل لجهات الاتصال الملغاة والأسباب.
• مراجعة النزاع:شغل مضيف NIC موقعًا تفسيريًا، لكن التقرير لا يصف إجراءً عامًا للفصل بين المطالبين المتنافسين على نفس الدور.
• حد الخصوصية:احتوت بعض المشتقات التشغيلية على بيانات اتصال شخصية ودور واسعة. ولا تُعاد إنتاج هذه التفاصيل هنا.

كان نظام الصيانة منظمًا. ولم يكن مكافئًا لسلسلة أدلة موثقة قابلة للتفتيش العام. يمكن أن يظل السجل الحالي متخلفًا عن تغيير الموظفين دون أن يتصرف أحد بسوء نية.

الاعتماد التشغيلي وإسناد المسؤولية في ديسمبر 1990

يقدم حادث فعلي أوضح حركة قبل عام 1997 تتجاوز الاستخدام الموصوف.

في ورقة قدمت في ندوة USENIX الأمنية لعام 1992،وصف أليساندرو بيرني، باولو فرانكي، وجوي مارينو حوادث أمن الإنترنت في إيطاليا. يذكر سردهم أن موقعين لاحظا محاولات اختراق مرتبطة بشبكة في إيطاليا واتصلا بمركز تنسيق CERT. أثناء الاستجابة، ربطت قاعدة بيانات WHOIS لـ DDN NIC الشبكة بجامعة ميلانو.

يمكن ذكر العناصر الإثباتية دون كشف تفاصيل الاتصال التاريخية:

• التاريخ:ديسمبر 1990، موثق في ورقة 1992.
• الفاعلون:المواقع المتضررة وCERT/CC.
• السجل المستخدم:ارتباط شبكة DDN NIC ومعلومات الاتصال.
• القرار:أي مؤسسة يجب أن تتلقى تقرير الحادث الأولي ويُطلب منها التحقيق قبل أن يفكر المشغلون في عزل الشبكة.
• مصادر الحقيقة المنافسة:سجلات النظام والحزم، معلومات التوجيه، الإدارة الفعلية للجهاز المتورط، السجلات المؤسسية المحلية، والتأكيد المباشر.
• النتيجة:حدد الاستعلام مؤسسة ذات صلة وبدأ الاتصال، لكن لم يتم تحديد مدير الجهاز المسؤول فورًا وظل التواصل صعبًا.

تثبت هذه الحالة الاعتماد التشغيلي. غير السجل ما فعله المستجيبون بعد ذلك: اختار مؤسسة للاتصال بها.

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

أثبتت السجلات الأحداث المرصودة. وقدمت WHOIS ارتباطًا مؤسسيًا. وكان على التحقيق المحلي ربط البيانات بجهاز. وحددت السلطة التنظيمية والوصول التقني من يمكنه التصرف. كان السجل جسرًا بين معرف ومؤسسة، وليس نظام إسناد كامل.

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

المؤسسة والنطاق وجهات الاتصال والخوادم: سجل النطاق

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

المؤسسة والنطاق

أمر RFC 1032 إداري النطاق بتقديم استبيان تسجيل ووصف الإداري بأنه مسؤول عن إبقاء بيانات النطاق حديثة. قال قسم التحقق منه إنه يمكن استخدام WHOIS لمراجعة المؤسسة المرتبطة بالنطاق، واسم النطاق، وجهات الاتصال الإدارية والفنية وجهات اتصال النطاق، وخوادم الأسماء المدرجة.

كان هذا أكثر من مجرد اكتشاف شخصي. لقد كان استخدامًا موصوفًا لـ WHOIS لمقارنة تسجيل مع تكوين النطاق المقصود.

ومع ذلك، قدم RFC 1032 أيضًا دليلاً مضادًا معاصرًا لأي نظرية ملكية. قال إن NIC لن تعمل كحكم في النزاعات المحلية حول من له "الحق" في تسجيل نطاق. وكان من المقرر تسوية هذه النزاعات بين الأطراف قبل التسجيل. يمكن لـ NIC الإجابة عن الأسئلة التقنية لكنها لم تدّعِ الفصل في الحق الأساسي.

لذلك يجب قراءة الحقول بشكل منفصل:

• المؤسسة:الكيان الممثل في طلب التسجيل.
• جهة الاتصال الإدارية:الشخص المسؤول عن تنسيق السياسة أو التنظيم.
• جهات الاتصال الفنية وجهات اتصال النطاق:الأشخاص المسؤولون عن تشغيل خادم الأسماء والبيانات ذات الصلة.
• خوادم الأسماء:الأنظمة المقصود منها الإجابة بشكل موثوق عن النطاق.
• عرض WHOIS:التمثيل المقروء بشريًا للمسجل للحقائق المسجلة.
• تفويض DNS:الوضع التشغيلي للنطاق في نظام التسمية الهرمي.

يمكن مقارنة إجابة WHOIS العامة بطلب وDNS نشط. لكنها لا تستطيع، دون أدلة إضافية، أن تثبت أن جهة الاتصال الإدارية لا تزال تمتلك سلطة مؤسسية أو أن المؤسسة تمتلك كل حق قانوني يتضمنه الاسم.

يؤسس RFC 1032 مستخدمًا وقرارًا معياريين: في نوفمبر 1987، قيل لإداري النطاق أن يفحص WHOIS عند التحقق مما إذا كانت بيانات النطاق ممثلة بشكل صحيح. كانت المصادر المنافسة هي الطلب المقدم، وسجلات النطاق الأعلى، وDNS النشط، والتعيينات التنظيمية. لا يوثق RFC إداريًا معينًا يقوم بهذه المقارنة ويحصل على نتيجة مسجلة. إنه يثبت التحقق التشغيلي المتوقع، وليس حدث اعتماد مكتمل.

تصحيح النطاق في سجل DDN لعام 1991

يعطي تقرير ستال لأبريل 1991 ملف جهات اتصال النطاق مصدرًا محددًا. يقول القسم 3.8، في صفحة التقرير 10، أن المشتقDOMAIN-CONTACTSاستقى معلوماته من طلبات تسجيل النطاق التي عالجها مضيف NIC ومن التصحيحات المقدمة من إداريي النطاقات. تم تخزين البيانات الخام في قاعدة بيانات WHOIS الخاصة بـ NIC، وكان ملف جهات الاتصال يُولد أسبوعيًا.

يميز التقرير أيضًا بين جهات الاتصال الإدارية والفنية وجهات اتصال النطاق. لم تكن هذه الأدوار قابلة للتبديل لمجرد ظهورها معًا.

يدعم التقرير مسار تصحيح محدد لكنه يترك أسئلة أخرى مفتوحة:

• يمكن لإداري نطاق معترف به تقديم تصحيح؛
• عالج مضيف NIC الطلب الأصلي أو التصحيح؛
• يمكن لمشتق أسبوعي جديد أن يكشف الحالة الحالية المتغيرة؛
• لا يذكر التقرير طريقة مصادقة عالمية لكل تصحيح؛
• لا يثبت أن كل مستخدم عام يمكنه استرداد جميع جهات الاتصال الملغاة؛
• لا يصف إجراءً موحدًا للفصل في طلبات التصحيح غير المتوافقة.

هذا دليل على تحول مُدار. وليس دليلاً على أن جهة اتصال إدارية معروضة اكتسبت سلطة قانونية بمجرد عرضها.

سير عمل طلب InterNIC لعام 1993

وثقRFC 1400، بتاريخ مارس 1993، انتقال خدمات التسجيل غير التابعة لـ DDN إلى InterNIC. اعتبارًا من 1 أبريل 1993، كان من المقرر أن يحتوي WHOIS الخاص بـ InterNIC على معلومات عناوين IP والنطاقات وأرقام الأنظمة المستقلة ونقاط الاتصال الفردية المرتبطة بالعُقد النشطة. ولم تعد تغطية الدليل الشخصي العام هي الجمهور الرئيسي لخدمة التسجيل المركزية.

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

حسنت هذه الضوابط الشكل والتوقيت والتتبع، لكن طريقتها مهمة.

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

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

بالنسبة لسير عمل نطاق 1993:

• المصدر:ربط النظام طلبًا ومقدم طلب ونموذجًا محللًا وتذكرة.
• المصادقة:لا يحدد RFC اختبارًا عالميًا مستقلًا للسلطة التنظيمية.
• التصحيح:كان لأخطاء المحلل والتقديمات المرفوضة مسار تصحيح صريح.
• الوقت:وفرت معلومات فتح التذكرة وحقل آخر تحديث علامات زمنية حالية.
• التاريخ:لا تثبت الأمثلة العامة تسلسلًا كاملاً للإصدارات المقدمة وقرارات الموظفين.
• المراجعة:قام موظفو التسجيل بالمعالجة النهائية، لكن RFC لا يحدد الفصل بين مطالبين متنافسين.
• المكانة الإدارية:تثبت الوثيقة مكان مقدم الطلب الأصلي في ذلك الطلب، وليس المكانة المكتسبة من حقل جهة اتصال عامة موجودة.

مقارنة محدودة من RFC 1591

تعلقRFC 1591، بتاريخ مارس 1994، بهيكل DNS وتفويضه. وهو مفيد فقط كمقارنة خاصة بالنطاق.

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

في النزاعات حول حقوق اسم ما، حددت RFC 1591 دور سلطة التسجيل في توفير معلومات الاتصال وقالت إن التسجيل لا يخلق حالة علامة تجارية. كما تصورت المراجعة حيث لا يمكن للأطراف التوصل إلى اتفاق.

كان الفاعلون المؤرخون هم IANA، والمدير الأعلى مستوى، والمنظمات القديمة والجديدة، والأطراف المتأثرة. يمكن لسجل جهة اتصال أن يحدد من يجب الاقتراب منه. واعتمد قرار التفويض على الأداء التشغيلي والاتفاق والمراسلات والمراجعة.

هذه مقارنة داخل DNS. لا يمكنها إثبات ملكية كتلة عنوان IP، ولا تثبت أن كل تغيير نطاق من المستوى الثاني اتبع نفس العملية.

حالة مكانة إدارية مكتملة: CLUE.COM في 1996

نصت سياسة نزاع أسماء النطاقات لشركة Network Solutions في يوليو 1995 على إشعار وخيارات إجرائية للمسجل المسجل عندما تُقدم مطالبة علامة تجارية مؤهلة. الأوصاف اللاحقة لتلك السياسة، بمفردها، تثبت الإجراء بدلاً من الاعتماد المكتمل. وتقدم حالة محددة الأدلة المفقودة.

يصف رأي 1998 فيقضية Oppedahl & Larson ضد Network Solutionsالسجل المحيط بتبني سياسة يوليو 1995. ويحدد اعترافات الأطراف، ومستند السياسة، واستجابة السياسة لتسجيل علامة تجارية فيدرالية معتمدة مطابقة لاسم نطاق مسجل. يمكن للمسجل أن يكتب إلى مسجل النطاق ويقدم خيارات محددة. يؤكد هذا السرد القضائي الإجراء، بينما يسجل أيضًا نزاعات حول تطبيقه على المسجلين الحاليين.

توثق إجراءات قضائية منفصلة ومعاصرة تطبيق السياسة على تسجيل معين. فيقضية Network Solutions, Inc. ضد Clue Computing, Inc.، سجلت المحكمة الجزئية الأمريكية لمنطقة كولورادو أن Clue Computing كانت تحمل تسجيل CLUE.COM الذي تديره Network Solutions وأن Hasbro أكدت مطالبة علامة تجارية منافسة.

في 1 فبراير 1996، أبلغت Network Solutions شركة Clue Computing أن استخدامها للنطاق قد ينتهك علامة Hasbro التجارية. وطالبت المسجل Clue Computing إما بتقديم شهادة علامة تجارية أو قبول تعيين اسم نطاق جديد. لم تظل Clue Computing اسمًا سلبيًا في شاشة عرض. لقد ردت بصفتها المسجل المعترف به، ورفعت دعوى قضائية في محكمة الولاية ضد Network Solutions، وسعت لمنع المسجل من وضع التسجيل قيد الانتظار.

في 25 يونيو 1996، أصدرت محكمة مقاطعة بولدر أمرًا قضائيًا يمنع Network Solutions من تغيير تسجيل واستخدام CLUE.COM. وفي الوقت نفسه، رفعت Network Solutions دعوى تداخل فيدرالية، وقدمت نفسها كطرف مستعد لتعيين التسجيل والاستخدام حسب توجيهات المحكمة. رفضت المحكمة الفيدرالية تلك الدعوى. وخلصت إلى أن الأمر القضائي الحالي للولاية منع Network Solutions من وضع النطاق تحت السيطرة الفيدرالية وأن النزاع يورط أيضًا واجبات Network Solutions التعاقدية تجاه Clue Computing.

العناصر الإثباتية مكتملة بشكل غير عادي:

• التاريخ:إشعار في 1 فبراير 1996، تلته دعوى الولاية، والأمر القضائي في يونيو، والقرار الفيدرالي في 1996.
• الفاعلون:Network Solutions، وClue Computing، وHasbro، ومحكمة مقاطعة بولدر، والمحكمة الجزئية الفيدرالية.
• السجل المعين:تسجيل CLUE.COM في نظام التسجيل الرسمي لـ Network Solutions، بالإضافة إلى ملف نزاع المسجل وتقديم العلامة التجارية المنافسة.
• القرار:ما إذا كان يجب على المسجل المسجل تقديم أدلة مؤهلة، أو قبول اسم بديل، أو مواجهة تعليق، أو الحصول على حماية قضائية.
• مصادر الحقيقة المنافسة:سجل التسجيل، وأدلة علامة Hasbro التجارية، وعلاقة التسجيل، والاستخدام الفعلي، والواجبات التعاقدية، وأوامر المحكمة.
• النتيجة:تلقى المسجل المسجل إشعارًا، ودخل المسابقة الإجرائية، وحصل على أمر قضائي يحفظ التسجيل بينما استمر النزاع؛ تم رفض التداخل الفيدرالي.

تظهر هذه الحالة المكانة الإدارية داخل إجراءات التسجيل الأساسية للمسجل. حدد التسجيل الحالي أي طرف عاملته Network Solutions كمسجل كان استخدامه مهددًا وكان رده مهمًا.

لا تظهر أن Network Solutions حصلت على هوية ذلك الطرف فقط من خلال تشغيل استعلام WHOIS عام. يتحدث الرأي إلى التسجيل الرسمي الذي تديره Network Solutions، وسياسة المسجل، ومراسلاته، والتقاضي الناتج. يمكن لـ WHOIS العامة أن تكشف معلومات التسجيل والاتصال، لكن القضية لا تثبت أن العرض العام خلق الموقف الإجرائي لـ Clue Computing.

كما أن التسجيل لم يقرر مسألة العلامة التجارية النهائية. قدم سجل علامة Hasbro التجارية مطالبة منافسة. اعتمدت Clue Computing على العملية التعاقدية والقضائية. حافظ الأمر القضائي على الوضع الراهن؛ ولم يكن إعلانًا نهائيًا بأن بيانات الاتصال العامة أثبتت الملكية.

لذلك تم إثبات درجة المكانة الإدارية، ولكن مع تأهيل مهم: تم إثباتها لمعاملة المسجل للطرف المسجل في نظام التسجيل الرسمي الخاص به، وليس كقوة تأسيسية عامة لحقول WHOIS العامة.

اصطدام أكتوبر 1995: تحور قاعدة البيانات والتحكم العملي

يعيد سجل الاستئناف الفيدرالي اللاحق فيقضية Kremen ضد Cohenبناء تغيير تسجيل مختلف في أكتوبر 1995.

تلقت Network Solutions خطابًا يدّعي تفويض حذف تسجيل نطاق موجود وتسجيله من قبل طرف آخر. بناءً على الخطاب، حذفت Network Solutions التسجيل السابق من قاعدة بياناتها، وسجلت النطاق لمؤسسة مختلفة، وأدرجت جهة اتصال إدارية جديدة. تبين لاحقًا أن الخطاب مزور. استخدم المسجل الجديد النطاق. وعندما طُلب الاستعادة، طلبت Network Solutions في البداية أمرًا قضائيًا. وأدى التقاضي في النهاية إلى استعادة التسجيل.

كتب الرأي بعد سنوات من المعاملة. إنه دليل على التسلسل المعاد بناؤه والنتائج القضائية، وليس سجل عمليات معاصر.

يجب أن تبقى خمس حقائق منفصلة:

1. قاعدة بيانات التسجيل الرسمية:حذفت Network Solutions تسجيلًا وأدخلت آخر.
2. مخرجات WHOIS العامة:يمكن للاستعلام عرض معلومات مشتقة من نظام التسجيل الحالي، لكن الرأي لا يقول أن استعلامًا عامًا تسبب في التغيير.
3. إجراء التغيير:تصرفت Network Solutions بناءً على الخطاب المقدم.
4. DNS والاستخدام:تبع التسجيل الجديد استخدام عملي للنطاق.
5. الأدلة الوثائقية والقانونية:تعارض التفويض الظاهري مع الموافقة الحقيقية وحُكم لاحقًا بأنه مزور.

كان الفاعل المؤرخ هو Network Solutions. وكان السجل المعين هو إدخال تسجيل النطاق الأساسي الخاص بها، وليس استجابة WHOIS عامة. وكان القرار هو إنهاء تسجيل، والاعتراف بآخر، ثم رفض الاستعادة الإدارية بدون أمر قضائي. وكانت المصادر المنافسة هي الطلب الأصلي، والسلطة التنظيمية الفعلية، والخطاب المتنازع عليه، والشهادة، والنتائج القضائية. وكانت النتيجة تغييرًا فيمن يمكنه استخدام التسجيل في الممارسة العملية، تلته استعادة قضائية لاحقًا.

هذا هو أقوى مثال قبل عام 1997 في المواد المفحوصة هنا لعاقبة شبيهة بالاستحقاق نتجت عن تحور نظام تسجيل رسمي. لقد فعلت عملية قاعدة بيانات المسجل أكثر من مجرد توجيه رسالة بشكل خاطئ؛ لقد غيرت حالة التسجيل التشغيلية والاستخدام العملي.

لا يثبت أن WHOIS العامة نفسها نقلت النطاق، أو منحت الملكية، أو تسببت في تصرف Network Solutions. في أقصى تقدير، كانت الاستجابة العامة ستعكس الحالة المتغيرة بعد المعاملة. حدثت العملية التأسيسية في أنظمة التسجيل الرسمية وإدارة DNS.

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

رقم الشبكة وASN وجهة الاتصال: سجل موارد الأرقام

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

السلف: جهة اتصال شبكة DDN

وصف تقرير ستال لأبريل 1991NETWORK-CONTACTS، وهو ملف مقروء بشريًا لأرقام شبكات الإنترنت المسجلة. يقول القسم 3.10، في صفحة التقرير 11، أن المعلومات جاءت من طلبات تسجيل أرقام الإنترنت التي عالجها مضيف NIC والتصحيحات المقدمة من منسقي الشبكات. تم تخزين البيانات الخام في قاعدة بيانات WHOIS الخاصة بـ NIC. وكان المشتق يُولد أسبوعيًا.

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

لا ينبغي الخلط بين هذا السلف وسجل أنشأه سجل إقليمي لاحق. استمر النسب المؤسسي، لكن مشغل السجل والعملية المحيطة به تغيرا.

مجتمع InterNIC بعد أبريل 1993

وضع RFC 1400 عناوين IP وأرقام الأنظمة المستقلة، مع نقاط الاتصال المرتبطة بها، في خدمة InterNIC بعد الانتقال. وقد أضفى ذلك طابعًا رسميًا على مجتمع متمركز حول الكائن: أصبح الشخص يظهر بشكل متزايد لأن الشخص مرتبط بكائن بنية تحتية مسجل.

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

RWhois كمقارنة تصميمية

اقترحRFC 1714، بتاريخ نوفمبر 1994، بروتوكول WHOIS الإحالي لبيئة سجل موزعة. ميز بين الإجابات الموثوقة والمخزنة مؤقتًا، وحدد مناطق السلطة، واستخدم قيمًا تسلسلية تتغير عندما تتغير البيانات. كما سمح بعمليات التسجيل وتوقع معلومات المصادقة.

تظهر هذه الميزات أن المصممين أدركوا المصدر والسلطة والنسخ والتحور كاهتمامات متميزة. لكنها لا تثبت أن كل تحديث إنتاجي لـ InterNIC أو سجل إقليمي استخدم الآليات المقترحة.

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

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

RFC 2050 وبيانات التسجيل ذات العواقب

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

أعطت الوثيقة ثلاثة أسباب لتلك التقديمات:

• احتياج المشغلين إلى معرفة من كان يستخدم رقم شبكة ومن يجب الاتصال به بخصوص مشاكل تشغيلية أو أمنية؛
• ساعدت معلومات إعادة التعيين في إظهار استخدام تخصيص موجود قبل تبرير مساحة عناوين إضافية؛
• دعمت البيانات دراسات التخصيص.

ذكر RFC 2050 أنه لن يتم تخصيص كتل CIDR إضافية من قبل سجل إقليمي أو مزود رئيسي حتى يتم تقديم ما يقرب من 80 بالمائة من معلومات إعادة التعيين. كما قال إنه يجب على المزودين الاحتفاظ بتبرير موثق للتعيينات وأن الوثائق غير المتاحة يمكن أن تؤثر على التخصيصات المستقبلية.

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

ومع ذلك، لم يختزل RFC 2050 التخصيص إلى صف WHOIS. يمكن للسجل أن يطلب خططًا هندسية، ويفحص التعيينات السابقة، ويتحقق من الاستخدام، ويطلب وثائق تنظيمية، ويدقق في الطلب. وميز بين التخصيصات للمزودين والتعيينات للمؤسسات النهائية. وأوصى بمعاملة عناوين المزودين كقروض مرتبطة بالاتصال وحذر من أن التخصيص لا يضمن قابلية التوجيه. تطلبت التحويلات موافقة السجل الإقليمي بموجب المعايير المطبقة.

لذلك فإن أهمية السجل في الدرجات العليا معيارية وليست خاصة بحالة:

• السياسة المؤرخة:RFC 2050، نوفمبر 1996.
• الفاعلون المسمون في السياسة:السجلات الإقليمية، والسجلات المحلية، والمزودون، والمنظمات الطالبة.
• السجل:بيانات التخصيص والتعيين وإعادة التعيين.
• القرار:الاتصال التشغيلي وما إذا كان الاستخدام المثبت يبرر مساحة عناوين إضافية.
• مصادر الحقيقة المنافسة:تعيينات العملاء، وأدلة الاستخدام، والخطط الهندسية، وجداول التوجيه، وعقود المزودين، والوثائق التنظيمية، ومراسلات السجل.
• العاقبة المحددة:يمكن أن تؤثر معلومات إعادة التعيين أو التبرير غير الكافية على التخصيصات المستقبلية.
• الحد:لا يوثق المصدر ملف تخصيص معين قبل عام 1997 حيث اتخذ سجل مسمى هذا القرار وأكمله.

يثبت RFC 2050 علاقة السياسة بين التسجيل والتخصيص. بدون ملف قضية، لا يثبت مدى اتساق تطبيق القاعدة أو أن مخرجات WHOIS العامة وحدها قررت طلبًا معينًا.

المراجعة والسرية خارج بروتوكول الاستعلام

يقدم RFC 2050 حدين مهمين يمكن أن يفوتهما الحساب المتمركز حول WHOIS.

أولاً، أعطى القسم 6 المنظمة حق استئناف قرار السجل إلى السجل الأعلى. وكان على السجل المخصص أن يوفر الوثائق ذات الصلة. ويمكن أن تستمر الاستئنافات صعودًا في التسلسل الهرمي، وبعد استنفاد السبل الأخرى، إلى IANA لاتخاذ قرار نهائي. وكان من المتوقع أن يوثق كل سجل إجراء الاستئناف الخاص به.

ثانيًا، طالب القسم 4.6 السجل المخصص بمعاملة المعلومات التي يحددها مقدم الطلب على أنها حساسة على أنها سرية. وحيث لا يمكن ضمان الخصوصية، يمكن أن يشارك السجل الأعلى في التعيين.

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

بالنسبة لسجلات موارد الأرقام، فإن التدقيق هو:

• المصدر:قدم المزودون أو السجلات المحلية أو المنظمات الطالبة التعيينات والمواد الداعمة.
• سلطة التحديث:فرض RFC 2050 واجبات تقديم فورية، لكنه لم يحدد طريقة مصادقة تقنية واحدة لكل تحديث.
• المصادقة والتحقق:يمكن للسجلات التدقيق والمطالبة بوثائق مؤيدة؛ السجل العام لم يكشف كل تلك الأدلة.
• التصحيح والاستبدال:يمكن لعملية السجل المحيطة أن تراجع السجلات، لكن RFC 2050 لم يعرف تاريخ إصدار عام عالمي.
• الوقت:كان التقديم الفوري مطلوبًا؛ ولم يكشف الصف العام الحالي بالضرورة تاريخ السريان الكامل.
• المراجعة:سارت الاستئنافات عبر التسلسل الهرمي للسجل ويمكن أن تصل في النهاية إلى IANA.
• الخصوصية:كان للتسجيل مكون تشغيلي عام، بينما كان من المقرر أن تظل المعلومات الحساسة التي يحددها مقدم الطلب سرية.
• الاستحقاق:يمكن أن يؤثر التسجيل على إدارة التخصيص، لكنه لا يضمن قابلية التوجيه ولا يعمل كأداة ملكية كاملة.

مقارنة عائلات السجلات الأربع

أخفت واجهة WHOIS المشتركة حدودًا إثباتية مختلفة.

تمنع هذه المقارنة تاريخين زائفين.

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

الثاني سيبدأ بتحور تسجيل نطاق ذي عواقب ويقرأ قوته إلى الوراء في كل رد WHOIS سابق. وهذا يتجاهل الفرق بين العرض العام والنظام الرسمي القادر على تغيير تسجيل أو تفويض.

السلم، مع كشف حدوده

يمكن الآن اختبار السلم الإثباتي مقابل السلوك المؤرخ بدلاً من أسماء الحقول وحدها.

وصلت إدارة موارد الأرقام إلى درجة عليا ذات صلة لكن أقل توثيقًا في RFC 2050. كانت بيانات التسجيل وإعادة التعيين مدخلات موصوفة لقرارات التخصيص المستقبلية. بدون ملف قضية مكتمل، يبقى ذلك دليل سياسة على عاقبة إدارية متوقعة بدلاً من إثبات أن صفًا عامًا قرر طلبًا معينًا.

النتيجة غير متماثلة. الراحة الدليلية والاعتماد التشغيلي وإسناد المسؤولية مدعومة جيدًا بالمواصفات وحادث مؤرخ. تم إثبات المكانة الإدارية في إجراء مسجل معين يشمل سجل تسجيل نطاق رسمي. تم إثبات العاقبة الشبيهة بالاستحقاق من خلال تحور ذلك النظام الرسمي. لا تظهر الأدلة المتاحة أن WHOIS العامة أصبحت مصدرًا عالميًا للمكانة أو الملكية قبل عام 1997.

من أين جاءت السلطة

لم تكتسب WHOIS قوتها من خلال البروتوكول التقني وحده.

ذكر RFC 812 أن NIC التابعة لـ SRI حافظت على الخدمة نيابة عن وكالة اتصالات الدفاع. يحدد تقرير ستال لأبريل 1991 عقدًا حكوميًا ومقاولًا مسؤولاً ومُسلّمًا وقاعدة بيانات مصدر وملفات مشتقة. يوثق RFC 1400 انتقال الخدمات غير التابعة لـ DDN إلى InterNIC.

يسجلالتاريخ القانوني لمكتب محاسبة الحكومةأن المؤسسة الوطنية للعلوم أبرمت اتفاقية تعاون مع Network Solutions في عام 1993 لتوفير خدمات معلومات موسعة ومنسقة للإنترنت غير العسكري. وشملت تلك الخدمات تسجيل نطاقات المستوى الثاني، بينما تعاونت Network Solutions أيضًا مع USC في إدارة منطقة الجذر.

جاءت السلطة العملية لقاعدة البيانات من تلك التعيينات المؤسسية، وخدمات التسجيل المقدمة بموجبها، واستعداد جهات فاعلة أخرى لمعاملة السجل المحفوظ على أنه حديث. كانت السلطة تكمن في وظيفة المنظمة المعترف بها وقدرتها على التصرف بناءً على قاعدة بياناتها، وليس في بناء جملة استجابة المنفذ 43.

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

كانت SRI-NIC وDDN-NIC وInterNIC وNetwork Solutions وIANA والسجلات الإقليمية مؤسسات مرتبطة، لكنها لم تكن قابلة للتبادل. تغيرت دوائرها الانتخابية ووظائفها المسندة ومواد مصدرها وسجلاتها. لم تضمن استمرارية البيانات أن كل إدخال موروث قد أعيد توثيقه بموجب إجراءات الخلف.

خصوصية محدودة تاريخيًا وتكاليف تصحيح

تدخل الخصوصية هذا التاريخ لأن الحقول الأصلية اختيرت لقابلية الوصول.

خدمة الدليل الشخصي كشفت عمدًا عن معلومات كافية للعثور على الأفراد والاتصال بهم. يمكن أن تكشف ملفات DDN التشغيلية عن حاملي الأدوار وقنوات اتصال واسعة لأن الإداريين عن بعد كانوا بحاجة إلى الوصول إلى شخص قادر على التصرف. ربطت سجلات النطاقات جهات اتصال محددة بوظائف إدارية وتقنية. ربطت سجلات موارد الأرقام معرفات الشبكات بجهات اتصال تشغيلية.

لم يكن التحول التاريخي ببساطة من معلومات خاصة إلى معلومات عامة. بل كان من دليل شخصي يخدم مجتمعًا محدودًا نسبيًا إلى سجلات بنية تحتية تُستشار أثناء الحوادث وتغييرات التسجيل والنزاعات وقرارات التخصيص.

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

يظهر السجل أيضًا تضييقًا في المجتمع. قال RFC 1400 أن سجلات InterNIC الفردية ستغطي بشكل أساسي نقاط الاتصال المرتبطة بالعُقد النشطة، بينما يمكن توزيع مشاريع الدليل الشخصي العامة في أماكن أخرى. بحلول عام 1996، ميز RFC 2050 بين معلومات التسجيل العامة ومواد الطلب الحساسة التي كان مطلوبًا من السجلات أن تحافظ على سريتها عندما يحددها مقدم الطلب على هذا النحو.

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

يمكن أن يفرض تقليل المعلومات العامة أيضًا تكاليف تشغيلية. يظهر حادث ديسمبر 1990 لماذا كان الاستعلام المركزي مهمًا: لقد أعطى المستجيبين عن بعد نقطة انطلاق مؤسسية. لم يكن ضعف السجل ببساطة أنه كشف جهة اتصال. بل كان أن ارتباطًا على مستوى المنظمة يمكن أن يكون أقل دقة مما يتطلبه الحادث.

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

السيناريو المخالف أ: سجلات موثقة ومؤرخة وغير تأسيسية صراحة

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

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

ضمن هذا الحد، كانت الضوابط الأقوى ستحسن عدة قرارات.

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

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

لم يكن الضمان ليحول الدليل إلى نظام ملكية. تثبت المصادقة أن طرفًا محددًا أدلى ببيان. لكنها لا تثبت بالضرورة أن الطرف يمتلك سلطة مؤسسية، أو أن اتفاقًا ظل ساريًا، أو أن علاقة مزود استمرت، أو أن محكمة ستعترف بالاستحقاق المدعى.

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

كان بيان صريح بعدم الحقوق سيوضح النية المؤسسية. قدم RFC 1032 وRFC 1591 بالفعل حدودًا موضوعية ذات صلة برفض التحكيم في الحقوق المحلية أو بفصل التسجيل عن حالة العلامة التجارية. تكرار مثل هذه الحدود في الاستجابة العامة كان ليقلل من الاستدلال المتهاون.

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

السيناريو المخالف ب: لا دليل، بينما تبقى العلاقات الأساسية

الآن أزل الدليل العام مع ترك العقود ومراسلات التخصيص وطلبات التسجيل وعمليات التوجيه وتفويضات DNS والسجلات التنظيمية والسجلات وشبكات الهاتف سليمة.

تبقى قرارات كثيرة ممكنة.

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

الوظيفة المفقودة هي الاكتشاف السريع عبر الحدود المؤسسية.

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

في إدارة النطاق، يمكن أن يظهر DNS خوادم الأسماء العاملة، ويمكن أن تظهر مراسلات التسجيل الطلب الأصلي. بدون دليل مشترك، سيكون العثور على الممثل الإداري أصعب. تشغيل DNS لن يثبت مع ذلك الموافقة التنظيمية.

في نزاع CLUE.COM، كان بإمكان Network Solutions تحديد مسجلها من ملف التسجيل الرسمي والمراسلات حتى لو لم توجد خدمة WHOIS عامة. كان يمكن للمسجل أن يرسل إشعارًا، وكان يمكن للمسجل أن يستحضر العلاجات التعاقدية أو القضائية. يظهر هذا أن المكانة الإدارية في تلك القضية لم تعتمد بشكل فريد على راحة الاستعلام العام.

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

يحدد هذا السيناريو المخالف القيمة المميزة لـ WHOIS: لقد جعلت العلاقات غير المتجانسة قابلة للبحث من معرف. لقد جلبت أول شخص أو منظمة ذات صلة إلى الواجهة.

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

عتبة 1997

يذكرتاريخ ARIN المؤسسيأنها تأسست في ديسمبر 1997 كمنظمة غير ربحية مستقلة تقدم خدمات تسجيل IP في منطقتها. ويؤرختقريرها السنوي لعام 1999افتتاح العمليات في 22 ديسمبر 1997.

قبل ذلك التاريخ، أصبحت عدة افتراضات مدعومة جيدًا:

• يمكن لاستعلام مركزي ربط الأشخاص والمنظمات بمعرفات الإنترنت؛
• كان من المتوقع أن تكون جهات الاتصال الخاصة بالأدوار قابلة للوصول وقادرة على التصرف؛
• استخدم مضيفو الشبكات الطلبات والتوجيهات والإداريين المعترف بهم وتقديمات التصحيح لصيانة السجلات؛
• تم تجديد بعض مشتقات DDN أسبوعيًا ودعمتها طلبات تصحيح شهرية؛
• استخدم المشغلون سجلات جهات اتصال الشبكة لتقرير أين يوجهون تقارير الحوادث؛
• أُمر إداريو النطاقات بمقارنة بيانات WHOIS مع معلومات التسجيل والخادم المقصودة؛
• يمكن لمسجل نطاق مسجل أن يتلقى إشعارًا ويحتل موقعًا إجرائيًا ذا عواقب في نزاع مسجل مكتمل؛
• يمكن أن ينتج عن تحور سجل تسجيل نطاق رسمي عواقب استخدام عملية؛
• كانت بيانات إعادة تعيين موارد الأرقام مدخلات موصوفة للاتصال التشغيلي وإدارة التخصيص اللاحقة؛
• يمكن تدقيق قرارات التخصيص واستئنافها ودعمها بمواد سرية خارج السجل العام.

تبقى عدة افتراضات أقوى غير مثبتة بالأدلة المفحوصة هنا:

• أن كل تحديث شخصي أو مضيف أو نطاق أو مورد أرقام استخدم طريقة موحدة للتحقق من الهوية؛
• أن كل سجل عام كشف تاريخًا كاملاً للقيم السابقة وأسباب التغيير؛
• أن جهة اتصال عامة موجودة امتلكت تلقائيًا سلطة تأكيد أو استبدال تسجيل؛
• أن مقدم الطلب الأصلي لـ RFC 1400 تم الاعتراف به بسبب إدراج جهة اتصال عامة سابقة؛
• أن WHOIS العامة وحدها خلقت المكانة الإدارية لـ Clue Computing في نزاع 1996؛
• أن تغيير تسجيل Kremen كان سببه الاعتماد على استعلام WHOIS عام بدلاً من إجراء تغيير المسجل وتحور قاعدة البيانات؛
• أن صفًا عامًا لمورد أرقام قرر بمفرده طلب تخصيص موثق قبل 1997؛
• أن جهة اتصال مدرجة أثبتت بشكل قاطع التحكم التقني الحالي أو الملكية القانونية أو الاستحقاق التعاقدي؛
• أن تفويض DNS أثبت حقًا في كتلة عنوان IP؛
• أن سجلاً إقليميًا لاحقًا حافظ على سجلات أو ألفها قبل أن يبدأ العمل.

لذلك لم يكن للانتقال من الراحة إلى السلطة تاريخ واحد. حدثت أقوى مراحله في عائلات سجلات مختلفة.

أسست WHOIS الدليل الشخصي اكتشافًا مريحًا. وانتقلت جهات اتصال مضيف وشبكة DDN إلى الاعتماد التشغيلي وإسناد المسؤولية. ويظهر نزاع نطاق مكتمل في 1996 مكانة إدارية مرتبطة بعلاقة التسجيل الرسمية للمسجل، بينما يظهر تسلسل Kremen في 1995 عواقب عملية من تحور ذلك النظام الرسمي. جعلت سياسة موارد الأرقام بيانات التسجيل ذات صلة بقرارات التخصيص المستقبلية مع الاحتفاظ بالوثائق الداعمة والسرية والاستئناف خارج الاستعلام العام.

الدرجات العليا للسلم حقيقية لكنها محدودة الموقع. قبل عام 1997، لا يظهر السجل المتاح أن WHOIS العامة أصبحت أداة ملكية عالمية. إنه يظهر شيئًا أكثر هشاشة وكاشفًا مؤسسيًا: طبقة اتصال مريحة أصبحت أول دليل يُستشار، وأول إطار يوضع حول مشكلة، والانعكاس المرئي لقرارات ذات عواقب لا تزال سلطتها تأتي من قواعد البيانات والإجراءات والعقود والأنظمة التشغيلية والمراجعة خارج نطاق الاستعلام.

المصادر

• RFC 812 — NICNAME/WHOIS، 1 مارس 1982
• RFC 954 — NICNAME/WHOIS، أكتوبر 1985
• RFC 1032 — Domain Administrators Guide، نوفمبر 1987
• RFC 1173 — Responsibilities of Host and Network Managers، أغسطس 1990
• Descriptions of NIC Tables and Lists — SRI International final report، 5 أبريل 1991
• Experiences of Internet Security in Italy — 1992 USENIX Security Symposium
• RFC 1400 — Transition and Modernization of the Internet Registration Service، مارس 1993
• RFC 1591 — Domain Name System Structure and Delegation، مارس 1994
• RFC 1714 — Referral WHOIS Protocol، نوفمبر 1994
• Network Solutions, Inc. v. Clue Computing, Inc. — U.S. District Court for the District of Colorado، 1996
• Oppedahl & Larson v. Network Solutions, Inc. — U.S. District Court for the District of Colorado
• Kremen v. Cohen — U.S. Court of Appeals for the Ninth Circuit
• RFC 2050 — Internet Registry IP Allocation Guidelines، نوفمبر 1996
• Guide to the SRI ARC/NIC Records — Computer History Museum، 2011
• GAO B-327398 — Government legal history of Internet technical functions
• History of ARIN — American Registry for Internet Numbers
• ARIN 1999 Annual Report