الخلاصة
- تقترح مسودة فردية أن يحذف المحلّل التكراري الذي لا يتحقق من DNSSEC بت DO من استعلامه الصاعد إذا كان طلب العميل الأصلي خالياً منه.
- إذا جاء لاحقاً عميل يطلب أدلة التحقق، فعلى المحلّل أن يعرف أن الإجابة في ذاكرته بلا دليل وأن يعيد سؤال الخادم الموثوق.
يحصل العميل الأول على إجابة صغيرة. يأتي الثاني مطالباً بالتوقيع. الإجابة موجودة في الذاكرة، أما الدليل فلم يصل إليها قط. هذه الفاتورة المؤجلة هي لب مسودة Clearing the DO bit for DNSSEC التي قدمها Warren Kumari وGeoff Huston وPeter Thomassen في 30 أكتوبر. إنها مقترح فردي للنقاش، لا معياراً اعتمدته IETF.
يشير بت DO إلى طلب سجلات DNSSEC. يلزم RFC 3225 وRFC 4035 المحلّل التكراري المدرك لـDNSSEC بأن يضع هذا البت في استعلامه الصاعد، حتى إن لم يضعه العميل. يستطيع بعدها حجب أدلة التحقق عن ذلك العميل مع الاحتفاظ بها للطلبات التالية.
تقترح المسودة تغييراً مشروطاً: عندما لا يجري المحلّل التحقق بنفسه ويتلقى استعلاماً بلا DO، يرسل استعلامه إلى الخادم الموثوق بلا DO أيضاً. عندها لا تُضمَّن أدلة DNSSEC تلقائياً. الدافع هو احتمال أن تزيد التواقيع اللاحقة للحوسبة الكمومية حجم الردود، وأن يرتفع اقتطاع الرسائل والرجوع إلى TCP. لا تقدم المسودة قياساً للبايتات الموفرة أو لعدد الاتصالات التي ستختفي.
الشرط الحاسم يقع في الذاكرة المؤقتة. يجب تمييز السجلات التي جُمعت بلا أدلة DNSSEC. إذا ورد استعلام لاحق مع DO، يجب طلب الدليل من الخادم الموثوق مجدداً. إرجاع الإجابة المخزنة وحدها يترك العميل الذي يتحقق بلا المادة التي يحتاجها. وتعرض مناقشة DNSOP خياراً منافساً: نقل مزيد من DNS عبر اتصال تدفقي يتحمل الردود الكبيرة. الدليل الذي يحسم الاختيار هو تنفيذ يُختبر فيه ترتيب الطلبين، ونجاح التحقق، والحمل الكلي على الخادم الموثوق.
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
