يمكن أن يؤدي تفويض نطاق فرعي إلى تسهيل تشغيل خدمة الإرسال، ولكنه يوزع أيضًا التحكم في الهوية التنظيمية. مفيدة DKIM يسمي التصميم مالك DNS وأمين المفتاح الخاص ومالك العمل بشكل منفصل. كما أنه يوضح بالضبط ما تم تفويضه وكيف سينتهي هذا التفويض.
لا تبدأ بنشر سجلات مقيدة أو تفترض أن النطاق الفرعي يرسل البريد فقط. تحديد الغرض الحالي والمقصود منه، بما في ذلك الاستلام واستخدام التطبيق والتبعيات الموروثة. لا يحدد تكوين DKIM وحده ما إذا كانت مساحة الاسم يجب أن تقبل الرسائل أو تخدم موقع ويب أو تظل خاملة.
تحديد حدود التفويض
التمييز بين مستوى المحدد CNAME من تفويض منطقة DNS بأكملها باستخدام سجلات NS. أ محدد يشير CNAME إلى بحث معين نحو بيانات التحقق التي يديرها الموفر ضمن RFC 1034 §3.6.2. يعين تفويض المنطقة مسؤولية رسمية للأسماء الموجودة داخل تلك المنطقة، مع مراعاة المزيد من قطع المنطقة، بموجب RFC 1034 §4.2; يمكن أن يتضمن النطاق سجلات لا علاقة لها بـ DKIM . قم بمراجعة تلك السلطة الأوسع قبل التعامل مع الآليتين على أنهما قابلتان للتبادل.
قم بتسجيل اسم البحث المحدد الكامل أو المنطقة المستهدفة أو الموثوقة والمجال d المقصود وحساب الموفر. RFC 6376 §3.1 يصف حالات استخدام المحدد و RFC 6376 §3.6.2.1 يحدد البحث الرئيسي. ولا يحدد الأذونات في لوحة تحكم موفر معين. احصل على تعليمات الموفر الحالية ومالك مسؤول عن تلك الأذونات.
تعيين ثلاثة أنواع من الملكية
يعرف صاحب العمل الرسائل التي يجب أن تستمر في العمل. يمكن لمالك DNS نشر البحث أو التفويض أو إزالته. يتحكم الوصي الرئيسي في مفتاح التوقيع الخاص، سواء كان ذلك نظامًا داخليًا أو موفرًا مُدارًا. يمكن لفريق واحد أن يتولى عدة أدوار، ولكن يجب أن تكون كل مسؤولية واضحة.
اسأل من يمكنه تدوير المفتاح وتغيير مجال التوقيع وتصدير الأدلة وتعطيل حساب الإرسال. بيانات التحقق العامة ليست مفتاح توقيع خاص. لا تطلب أبدًا المفتاح الخاص لموفر الخدمة لمجرد إثبات ذلك سجل صحيح؛ استخدم عناصر التحكم الموثقة والتحقق من الرسائل المستلمة بدلاً من ذلك.
العمل من خلال مثال النطاق
تصميم توضيحي: تم تعيين receipts.mail.example لخدمة إعداد الفواتير، مع توقيع مدعوم باستخدام d=receipts.mail.example ومحدد bill1. تحتفظ المؤسسة DNS الأصلي الخاص بها، بينما يتحكم الموفر في مواد التحقق التي يتم الوصول إليها عن طريق bill1._domainkey.receipts.mail.example . قم بتسجيل مالك الفوترة ومالك تغيير DNS والوصي على مفتاح الموفر مقابل هذا الاسم الدقيق.
إذا كان المجال "من" المرئي receipts.mail.example ، فستتطابق الهويات تمامًا. إذا كان From يستخدم mail.example بدلاً من ذلك، فقم بتقييم التكوين تنسيق الوضع تحت RFC 9989 §3.2.10 واكتشاف المجال التنظيمي تحت RFC 9989 §4.10.2; لا تفترض محاذاة صارمة. يثبت التوقيع العابر علاقة التشفير للمجال d الخاص به، وليس أن كل عنوان ضمن الأصل لديه نفس ترخيص العمل. هذه أداة تصميمية، وليست نتيجة مستأجر حي.
تحقق من التبعيات المخفية قبل التغيير
ابحث في مخزونات التكوين عن الوظائف المجدولة وتطبيقات عصر الاستحواذ وأنظمة الحملات القديمة باستخدام النطاق الفرعي. قم بمراجعة متطلبات الاستلام بشكل منفصل. يمكن أن يؤثر تغيير تفويض DNS على أكثر من DKIM ، بينما يمكن أن تؤثر إزالة المحدد على الرسائل المتأخرة الموقعة بالفعل مع هذا المحدد.
قم بإعداد اختبارات تمثيلية لكل طريق إرسال معروف. التقط من، d، s، نتيجة جهاز الاستقبال الموثوق به ومواءمته، بالإضافة إلى إجابة DNS والطابع الزمني. تحقق من المسار الطبيعي وكذلك مسار الاسترداد. تعتبر لوحة المعلومات التي تم وضع علامة "تم التحقق منها" بمثابة دليل تكوين مفيد، ولكنها ليست بديلاً لعينة الرسائل المستلمة.
اجعل عملية النقل جزءًا من التصميم الأولي
قم بتوثيق كيفية إيقاف التوقيع الجديد والحفاظ على التحقق الضروري أثناء عملية النقل المخطط لها وإزالة التفويض غير المستخدم بعد انتهاء التبعيات. تنسيق الوصول إلى الحساب وبيانات اعتماد API بشكل منفصل؛ لا يعد حذف سجل DNS واحدًا بمثابة إلغاء كامل للموفر. في حالة الاشتباه في وجود تسوية رئيسية، يمكن أن يكون للاحتواء الأمني الأولوية على التداخل العادي.
يجب أن يوضح السجل النهائي غرض مساحة الاسم والسلطة الممنوحة والمالكين والاختبارات وشروط الخروج. يتيح هذا السجل للمسؤول التالي التمييز بين التبعية الضرورية والمؤشر المهجور دون التخمين من اسم الموفر في DNS .
سجل القرار التالي
قبل الموافقة، قارن الاسم الدقيق المطلوب ونوع السجل مع السلطة المقصودة. لا ينبغي استبدال محدد CNAME بصمت بتفويض NS لمنطقة بأكملها. إذا كان الموفر يحتاج إلى نطاق أوسع، فقم بإدراج الأسماء والتبعيات المتأثرة واحصل على قرار المالك المسؤول. لا يمنح المثال أي سلطة DNS فعلية.