الخلاصة

  • يحوّل ENUM رقم E.164 إلى مفتاح DNS، ثم يعالج قواعد NAPTR بالترتيب إلى أن ينتج URI؛ وهذه النتيجة عنوان اتصال محتمل بخدمة، لا دليلاً على اكتمال جلسة اتصال.
  • يجمع سجل المكالمة القابل للدفاع بين التحقق من حق استخدام الرقم، وحالة DNSSEC، وسجل NAPTR المختار، وURI الناتج، ومصادقة الطرف اللاحق، ومسار الإشارة، والوسائط ثنائية الاتجاه المرصودة، من دون دمجها في عبارة «نجح ENUM».

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

كان Fältström، مع Michael Mealling، من مؤلفي RFC 3761 الذي صاغ تطبيق ENUM على نظام DDDS في عام 2004. ثم حدّث RFC 6116 ذلك العمل في عام 2011، وشرح صراحة أنه مراجعة لنص Fältström وMealling. القراءة التشغيلية المهمة هنا ليست أن ENUM «يجعل أرقام الهاتف تعمل على الإنترنت»، بل أنه يضع مرحلة اكتشاف منضبطة بين رقم E.164 وبروتوكول خدمة آخر. نهاية تلك المرحلة ليست نهاية الاتصال.

الرقم يتحول أولاً إلى مفتاح DNS

تبدأ الخوارزمية برقم E.164 كامل. تُزال منه العلامات غير الرقمية اللازمة للعرض، ثم تُعكس الأرقام، وتوضع نقاط بينها، وتضاف اللاحقة e164.arpa. هكذا لا يصبح الرقم هوية مستخدم ولا شهادة ملكية؛ بل يصبح اسم نطاق يُسأل عن سجلات NAPTR.

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

يصف RFC 3403 حقول NAPTR التي تحكم المعالجة: ORDER يحدد أي مجموعة من القواعد تُجرَّب أولاً، وPREFERENCE يرتب البدائل داخل المجموعة، بينما تحدد FLAGS وSERVICES وREGEXP وREPLACEMENT كيفية التحويل والخطوة التالية. الوصول إلى سجل قابل للتطبيق يعني أن آلة قواعد وجدت انتقالاً مشروعاً. لا يعني أن الخدمة الناتجة أجابت أو قبلت المستخدم.

قاعدة نهائية واحدة لا تلغي الاختيار

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

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

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

إذا نتج sip: URI من قاعدة ما، فالإيصال الصحيح يقول: «اختيرت هذه القاعدة، وولّدت هذا العنوان، وفق هذه السياسة». أما «وُجد الشخص» أو «تمت المكالمة» فادعاءان يحتاجان إلى أدلة لاحقة.

الحق في الرقم إيصال يسبق الاستعلام

يفصل RFC 4725 بين صاحب الحق في الرقم، والمسجِّل، وجهة التحقق، والسجل، وأمين التسجيل، ومزود DNS، ومزود التطبيق. قد تؤدي جهة واحدة أكثر من دور، لكن جمعها تنظيمياً لا يجعل الوقائع متطابقة. يمكن لسجل DNS أن يعمل بلا خطأ بينما يكون إثبات حق التسجيل قديماً.

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

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

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

DNSSEC يثبت البيانات، لا هوية طرف الخدمة

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

يوضح RFC 6116 أن الخدمة الناتجة ينبغي أن تصادق الطرف أثناء إعداد الخدمة. السبب بنيوي: ENUM انتهى قبل أن يبدأ بروتوكول الخدمة. قد يشير URI إلى اسم يحتاج بدوره إلى NAPTR أو SRV أو A وAAAA. وقد تسلك الإجابات اللاحقة مساراً مختلفاً، وتخضع لذاكرة مؤقتة أخرى، وتنتهي عند وسيط أو بوابة أو نطاق ثقة جديد.

كما أن زمن التخزين المؤقت ليس ملاحظة هامشية. يمكن أن تكون كل إجابة صحيحة داخل TTL الخاص بها، بينما تمثل السلسلة مجتمعة أزمنة مختلفة: رقم أُعيد التحقق منه الآن، وNAPTR من ذاكرة أقدم، وSRV أحدث، وعنوان شبكة تبدل بعد ذلك. «صحيح تشفيرياً» و«متسق زمنياً مع بقية الرحلة» حكمان منفصلان.

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

URI للصوت يبدأ بروتوكولاً آخر

يعرّف RFC 4415 خدمة ENUM للصوت بحيث يمكن استعمال tel: URI الناتج لبدء مكالمة صوتية تفاعلية. كلمة «بدء» هي الحد الفاصل. فهي لا تعد بأن الجهاز قابل للوصول، أو أن شبكة الوجهة ستقبل الاتصال، أو أن الشخص سيوافق، أو أن الصوت سيمر في الاتجاهين.

أما حين يكون الناتج sip: URI، فتبدأ آلة حالة SIP المنفصلة التي يصفها RFC 3261. عليها تحديد موقع المستخدم، ومصادقة الأطراف وتفويضها حيث يلزم، وإرسال الدعوة، ومعالجة الردود المؤقتة والنهائية، وتأكيد الجلسة. قد يكون الرد رفضاً أو تحويلًا أو انشغالاً أو فشلاً في الوصول. وقد تنجح الإشارة من دون أن تكون الوسائط قابلة للاستخدام.

هنا يقع خطأ القياس الشائع. قد يعدّ فريق DNS استخراج URI نجاحاً، ويعدّ وكيل SIP وصول استجابة نجاحاً، وتعدّ منصة الوسائط وجود حزم نجاحاً. لكن المستخدم قد يسمع صمتاً، أو صوتاً في اتجاه واحد، أو يجيب نظاماً آلياً غير مقصود. كل مقياس محلي صادق في حدوده، ولا يملك وحده حق تسمية النتيجة «مكالمة مكتملة».

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

ابنوا إيصال المكالمة بالترتيب

السجل المفيد لا يحتاج إلى مخزن شامل لمحتوى الاتصال. يحتاج إلى سلسلة قليلة البيانات واضحة الحدود. تبدأ السلسلة بوقت إدخال رقم E.164 وسياقه، ثم مرجع التحقق من حق استعماله. يلي ذلك اسم ENUM المشتق، ومجموعة NAPTR التي شوهدت، وحالة DNSSEC وTTL، والقاعدة المختارة وسبب الاختيار، وURI الناتج.

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

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

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

المصادر