الخلاصة

  • يثبت تطابق SSHFP الموثق بـDNSSEC ارتباط خوارزمية وبصمة مفتاح مضيف باسم DNS محدد، ولا يثبت أن الاسم هو الخدمة المقصودة ولا يحمل منفذاً أو مستخدماً أو أمراً.
  • يتكون القرار من اختيار الاسم وحالة DNSSEC والمقارنة الدقيقة وإثبات حيازة المفتاح وسياسة العميل؛ ويضيف التدوير ساعات التخزين المؤقت وknown_hosts.

دليل صحيح لاسم خاطئ

لم تُزوّر أي توقيعات. اختار المحلل اسماً كاملاً، وثبتت سلسلة DNSSEC مجموعة SSHFP، ووقّع الخادم التبادل بالمفتاح الخاص. السؤال المفقود أسبق: لماذا تحوّل db إلى ذلك الاسم؟

يحذر RFC 4255 من الأسماء غير المؤهلة لأن مسار بحث محقوناً قد يقود إلى مضيف آخر. DNSSEC يصحح جواب السؤال المطروح، ولا يصنع نية السائل. لذلك يجب فصل الاسم الأصلي والاسم الفعلي واللاحقة أو CNAME ومالك SSHFP والعنوان والمنفذ.

SSHFP هو نوع DNS رقم 44. يحمل رقم خوارزمية المفتاح ونوع البصمة والبصمة. يجب أن تتطابق الخوارزمية والبصمة المحسوبة على كتلة المفتاح. ثم يثبت توقيع تبادل SSH حيازة المفتاح الخاص، لا حيازته الحصرية؛ فالنسخة المسروقة توقّع أيضاً.

لا يحمل السجل منفذاً أو حساباً أو أمراً أو دوراً أو مدة صلاحية. كما أن Secure وInsecure وBogus وIndeterminate حالات مختلفة. لا يمنح التطابق تحت Insecure ثقة آلية، ولا يجوز خفض Bogus إلى Insecure. وحتى Secure يوثق السجل تحت الاسم المختار ولا يوثق أن لاحقة DHCP كانت مقصودة.

يسجل IANA خوارزميات RSA وDSA وECDSA وEd25519 وEd448 وبصمتي SHA-1 وSHA-256. يفرض RFC 6594 تفضيل SHA-256؛ فإذا فشل تطابقه وجب رفض المفتاح، لا إنقاذه عبر SHA-1 مطابق.

تبقى السياسة محلية. القيمة الافتراضية في OpenSSH هي VerifyHostKeyDNS=no. ومع yes يوثق التطابق الآمن ضمنياً، أما ask فيبقي القرار لـStrictHostKeyChecking. وتستطيع known_hosts تمييز [hostname]:port بينما لا يحمل SSHFP المنفذ.

يتطلب التدوير نشر البصمة الجديدة مسبقاً ومراقبة المحللات وتداخل المفاتيح ثم إزالة القديم بعد مراعاة TTL وRRSIG. حذف السجل السلطوي لا يعني رفضه فوراً في كل ذاكرة.

وأخيراً، توثيق الخادم في طبقة النقل لا يوثق المستخدم ولا يجيز shell أو forwarding أو أمراً. يجب أن تختبر الحالات السلبية مساري بحث، وحالات DNSSEC الأربع، وفشل SHA-256، وتعارض pin، ومنفذين، ومضيف قفز، ومفتاحاً منسوخاً، ثم رفض المستخدم والأمر بعد نجاح المضيف.