الخلاصة

  • احتفظ برنامج ZONE في RFC 1296 بقائمة نطاقات وخوادم، واختبر SOA قبل أن يطلب AXFR، ثم بنى جدولاً من سجلات DNS التي وصلت إليه. وكان «المضيف» تجميعاً لـ [name(s), IP-address(es)]، لا آلة اختُبر اتصالها من الشبكة العامة.
  • الامتناع عن نقل المناطق، وفشل النقل، والمضيفات غير المسجلة في DNS أنقصت ما رآه البرنامج؛ أما الإدخالات العشوائية أو المعيبة وبقايا إعادة التسمية فقد تزيده. وبعد مراجعة يدوية وصف الكاتب بيانات ZONE بأنها حد أدنى لعدد المضيفات، لا العدد الحقيقي ولا مقياس قابلية الوصول.

يُقرأ RFC 1296، Internet Growth (1981-1991) أحياناً كما لو كان جدولاً زمنياً بسيطاً. وهو، عند القراءة الدقيقة، وصف لعقد دليل: ما هي الإشارة التي يستطيع مجمّع أن يلتقطها، وما هي الأبواب التي لا يستطيع فتحها، وما الذي لا يجوز أن يُنسب إلى الإشارة بعد ذلك. تهم هذه الدقة لأن كلمة واحدة مثل «حجم الإنترنت» تجمع في ظاهرها أسئلة متباينة: هل المقصود أسماء منشورة؟ عناوين مضيفة؟ أجهزة يمكن الوصول إليها مباشرة؟ نطاقات إدارية؟ أو سكان الشبكة بوصفهم مجموعة اجتماعية أو تشغيلية؟

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

من سجلات الأسماء إلى جدول، لا من الشبكة إلى سكانها

بدأ ZONE في 1986، في مرحلة انتقال من Host Table إلى DNS. كانت فكرته الأصلية أن يسير في شجرة DNS، ويجعل من المعلومات المجموعة Host Table، ويخدم المواقع التي لم تكمل الانتقال بعد. يذكر RFC أن البرنامج لم يستخدم لهذه الغاية؛ بل صار أداة لإحصاءات عن نظام النطاقات والإنترنت. تغير الغرض مهم، لكنه لا يبدل حدود جهاز الالتقاط. جدول صار مفيداً للإحصاء يظل جدولاً لما استطاع جامع البيانات أن يراه.

كان البرنامج يحمل قائمة بالنطاقات وخوادم الأسماء الخاصة بها، وعلامة تبين إن كانت معلومات النطاق قد حُمّلت بنجاح من أحد خوادمه. وبسبب عيب آخر في BIND احتاج إلى قائمة بدء تضم نطاقات المستوى الأعلى وخوادمها. للنطاق الذي لم ينجح نقله، كان يحاول الوصول عبر TCP إلى خادم من القائمة. فإذا تم الاتصال أرسل أولاً استعلام Start of Authority، أي SOA، ليتحقق من أن الخادم متسلط على النطاق المطلوب. وعندئذ فقط يرسل AXFR طالباً سجلات المورد كلها في المنطقة.

كان سجل NS يصل من المنطقة يضيف النطاق والخادم المشار إليهما إلى العمل المنتظر. وسجلات A وCNAME وHINFO وMX تحفظ في جدول معلومات المضيفات في الذاكرة. وعندما تمر القائمة كلها من دون معلومات جديدة، يكتب البرنامج الجدول على هيئة HOSTS.TXT. كل خطوة تحدد دعوى مختلفة. نجاح SOA متعلق بأساس سؤال خادم عن منطقة. اكتمال AXFR متعلق بالسجلات التي استقبلها المجمّع. إدخال مادة في الجدول متعلق بقاعدة البرنامج في الحفظ والتجميع. لا تقفز أي واحدة من هذه الخطوات إلى دعوى أن جهازاً ما متاح للمستخدمين أو أن المؤسسة التي يظهر اسمها جزء من السكان الذين يريدهم القارئ.

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

النقص ليس فراغاً محايداً

الأشياء التي لم يدخلها ZONE لها اتجاه واضح في تفسير العدد. تقول المذكرة إن بعض المواقع على الإنترنت لم تسمح بتحويل المنطقة من خوادم نطاقاتها. وبعد محاولات كثيرة فاشلة كان ZONE يتخلى عن النقل. وفي تشغيل الأول من يناير 1992 لم يمكن نقل نحو 800 من 17,000 نطاق. وتبدأ المذكرة أيضاً من ملاحظة أن كل مضيفات الإنترنت لم تكن مسجلة لدى خادم نطاق. ما حُجب عن النقل وما لم ينشر في المصدر لا يمكن أن يظهر في جدول يتغذى من عمليات النقل الناجحة.

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

ويجعل زمن الجمع هذا الحد أكثر وضوحاً. احتاج DNS، الذي قدم نحو 1984، إلى ما يقارب أربع سنوات حتى ينفذ تماماً في الإنترنت؛ وفي تلك الفترة لم تعد كثير من المضيفات تسجل في Host Table. واجهت نسخ BIND الأولى مشكلات كبيرة في نقل المنطقة، ولم يتمكن ZONE من جمع بيانات DNS كاملة تقريباً قبل 1988. نما وقت الجمع من ساعات إلى أسبوع، وبلغ الجدول قرابة 50 ميغابايت. وفي الأسلوب المستخدم آنذاك حفظ البرنامج أسماء المضيفات وعناوين IP فقط، وتجاهل بيانات البروتوكول ومعلومات المضيف وMX، ثم استعمل sort وuniq وgrep لإنتاج الإحصاءات. كان تشغيل SRI يقع كل ثلاثة أشهر.

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

الزيادة المحتملة لا تحول المشاهدة إلى تعداد

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

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

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

الاسم المنشور لا يحدد من «ينتمي» إلى الإنترنت

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

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

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

جمع الدليل له تكلفة، ولا يمنح سلطة تعريف العالم

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

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

التصميم المقترح ليس قاعدة مكتملة لاحقة

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

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

مصادر وحدود الدليل

المصدر الوحيد هو RFC 1296. وهو يدعم صفة المذكرة المعلوماتية في يناير 1992، وخلفية Host Table وZONE، وتسلسل SOA/AXFR، وأنواع السجلات، وتعريف المضيف، وإخفاقات النقل، والإدخالات المتبقية، واستنتاج الحد الأدنى، وأسئلة النطاق، وأرقام يناير 1992، وكلفة الجمع، واقتراح البنية المستقبلية. لا يثبت سكان DNS الحاليين، أو نقل AXFR حيّاً، أو سلوك BIND المعاصر، أو سياسة حالية لجمع النطاقات، أو قابلية وصول مضيف، أو عضوية منظمة، أو أمن خدمة، أو تنفيذ الجامع المقترح، أو نتيجة تاريخية لاحقة.