لا يعني محرر DNS الذي يبلغ عن حد يبلغ 255 حرفًا بالضرورة أنك SPF يجب أن تصبح السياسة سجلات متعددة. يسمح تنسيق DNS TXT بسلاسل أحرف متعددة داخل سجل مورد واحد. يتعامل SPF مع محتوياتها كقيمة واحدة مستمرة. ويتمثل التحدي التشغيلي في الحفاظ على النص المقصود مع إبقاء السياسة واستجابات DNS الخاصة بها قابلة للإدارة.
فصل ثلاثة حدود مختلفة
أولاً، تقتصر سلسلة أحرف TXT الفردية على 255 ثماني بتات. محتوى SPF هو ASCII، لذا فإن كل حرف من أحرفه العادية يشغل ثماني بتات واحدة. واحد سجل TXT يمكن أن تحتوي على أكثر من سلسلة واحدة من هذا القبيل. RFC 7208 القسم 3.3 يسمح صراحة بهذا التمثيل.
ثانيًا، استجابة DNS لها حجم. ويتضمن الأسماء وبيانات تعريف السجل وسجلات TXT الأخرى التي يتم إرجاعها باسم المالك هذا، وليس فقط نص نظام التعرف على هوية SPF . يوصي القسم 3.4 بإبقاء إجابات SPF DNS صغيرة بما يكفي للتعامل مع UDP القديم الذي يبلغ 512 أوكتات. هذه توصية توافق، وليست حدًا أقصى عالميًا يبلغ 512 حرفًا لنظام التعرف على SPF . لا تؤدي إمكانيات نقل DNS الحديثة إلى التخلص من كل مشكلة في محلل البيانات أو جدار الحماية أو مشكلة الاقتطاع.
ثالثًا، تقييم SPF له حدود للموارد. لا يؤدي تقسيم النص إلى سلاسل إلى تقليل عملية التضمين المتداخلة أو الحد العشرة لمصطلحات البحث المسببة. يمكن أن تتجاوز السياسة القصيرة حد التقييم هذا؛ قائمة أطول من العناوين الصريحة قد لا. تقييم بناء الجملة ونقل DNS وتكلفة التقييم بشكل مستقل.
الحفاظ على المساحات عمدا
يقوم SPF بتسلسل السلاسل دون إدراج مسافات. في تمثيل ملف المنطقة، "v=spf1 ip4:192.0.2.10 " "ip4:198.51.100.20 -all" ينتج السياسة المستمرة المقصودة لأن السلسلة الأولى تنتهي بمسافة. تؤدي إزالة هذه المسافة إلى دمج الآليتين المتجاورتين في نص غير صالح.
عناوين التوثيق فقط المذكورة أعلاه توضيحية. وهي ليست قيمًا معتمدة لنطاقك. علامات الاقتباس هي بناء جملة العرض التقديمي لملف المنطقة؛ يعتمد ما إذا كنت تقوم بإدخالها في محرر DNS مستضاف على الواجهة الموثقة لهذا الموفر. يقوم بعض المحررين بتقسيم القيم الطويلة تلقائيًا، بينما يعرض البعض الآخر حقول سلسلة منفصلة. تحقق من الإجابة المقدمة بدلاً من افتراض أن عرض المحرر يتطابق مع تنسيق السلك.
لا تقم بإنشاء بداية سجل مورد TXT ثانٍ v=spf1 للاحتفاظ بالباقي. متعددة مختارة سجلات SPF ينتج permerror. وعلى العكس من ذلك، لا تحذف سجلات التحقق TXT غير ذات الصلة لأن أداة التشخيص تعرض العديد من إجابات TXT .
فحص القيمة المنشورة
التقط استجابة TXT الرسمية وحدد السلاسل التي تنتمي إلى كل سجل مورد. قم بإعادة بناء قيمة نظام التعرف على SPF عن طريق ربط السلاسل فقط ضمن سجل واحد. تحقق من المسافات عند كل حدود مقسمة وتأكد من وجود علامة إصدار واحدة وآليات صالحة والبيان النهائي المقصود.
ثم اختبر استجابات DNS المتكررة من الشبكات المهمة. إذا تم اقتطاع الاستجابة أو فشل الحل، فتحقق من نقل DNS وتكوين الموفر بدلاً من حذف الآليات التعسفية. DNSSEC ويمكن أن تؤثر مجموعة الإجابات الأوسع على حجم الاستجابة؛ لا يعد عدد الأحرف البسيط اختبارًا كاملاً لحجم الحزمة.
تفضل تنظيف السياسة على التعبئة الذكية
غالبًا ما تشير السياسة المتنامية إلى الخدمات المتراكمة. مراجعة التضمينات القديمة والآليات الواسعة بلا داع والتراخيص المكررة قبل زيادة التعقيد. احتفظ بالآليات الحالية التي يديرها الموفر عندما يكون ذلك مناسبًا بدلاً من نسخ عناوين IP الحالية الخاصة بهم فقط لتقصير السجل أو إعادة تشكيله. يمكن أن تصبح العناوين المسطحة يدويًا قديمة عندما يقوم الموفرون بتغيير البنية التحتية.
بالنسبة للسياسة التي لا تزال بحاجة إلى سلاسل متعددة، احفظ النص غير المقسم المقصود إلى جانب التمثيل المنشور. وهذا يمنح المسؤولين المستقبليين هدف مقارنة ثابتًا. لا ينبغي الخلط بين إعادة تنسيق المحرر غير الضارة وتغيير السياسة الدلالية.
التحقق من النتيجة التي تواجه القارئ
بعد إجراء تغيير معتمد، قم باختبار المصادر التمثيلية والمصدر الذي لا مثيل له باستخدام مقيم مطلع على المعايير، ثم افحص النتائج الفعلية لجهاز الاستقبال الموثوق به. سجل القيمة المعاد بناؤها وملاحظات الاستجابة ونتائج التقييم. قم بإغلاق المشكلة عندما يكون تمثيل DNS وسلوك التفويض صحيحين، وليس فقط عندما يقبل المحرر الحفظ.
إعادة بناء إجابة الاستعلام
ما يلي هو تمرين تشخيصي تركيبي، وليس استعلامًا قمنا بإجرائه أو سجل للنشر. استبدل اسم مالك نظام التعرف على SPF الفعلي والمعتمد الذي تم التحقق منه خادم الأسماء قبل استخدام أوامر القراءة فقط هذه. تستخدم هذه القوالب أسماء الأمثلة المحجوزة.
حفر @ ns1.example.net example.com TXT +noall +إجابة حفر example.com TXT +noall +answerيطلب الأمر الأول من الخادم المعتمد المحدد؛ والثاني يستخدم المحلل الذي تم تكوينه على هذا الجهاز. لا تثبت إجابة أحد المحللين التكراريين أن كل جهاز استقبال يرى نفس البيانات. إذا لزم الأمر، قم بالاستعلام عن محلل معروف آخر بشكل صريح باستخدام @server-address.
الجواب الاصطناعية:
example.com . 300 في TXT " v=spf1 ip4:192.0.2.10 " " ip4:198.51.100.20 -all "القيمة المعاد بناؤها:
v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 -allبدون المسافة الزائدة في السلسلة الأولى، يصبح الحد 192.0.2.10ip4: 198.51.100.20 . قد يقبل المحرر بيانات TXT ، لكن هذا لا يجعل سياسة SPF صالحة. على النقيض من ذلك، فإن سجلي الإجابات المنفصلين، كل منهما يبدأ v=spf1 يمثلان مشكلة متعددة السياسات، وليس حلاً لتقسيم السلسلة.
احفظ الخادم الذي تم الاستعلام عنه واسم المالك والطابع الزمني والإجابة. قم بإعادة بناء سجل واحد في كل مرة، وقارنه بسياسة عدم التقسيم المقصودة، ثم قم بتقييم تفويض المرسل بشكل منفصل. الأوامر تفحص تمثيل DNS ؛ لا يقومون بإجراء تقييم SPF كامل. يرى RFC 7208 القسم 3.3 للربط و القسم 4.6.4 لحدود التقييم