الخلاصة
- يثبت سياق DoC المحمي التبادل بين طرفيه، لا طريق DNS الذي يسلكه الخادم بعد ذلك.
- الاكتشاف والسياق والرد والمنبع وDNSSEC وقبول التطبيق أدلة مستقلة.
تضع RFC 9953 السؤال والرد في تبادل CoAP، ويمكن لـ DTLS أو TLS أو OSCORE حماية ذلك المقطع. هذا مفيد للأجهزة المقيدة، لكنه لا يصف سوى من يتشارك السياق.
يستطيع خادم DoC استخدام DNS عبر UDP غير محمي في المنبع. قد يستخدم سياقاً محمياً آخر، لكن ذلك معتم على العميل في مستوى البروتوكول. لذلك لا يشهد مؤشر آمن في القفزة الأولى على المكرر أو الذاكرة المخبأة أو السلطة أو الاتصال التالي.
مصدر الإعداد لا يحل محل هذا الدليل. يجب أن يعرف العميل الخادم والمورد، وأن يأتي الاكتشاف الآلي من مصدر موثوق؛ وهذا يثبت أصل الإعداد لا تحقق DNSSEC لجواب معين ولا قبول التطبيق له. Amsüss مؤلف مشارك في معيار جماعي، لا مشغل خدمة محددة.
المصادر
- https://www.rfc-editor.org/rfc/rfc9953.html
- https://www.rfc-editor.org/rfc/rfc8613.html
- https://christian.amsuess.com/
- https://github.com/chrysn
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
