انتهاء الذاكرة المؤقتة لا يسحب موقعا صار علنيا

الخلاصة

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

تعديل السجل لا يمحو المعرفة

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

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

كان الوعي بالعلنية حاضرا مبكرا. RFC 1712، الذي اقترح GPOS في نوفمبر 1994، يوضح أن المعلومات الموضوعة في DNS عامة. ثم حذر RFC 1876، الخاص بسجل LOC في يناير 1996، من مخاطر مادية قد تزيد مع دقة تحديد المكان. لا تثبت هذه التحذيرات وقوع هجوم معين؛ لكنها تبين أن القدرة على الوصف لم تكن توصية بنشر أقصى التفاصيل.

لماذا استُخدمت أسماء الإنترنت للمكان؟

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

ناقش اقتراح GPOS، وهو وثيقة تجريبية، بدائل مثل sysLocation في SNMP، وما يرتبط به من وكيل وصلاحية قراءة ووصف محلي، وكذلك محدودية انتشار X.500 آنذاك. هذه اعتبارات من سياق التسعينيات، وليست إحصاءات عن وضع تلك التقنيات اليوم.

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

GPOS استخدم ثلاث سلاسل رقمية قابلة للطباعة، وليس ثلاثة أعداد ثنائية من نوع الفاصلة العائمة IEEE. إمكان كتابة منازل عشرية كثيرة لا يخبر القارئ بالأداة التي أنتجت الرقم أو بتاريخ القياس. وتلك مشكلة معنى، لا مشكلة سعة تخزين.

حتى أسماء المحاور لم تكن تفصيلا ثانويا

في نص RFC 1712 تبدلت بعض تسميات وتعريفات خطي الطول والعرض. التصحيح الرسمي 541، المبلغ عنه في 2006، يعالج هذا الالتباس ويقترح تصحيح التسميات مع الحفاظ على ترتيب الأرقام.

حالة التصحيح هي «Held for Document Update»، أي مؤجل لمعالجة عند تحديث الوثيقة، وليست «Verified». لذلك لا يصح التعامل معه كأنه تعديل معياري اكتمل بالفعل أو دليل على أن جميع التطبيقات اتفقت على تفسير واحد. ولا حاجة إلى إعادة نشر أمثلة الإحداثيات القديمة بوصفها إعدادات صالحة للتنفيذ.

ظهر LOC بعد GPOS، لكن RFC 1876 لا يعلن إلغاء RFC 1712. ما زال سجل معلمات DNS لدى IANA يورد GPOS بالرقم 27 وLOC بالرقم 29. استمرار الاسمين في السجل يحدد هوية الصيغتين، ولا يثبت انتشار أي منهما أو انتظام تحديث بياناتهما.

ثلاث إجابات بدلا من نقطة واحدة

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

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

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

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

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

دقة التمثيل ليست دقة المعرفة

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

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

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

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

ارتفاع بالنسبة إلى أي سطح؟

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

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

وفي ملف المنطقة تُكتب قيم الارتفاع والحجم والدقة بالأمتار، بينما تستخدم الحقول الثنائية المعنية السنتيمترات. العدد لا يحمل وحدته معه خارج تفسير الصيغة. قد تبدو قيمة ما معقولة عدديا، مع أنها تُقرأ انطلاقا من مرجع أو وحدة غير صحيحين.

حين يكون البديل شبكة كاملة

من اسم مضيف، يبدأ البحث بسجل LOC لذلك الاسم، مع متابعة CNAME بالطريقة المعتادة. إذا لم يوجد موقع مباشر، يمكن الاستعانة بعناوين A المرتبطة للبحث عن موقع شبكة أو شبكة فرعية. ومن عنوان IPv4، يبدأ الإجراء بالحصول على اسم عبر IN-ADDR.ARPA، ثم طلب LOC للاسم الناتج.

البديل الشبكي اختياري، ويستند إلى أسلوب تسمية تاريخي في RFC 1101 من عام 1989. يستعمل هذا الأسلوب PTR وبيانات بشكل A تحت أسماء عكسية خاصة لاستخراج أسماء الشبكات والأقنعة. بعض قيم A هنا أقنعة للشبكة الفرعية، وليست عناوين خدمات يمكن الاتصال بها.

تجمع عملية LOC الأسماء، ثم تبحث من الأكثر تحديدا نحو النطاق الأوسع. ليست العملية صعودا عاديا بين تسميات الآباء في DNS، وليست اختيار أطول بادئة في توجيه BGP. وهي مرتبطة بافتراضات IPv4 والتقسيم إلى فئات في ذلك الزمن؛ لا يقدم النص امتدادا عاما يحل كل حالات IPv6.

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

التوقيع لا يزور المكان

يفصل نموذج الموارد في RFC 1035 بين الاسم والنوع والفئة وTTL والبيانات. مدة التخزين المؤقت تخص إعادة الاستعلام، ولا تسجل متى جرى التحقق الميداني من الموقع.

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

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