ملخص
- عرّف RFC 812 في عام 1982 NICNAME/WHOIS كدليل قابل للقراءة البشرية لتحديد موقع مستخدمي الشبكة. 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، من تأليف Ken Harrenstien و Vic White والمؤرخ في 1 مارس 1982، وصف NICNAME/WHOIS كخادم استعلام واستجابة قائم على المعاملات على آلة SRI-NIC. قدم دليلاً على مستوى الشبكة لمستخدمي ARPANET نيابة عن وكالة الاتصالات الدفاعية. كان المستخدم يرسل سطر أوامر، ويتلقى رداً، ويقطع الاتصال. كان الرد مخصصاً للقراء البشر، وليس للتفسير الآلي.
كانت المجموعة المتوقعة شخصية. طلبت وكالة الاتصالات الدفاعية تسجيل كل شخص لديه دليل على مضيف ARPANET ويمكنه توجيه حركة المرور عبر الشبكة. تضمنت معلومات التسجيل اسماً وبيانات اتصال مؤسسية أو بريدية ورقم هاتف وصندوق بريد شبكي. تظهر هذه الحقول مقدار معلومات الاتصال الشخصية التي كشفها الخدمة؛ لا حاجة لإعادة إنتاج إدخالات حقيقية. وظيفتها الأصلية كانت قابلية الاكتشاف.
RFC 954، من تأليف K. Harrenstien و M. K. Stahl و E. J. Feinler والمؤرخ في أكتوبر 1985، حافظ على المنفذ 43 وهندسة الاستلام والاستجابة لمرة واحدة. وصف الخدمة كدليل لمستخدمي الإنترنت وأوضح مرة أخرى أن مخرجاته قابلة للقراءة البشرية. كانت المجموعة القابلة للبحث أوسع: الأشخاص المسجلون وصناديق البريد ومنظمات الشبكة وعقد DDN والمضيفين المرتبطين ومستخدمي الوصول إلى المحطة الطرفية MILNET المسجلين.
كانت الحقول تخدم بالفعل مهام مختلفة. ساعد الاسم المستخدم في العثور على شخص. ميز المقبض هذا الشخص عن الآخرين ذوي الأسماء المتشابهة وكان بمثابة مرجع قاعدة بيانات قابل لإعادة الاستخدام. قدمت المنظمة انتماءً. قدمت حقول صندوق البريد والهاتف قنوات اتصال. وضعت تعيينات المضيف والعقد شخصاً داخل عمليات الشبكة.
لم يذكر أي من هذه البيانات بمفرده أن الشخص لا يزال موظفاً في المنظمة، أو يمكنه إلزامها، أو يتحكم في كل نظام معين، أو لديه مطالبة قانونية أو تعاقدية على معرف إنترنت.
الفرق بين الدليل ونظام الإثبات يكمن جزئياً في ما يحيط بالحقول المعروضة. نظام الإثبات يطرح أسئلة حول الأصل، والتفويض لتقديم الطلب، والمصادقة، وتواريخ الصلاحية، والإصدارات المستبدلة، والتصحيحات المتنازع عليها، وأسباب التغيير، والتدقيق. RFC 812 و RFC 954 حددا خدمة الاستعلام العامة. لم يحددا مسار تدقيق عام يجيب على هذه الأسئلة.
لا ينبغي المبالغة في تقدير هذا الغياب. وثيقة بروتوكول ليست دليل تشغيل كامل. عدم وجود قاعدة مصادقة في مواصفة الاستعلام لا يثبت أن موظفي NIC قبلوا كل تحديث دون مراسلات أو تحقق هاتفي أو علاقات موقع راسخة أو حكم بشري. إنه يثبت شيئاً أضيق: لم يتلق متلقي الرد العام تمثيلاً موحداً لمن قدم كل حقل، وكيف تم التحقق من سلطة ذلك الشخص، وما القيم السابقة التي تم استبدالها، أو ما إذا كان طرف آخر يعترض على السجل الحالي.
لذا يجب أن تظل خمسة مكونات منفصلة:
- قاعدة بيانات التسجيل أو التعريف الأساسية للمؤسسة؛
- استجابة WHOIS العامة المولدة من تلك القاعدة؛
- الإجراء الذي تمت به إضافة أو تعديل أو حذف التسجيل أو جهة الاتصال؛
- الأنظمة التشغيلية المرتبطة بالمعرف، بما في ذلك إدارة المضيف والتوجيه وتفويض DNS؛
- العقود ومراسلات التخصيص والتعيينات التنظيمية والموافقات والسجلات القانونية خارج قاعدة البيانات.
خلط هذه الطبقات يجعل الاستعلام العام يبدو أكثر قوة مما تسمح به الأدلة التاريخية. يمكن لاستجابة WHOIS وصف تسجيل. يمكن لمعاملة تسجيل تغيير قاعدة البيانات الموثوقة لسجل. يمكن لتغيير تشغيلي منفصل تغيير خدمة DNS أو استخدام الشبكة. يمكن لمحكمة أو سجل أن تقرر لاحقاً ما إذا كانت المعاملة صالحة. كانت هذه أحداثاً ذات صلة ولكنها ليست حدثاً واحداً.
سلم الأدلة الذي تم بحثه هنا هو:
راحة الدليل -> الاعتماد التشغيلي -> إسناد المسؤولية -> الأهلية الإدارية -> استنتاج يشبه المطالبة
كل خطوة لأعلى تتطلب أكثر من مجرد مواصفة تظهر أن حقلاً موجوداً. تتطلب فاعلاً مؤرخاً وسجلاً محدداً وقراراً ومصدر حقيقة متنافساً ونتيجة قابلة للملاحظة. إذا كان الأرشيف يوفر فقط إجراءً منصوصاً عليه، يجب أن يظل الاستنتاج توقعاً موثقاً وليس فعلاً مكتملاً من الاعتماد.
الاسم والمقبض: إدخال الدليل الشخصي
عائلة السجلات الأولى كانت دليلاً للأشخاص.
ما فائدة الحقول
حقل الاسم أجاب على أبسط سؤال: أي شخص نبحث عنه؟ جعل المقبض هذه الإجابة أكثر استقراراً داخل قاعدة البيانات. يمكن للمستخدم البحث على نطاق واسع ثم اختيار إدخال معين من خلال مقبضه. يمكن للسجلات الأخرى الرجوع إلى المقبض دون إعادة إنتاج كل حقل اتصال.
كان هذا إنجازاً تقنياً مهماً. الأسماء ليست فريدة، والمختصرات تختلف، والانتماءات التنظيمية تتغير. المعرف الدائم قلل الغموض داخل سجلات NIC. كان مؤشراً قوياً على صف قاعدة البيانات الذي اختاره المستخدم.
لكنه لم يكن دليلاً على الهوية. RFC 812 و RFC 954 لم يصفا إثبات هوية مستندي، ولا توقيعاً مرتبطاً بالمقبض، ولا سلطة خارجية تؤكد كل انتماء. المقبض أنشأ استمرارية في قاعدة البيانات بشكل أوضح من استمرارية توظيف الشخص أو مسؤولياته أو أهليته القانونية للتصرف.
حقل المنظمة كان وصفياً بالمثل. ساعد في التمييز بين الأشخاص وأشار إلى أين يمكن العثور عليهم. يمكن أن يُظهر السجل انتماء مؤسسياً صحيحاً في وقت الإدخال ويصبح قديماً بعد تغيير الوظيفة أو إعادة الهيكلة أو المغادرة. لم يحتوي الحقل على عقد عمل أو تفويض بالسلطة.
التقديم والتحديث والمصادقة
وجه RFC 812 الأشخاص لإرسال معلومات التسجيل إلى NIC. استخدم RFC 954 قناة مسجل للتقديمات المماثلة. تحدد المواصفات الموضوع المتوقع والهدف من المعلومات، لكنها لا تصف بروتوكول تحديث موثقاً منفصلاً.
المواصفات الباقية تسمح بالفحص المحدود التالي:
- مقدم الطلب والأصل:جاءت المعلومات من شخص أراد أو كان مطلوباً منه التسجيل.
- صلاحية التحديث:لا تذكر RFCs قاعدة شاملة لمن يمكنه استبدال إدخال شخص موجود.
- المصادقة:لا توجد طريقة موحدة للتحقق من الهوية منصوص عليها في وثائق البروتوكول العامة.
- التصحيح:كانت هناك قنوات دعم وتسجيل، لكن RFCs لا تصف إجراءً للتعامل مع التصحيحات المتنازع عليها.
- الاستبدال والوقت الحالي:أعطى الرد العام الاستجابة الحالية لقاعدة البيانات؛ لا تحدد المواصفات تاريخ صلاحية لكل سجل.
- الاحتفاظ التاريخي:لا يوجد تسلسل عام للقيم السابقة منصوص عليه.
- فحص النزاع:لا توضح RFCs كيف سيقرر الموظفون بين المطالبات غير المتوافقة بخصوص نفس الإدخال الشخصي.
- حد الخصوصية:تم الكشف عن معلومات الاتصال الشخصية عن قصد لأن قابلية اكتشاف الشخص كانت الغرض الأصلي من الخدمة.
غير معروف لا يعني غير موجود. ربما قدمت المراسلات الداخلية أو الممارسة الشخصية ضوابط لم توثقها RFCs. النتيجة المعقولة هي أن هذه الضوابط لم تكن جزءاً من الأدلة المقدمة لمستخدم الرد العام.
المستوى الذي تدعمه هذه العائلة
إدخال الدليل الشخصي يؤسس مباشرة راحة الدليل. في 1982 و 1985، كان المستخدم المحدد مشاركاً في ARPANET أو DDN يبحث عن شخص أو صندوق بريد أو منظمة أو تعيين مضيف. كان القرار هو إلى أين يتم توجيه الرسالة أو الطلب. كانت المصادر المتنافسة هي دليل صاحب العمل، أو حساب المضيف، أو قائمة الموقع، أو الاتصال الهاتفي، أو تأكيد الشخص أو المؤسسة.
المصادر التي تم بحثها هنا لا توثق أي حالة قبل عام 1997 حيث قرر وجود مقبض NIC شخصي وحده المطالبات القانونية أو السلطة التنظيمية أو التحكم التقني. ديمومة الحقل يمكن أن توحي بمثل هذه الاستنتاجات، لكن وظيفته الموثقة ظلت قابلة للاكتشاف.
المضيف والشبكة: سجل اتصال تشغيل DDN
العائلة الثانية ربطت الأشخاص بالآلات والشبكات والأدوار التشغيلية المحددة. هنا بدأ السجل يحمل أكثر من مجرد إمكانية الوصول.
من الانتماء إلى واجب العمل
مشغل بعيد يواجه عطلاً أو حادثة أمنية لا يحتاج فقط إلى اسم شخص في مؤسسة. يحتاج إلى شخص يمكنه التحقيق في مضيف، أو تغيير تكوين، أو فصل نظام، أو توجيه موظفين محليين للقيام بذلك.
المصادر المعاصرة تحدد هذه المسؤولية.دليل مسؤولي النطاق، RFC 1032، من نوفمبر 1987 ميز مسؤول النطاق عن جهات الاتصال التقنية والمنطقة. كان المسؤول مسؤولاً عن تنسيق النطاق وإدارته وامتلاك سلطة التصرف أو التفويض. جهات الاتصال التقنية والمنطقة قامت بصيانة برمجيات وبيانات خادم الأسماء والعمل مع الموظفين التقنيين في مواقع أخرى.
RFC 1173من أغسطس 1990 وصف مسؤوليات مديري المضيف والشبكة. كان صراحة ملخصاً غير رسمي للتقاليد الشفهية للإنترنت، وليس معيار IAB. حتى مع هذا القيد، فإن فحصه الموضوعي مفيد. طلب من الأشخاص المسؤولين عن الشبكات المتصلة أن يكونوا مسجلين لدى NIC المختص ويتم تحديثهم. من المتوقع أن يكون مدير الشبكة لديه وصول إلى إدارة النظام أو سلطة تعطيل نظام معطل أو فصله أو منع توجيه حركة المرور. بالمثل، يحتاج مدير المضيف إلى السلطة والوصول والأدوات اللازمة للتحكم في المضيف.
السجل والواقع الخارجي كانا مرتبطين لكنهما ليسا متطابقين. السجل يسمي الشخص. الصلاحيات الفعلية والوصول المادي وسلطة صاحب العمل والتعاون المحلي هي التي تحدد ما إذا كان هذا الشخص يمكنه أداء الدور.
دليل سجلات SRI ARC/NIC لعام 2011يقدم رسم خرائط استعادي للمجموعة، ويحدد المواد الخاصة بالاتصالات التقنية ومسؤولي المضيف ومنسقي مواقع العقد ومجموعات الاتصال الأخرى. يساعد في تحديد موقع السجلات ذات الصلة؛ لا يتم التعامل معه كدليل معاصر على سبب إنشاء كل دور أو السلطة الدقيقة التي يمتلكها كل شاغر. هذه التصريحات تتطلب وثائق معاصرة مثل 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. تم استخراج بياناتها من قاعدة بيانات NIC WHOIS. جاءت المعلومات الأولية من توجيهات تغيير الشبكة، وبعد ذلك طلب مضيف NIC الشهري تصحيحات من مسؤولي المضيف. تم إنشاء الملف المشتق أسبوعياً.
القسم 3.7 في صفحة 10 من التقرير يصف ملفاً يرتب مسؤولي المضيف حسب عنوان الشبكة. مرة أخرى، ينص على أن المعلومات الأولية جاءت من توجيهات تغيير الشبكة وتم الحفاظ عليها محدثة من خلال طلبات التصحيح الشهرية عبر الإنترنت. تم إنشاء الملف أسبوعياً.
يواصل التقرير ذكر أن الملفات والجداول على مستوى الملف تحمل رقم إصدار أو تاريخ آخر تحديث. قدم ذلك معلومات زمنية مفيدة: يمكن للمستخدم تحديد جيل معين منشور. لكنه لم يقدم بالضرورة تاريخاً عاماً لجميع القيم السابقة لكل اتصال.
لسجلات مضيف DDN والشبكة، يصبح الفحص أكثر تحديداً:
- مقدم الطلب والأصل:معلومات المضيف الأولية يمكن أن تأتي من توجيهات تغيير الشبكة؛ التغييرات اللاحقة جاءت من مسؤولي المضيف المعترف بهم أو منسقي مواقع العقد أو موظفي الشبكة.
- صلاحية التحديث:كان من المتوقع أن يقدم شاغلو الدور تصحيحات، ويطلبها مضيف الاستضافة. لا يحدد التقرير كل اختبار تم تطبيقه عندما يدعي مراسل جديد أنه يحل محل شاغل دور موجود.
- المصادقة:دور راسخ وقناة مراسلات خلقت ثقة إجرائية، لكن التقرير لا يصف نظاماً موحداً للتحقق من الهوية أو مصادقة الرسائل لجميع التحديثات.
- التصحيح:الطلبات الشهرية والتقديمات الطوعية قدمت طرق تصحيح متكررة.
- الاستبدال والوقت الحالي:الملفات المعاد إنشاؤها أسبوعياً والإصدارات المتعلقة بالملف أظهرت دورات النشر، وليس بالضرورة تاريخ سريان كل تغيير تنظيمي خارجي.
- الاحتفاظ التاريخي:يصف التقرير المشتقات الحالية وتوليدها. لا يؤسس تاريخاً عاماً كاملاً لكل سجل لجهات الاتصال المستبدلة والأسباب.
- فحص النزاع:اتخذ مضيف الاستضافة موقفاً تفسيرياً، لكن التقرير لا يصف إجراءً عاماً للتحكيم للمطالبين المتنافسين على نفس الدور.
- حد الخصوصية:بعض المشتقات التشغيلية احتوت على بيانات اتصال شخصية ومتعلقة بالدور. لا يتم إعادة إنتاج هذه التفاصيل هنا.
كان نظام الصيانة منظمًا. لم يكن سلسلة أدلة موثقة متاحة للجمهور. يمكن أن يظل السجل الحالي متخلفاً عن تغيير الموظفين دون أن يتصرف أحد بشكل غير شريف.
الاعتماد التشغيلي وإسناد المسؤولية في ديسمبر 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، وتم إنشاء ملف الاتصال أسبوعياً.
يميز التقرير كذلك بين جهات الاتصال الإدارية والتقنية والمنطقة. لم تكن هذه الأدوار قابلة للتبديل لمجرد ظهورها معاً.
يدعم التقرير طريق تصحيح محدد لكنه يترك أسئلة أخرى مفتوحة:
- مسؤول نطاق معترف به يمكنه تقديم تصحيح؛
- مضيف الاستضافة قام بمعالجة الطلب الأصلي أو التصحيح؛
- اشتقاق أسبوعي جديد يمكن أن يكشف الحالة الحالية المعدلة؛
- التقرير لا يذكر طريقة مصادقة عالمية لكل تصحيح؛
- لا يؤسس أن كل مستخدم عام يمكنه استرداد جميع جهات الاتصال المستبدلة؛
- لا يصف إجراءً موحداً لتقرير في طلبات التصحيح غير المتوافقة.
هذا دليل على طفرة موجهة. إنه ليس دليلاً على أن جهة اتصال إدارية معروضة اكتسبت سلطة قانونية بمجرد العرض.
سير عمل طلب InterNIC لعام 1993
RFC 1400من مارس 1993 وثق انتقال خدمات التسجيل غير DDN إلى InterNIC. اعتباراً من 1 أبريل 1993، كان من المفترض أن يحتوي InterNIC على معلومات WHOIS حول عناوين 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 v. Network Solutionsيصف خلفية اعتماد سياسة يوليو 1995. يحدد إقرارات الأطراف، ومعروض السياسة، واستجابة السياسة لتسجيل علامة تجارية اتحادية معتمدة تطابق اسم نطاق مسجلاً. يمكن للسجل أن يكتب لمالك النطاق ويقدم خيارات معينة. هذا العرض القضائي يؤكد الإجراء بينما يوثق أيضاً النزاعات حول تطبيقه على المالكين الحاليين.
دعوى قضائية منفصلة معاصرة توثق تطبيق السياسة على تسجيل معين. فيNetwork Solutions, Inc. v. 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 v. Cohenيعيد بناء تغيير تسجيل آخر من أكتوبر 1995.
تلقت Network Solutions خطاباً يفيد بأنه يأذن بحذف تسجيل نطاق موجود وتسجيله من قبل طرف آخر. بناءً على الخطاب، حذفت Network Solutions التسجيل السابق من قاعدة بياناتها، وسجلت النطاق لمنظمة أخرى، وأدرجت جهة اتصال إدارية جديدة. تبين لاحقاً أن الخطاب مزور. استخدم المالك الجديد النطاق. عندما طُلب الاستعادة، طلبت Network Solutions في البداية أمراً قضائياً. أدى النزاع القانوني في النهاية إلى استعادة التسجيل.
تم كتابة الحكم بعد سنوات من المعاملة. إنه دليل على التسلسل المعاد بناؤه والنتائج القضائية، وليس سجل تشغيلي معاصر.
يجب أن تظل خمس حقائق منفصلة:
- قاعدة بيانات التسجيل الموثوقة:حذفت Network Solutions تسجيلاً وأدخلت آخر.
- مخرجات WHOIS العامة:استعلام يمكن أن يعرض معلومات مشتقة من نظام التسجيل الحالي، لكن الحكم لا ينص على أن استعلاماً عاماً تسبب في التغيير.
- إجراء التغيير:تصرفت Network Solutions بناءً على الخطاب المقدم.
- DNS والاستخدام:التسجيل الجديد تبعه استخدام فعلي للنطاق.
- الأدلة الوثائقية والقانونية:التفويض الظاهري تناقض مع الموافقة الحقيقية وتم تقييمه لاحقاً كتزوير.
الفاعل المؤرخ كان Network Solutions. السجل المحدد كان إدخال تسجيل النطاق الأساسي الخاص به، وليس استجابة WHOIS عامة. القرار كان إنهاء تسجيل، والاعتراف بآخر، ثم رفض الاستعادة الإدارية دون أمر قضائي. المصادر المتنافسة كانت الطلب الأصلي، السلطة التنظيمية الفعلية، الخطاب المتنازع عليه، الشهادة، والنتائج القضائية. النتيجة كانت تغييراً في من يمكنه استخدام التسجيل عملياً، متبوعاً باستعادة قضائية لاحقة.
هذا هو أقوى مثال قبل عام 1997 في المواد التي تم بحثها هنا لعواقب شبيهة بالمطالبة ناتجة عن طفرة في نظام تسجيل موثوق. عملية قاعدة بيانات السجل فعلت أكثر من مجرد توجيه رسالة خاطئة؛ غيرت حالة التسجيل التشغيلية والاستخدام العملي.
لا يثبت أن استعلام WHOIS العام نفسه نقل النطاق، أو منح ملكية، أو دفع Network Solutions للتصرف. في أحسن الأحوال، يمكن لاستجابة عامة أن تعكس الحالة المعدلة بعد المعاملة. العملية التأسيسية حدثت في نظام التسجيل الموثوق وإدارة DNS.
وبالمثل، لا تثبت القضية أن كل إجراء تحديث مبكر كان غير موثق أو غير موثوق. إنها توثق خطأً ذا عواقب مع تعليمات مزورة. التعميم من ذلك سيكون مبالغاً فيه.
رقم الشبكة، ASN وجهة الاتصال: سجل موارد الأرقام
العائلة الرابعة تطورت تحت ضغوط مختلفة: ندرة العناوين، توسع التوجيه، التفويض للمزودين والسجلات الإقليمية، والحاجة إلى تحديد الشبكات أثناء الحوادث التشغيلية.
سابق اتصال شبكة DDN
تقرير ستال في أبريل 1991 وصفNETWORK-CONTACTS، وهو ملف قابل للقراءة البشرية لأرقام شبكات الإنترنت المسجلة. القسم 3.10 في صفحة 11 ينص على أن المعلومات جاءت من طلبات تسجيل أرقام الإنترنت التي تمت معالجتها من قبل مضيف الاستضافة ومن التصحيحات المقدمة من منسقي الشبكة. تم تخزين البيانات الخام في قاعدة بيانات NIC WHOIS. تم إنشاء المشتق أسبوعياً.
ملف الاتصال ربط رقم شبكة واسم شبكة بجهة اتصال ومقبض 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 المشتركة أخفت حدود إثبات مختلفة.
| عائلة السجلات | الموضوع الأساسي | أقوى استخدام مثبت قبل 1997 | أدلة التغيير والتصحيح | حدود التاريخ والمراجعة |
|---|---|---|---|---|
| دليل شخصي WHOIS | شخص وقنوات اتصال | راحة الدليل | معلومات التسجيل المرسلة إلى NIC؛ لا يوجد قاعدة مصادقة تحديث عامة شاملة في RFC 812 أو RFC 954 | لا يوجد تاريخ إصدار عام محدد لكل سجل أو تدقيق للهويات المتنازع عليها |
| اتصالات مضيف وشبكة DDN | مضيفون وشبكات وأدوار تشغيلية مسؤولة | اعتماد تشغيلي وإسناد مسؤولية محدود | تعليمات الشبكة، طلبات تصحيح شهرية، تحديثات طوعية، ومشتقات مولدة أسبوعياً، موثقة في تقرير أبريل 1991 | الإصدارات على مستوى الملف لم تكشف بالضرورة كل حقل مستبدل أو قرار نزاع |
| تسجيل النطاق وWHOIS | منظمة ونطاق وجهات اتصال وخوادم أسماء | تحقق منصوص عليه؛ أهلية إدارية مكتملة في إجراء التسجيل الأساسي لمسجل في 1996؛ عواقب عملية من طفرة قاعدة بيانات موثوقة في 1995 | طلبات النطاق وتصحيحات؛ تحقق محلل في 1993 من قبل مقدم الطلب الأصلي؛ سياسة السجل ومراسلاته | لا دليل على أن WHOIS العام وحده أذن بتغييرات أو خلق أهلية أو حسم مطالبات؛ النزاعات اعتمدت على اتفاقات وأدلة علامات تجارية وDNS ومراسلات ومحاكم |
| تسجيل موارد الأرقام | أرقام شبكات، ASNs، تخصيصات، تعيينات، وجهات اتصال | اتصال تشغيلي وتأثير قائم على السياسة على التخصيصات الإضافية | طلبات التسجيل، تصحيحات المنسقين، التزامات إعادة التخصيص في الوقت المناسب، المراجعات، والوثائق الداعمة | لا توجد حالة محددة قبل 1997 تظهر أن سطراً عاماً حسم تخصيصاً؛ الأدلة السرية والمبررات والإصدارات السابقة ووثائق التظلم يمكن أن تبقى خارج الاستعلام |
هذه المقارنة تمنع تاريخين زائفين.
الأول سيبدأ بالدليل الشخصي لعام 1982 ويعامل كل كائن تسجيل لاحق كنسخة موسعة من نفس سطر إدخال دليل الهاتف. هذا يتجاهل الواجبات المتميزة التي حملها مديرو المضيف ومسؤولو النطاق والمالكون والمزودون وجهات اتصال الموارد.
الثاني سيبدأ بطفرة تسجيل نطاق ذات عواقب ويعرض قوتها إلى الوراء على كل استجابة WHOIS سابقة. هذا يتجاهل الفرق بين عرض عام والنظام الموثوق القادر على تغيير تسجيل أو تفويض.
السلم، مع حدوده المكشوفة
يمكن الآن فحص سلم الأدلة بناءً على السلوك المؤرخ، وليس فقط أسماء الحقول.
| المستوى | فاعل مؤرخ وسجل | القرار | مصدر الحقيقة المتنافسة | النتيجة والحد |
|---|---|---|---|---|
| راحة الدليل | مستخدمو ARPANET وDDN، الموصوفون في RFC 812 (1982) وRFC 954 (1985)، الذين استعلموا عن الإدخالات الشخصية والتنظيمية | بمن نتواصل أو أي إدخال يطابق اسماً | أدلة أصحاب العمل، حسابات المضيف، قوائم المواقع، التأكيد المباشر | قدم الخدمة نقطة بداية قابلة للقراءة البشرية؛ لا تظهر عواقب مطالبة |
| الاعتماد التشغيلي | المواقع المتأثرة وCERT/CC في الحادثة الإيطالية في ديسمبر 1990، باستخدام سجل شبكة DDN-NIC | أي مؤسسة يجب الاتصال بها بشأن حركة المرور الملاحظة | السجلات، معلومات التوجيه، الإدارة المحلية، التحقيق المباشر | الاستعلام وجه الاستجابة إلى مؤسسة |
| إسناد المسؤولية | نفس المستجيبين، باستخدام تعيين الشبكة إلى المنظمة | أي منظمة يجب أن تحقق وتتصرف | التحكم الفعلي في الآلة والسلطة المؤسسية | أُسندت المسؤولية على مستوى الشبكة أو المؤسسة، وليس نهائياً لمسؤول آلة أو مستخدم |
| الأهلية الإدارية | Network Solutions في 1 فبراير 1996، باستخدام تسجيل CLUE.COM وملف النزاع لإخطار Clue Computing | أي مالك مسجل يجب أن يستجيب لمطالبة العلامة التجارية ويمكنه الطعن في تعليق أو تغيير مهدد | أدلة العلامات التجارية، علاقة التسجيل، الاستخدام الفعلي، الالتزامات التعاقدية، أوامر المحكمة | تلقى المالك المسجل إخطاراً، وقاضى، وحصل على أمر قضائي؛ WHOIS العام وحده لم يخلق هذه الأهلية كما هو موثق |
| استنتاج يشبه المطالبة | Network Solutions في أكتوبر 1995، عندما غيرت قاعدة بيانات تسجيل النطاق الموثوقة الخاصة بها بعد تفويض مزعوم | ما إذا كان سيتم إنهاء تسجيل وإنشاء آخر واستعادة الحالة الأصلية لاحقاً | السلطة الفعلية، المراسلات الأصلية، الخطاب المتنازع عليه، الشهادة، النتائج القضائية | طفرة قاعدة البيانات تتبعت عواقب استخدام عملية؛ القضية لا تظهر أن استعلام WHOIS عام تسبب في التغيير |
إدارة موارد الأرقام وصلت إلى مستوى أعلى مرتبط ولكن أقل توثيقاً بشكل كامل في RFC 2050. كانت بيانات التسجيل وإعادة التخصيص مدخلات منصوصاً عليها لقرارات التخصيص المستقبلية. بدون ملف حالة مكتمل، يبقى هذا دليل سياسة على العاقبة الإدارية المتوقعة وليس دليلاً على أن سطراً عاماً حسم طلباً معيناً.
النتيجة غير متماثلة. راحة الدليل والاعتماد التشغيلي وإسناد المسؤولية مدعومة جيداً بالمواصفات وحادثة مؤرخة. الأهلية الإدارية موضحة في إجراء مسجل محدد بسجل تسجيل نطاق موثوق. العاقبة الشبيهة بالمطالبة موضحة من خلال طفرة ذلك النظام الموثوق. الأدلة المتاحة لا تظهر أن WHOIS العام أصبح مصدراً عالمياً للأهلية أو المطالبات القانونية قبل عام 1997.
من أين أتت السلطة
لم يكتسب WHOIS قوته من خلال البروتوكول التقني وحده.
ذكر RFC 812 أن NIC من SRI تدير الخدمة نيابة عن وكالة الاتصالات الدفاعية. تقرير ستال في أبريل 1991 يحدد عقداً حكومياً، والمقاول المسؤول، وتسليم العمل، وقاعدة البيانات المصدر، والملفات المشتقة. RFC 1400 يوثق انتقال خدمات غير DDN إلى InterNIC.
التاريخ القانوني لمكتب المساءلة الحكوميةيسجل أن المؤسسة الوطنية للعلوم دخلت في اتفاقية تعاون مع Network Solutions في عام 1993 لتوفير خدمات معلومات موسعة ومنسقة للإنترنت غير العسكري. تضمنت هذه الخدمات تسجيل النطاق من المستوى الثاني بينما عملت Network Solutions أيضاً مع USC في إدارة المنطقة الجذرية.
السلطة العملية لقاعدة البيانات جاءت من هذه التعيينات المؤسسية، وخدمات التسجيل المقدمة تحتها، واستعداد الفاعلين الآخرين لمعاملة السجل المُدار على أنه حالي. كانت السلطة في الوظيفة المعترف بها لمنظمة وقدرتها على العمل على قاعدة بياناتها، وليس في صياغة استجابة المنفذ 43.
تاريخ GAO يحتوي أيضاً على تحذير إثباتي. يصف استنتاجاته على أنها محدودة بسجل غير كامل، مشيراً إلى أن وثائق العقد الهامة من السبعينيات إلى التسعينيات لم يمكن الحصول عليها. الاتفاقيات والتقارير الباقية تضع الخدمات ضمن التمويل الفيدرالي وأداء المقاولين. لا تدعم الادعاء الواسع بأن العقد حول كل حقل اتصال إلى سند ملكية.
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 — دليل مسؤولي النطاق، نوفمبر 1987
- RFC 1173 — مسؤوليات مديري المضيف والشبكة، أغسطس 1990
- أوصاف جداول وقوائم NIC — تقرير SRI International النهائي، 5 أبريل 1991
- تجارب أمن الإنترنت في إيطاليا — ندوة USENIX للأمن 1992
- RFC 1400 — انتقال وتحديث خدمة تسجيل الإنترنت، مارس 1993
- RFC 1591 — هيكل نظام أسماء النطاقات والتفويض، مارس 1994
- RFC 1714 — بروتوكول WHOIS بالإحالة، نوفمبر 1994
- Network Solutions, Inc. v. Clue Computing, Inc. — محكمة المقاطعة الأمريكية لمقاطعة كولورادو، 1996
- Oppedahl & Larson v. Network Solutions, Inc. — محكمة المقاطعة الأمريكية لمقاطعة كولورادو
- Kremen v. Cohen — محكمة الاستئناف الأمريكية للدائرة التاسعة
- RFC 2050 — إرشادات تخصيص عناوين IP لسجل الإنترنت، نوفمبر 1996
- دليل سجلات SRI ARC/NIC — متحف تاريخ الحاسوب، 2011
- GAO B-327398 — التاريخ القانوني للوظائف التقنية للإنترنت عبر الحكومة
- تاريخ ARIN — السجل الأمريكي لأرقام الإنترنت
- التقرير السنوي لـ ARIN 1999

