ทั้งlibspf2(C) และMail::SPF::Query(perl ที่ใช้ในsendmail-spf-milter ) ใช้กลไกที่ก่อให้เกิด DNS 10 ขีด จำกัดแต่กลไกหลังไม่ได้ (AFAICT) ใช้ข้อ จำกัด MX หรือ PTR libspf2จำกัด แต่ละmxและptrถึง 10 ด้วย
Mail::SPF(perl) มีขีด จำกัด ของ 10 กลไกที่ทำให้เกิด DNS และขีด จำกัด 10 การค้นหาต่อกลไกต่อ MX และต่อ PTR (แพคเกจ Perl ทั้งสองเป็นปกติ แต่ไม่ใช่โดยค่าเริ่มต้นที่ใช้ในMIMEDefang )
pyspfมีข้อ จำกัด ที่ 10 จากทั้งหมด: "การค้นหา", MX, PTR, CNAME; แต่จะคูณ MAX_LOOKUPS 4 อย่างชัดเจนระหว่างการดำเนินการ นอกจากจะอยู่ในโหมด "เข้มงวด" ก็ยังทวีคูณ MAX_MX และ MAX_PTR 4
ฉันไม่สามารถแสดงความคิดเห็นในการใช้งานเชิงพาณิชย์ / เป็นเจ้าของ แต่ข้างต้น (ยกเว้นpyspf) ใช้ขีด จำกัด บนของกลไกการเรียกใช้ DNS 10 กลไก (เพิ่มเติมจากด้านล่าง) ให้หรือรับแม้ว่าในกรณีส่วนใหญ่สามารถแทนที่ได้ในการรัน - เวลา.
ในกรณีเฉพาะของคุณคุณถูกต้องมันคือ 12 รวมและเกินขีด จำกัด 10 ฉันคาดหวังว่าซอฟต์แวร์ SPF ส่วนใหญ่จะส่งคืน "PermError" อย่างไรก็ตามความล้มเหลวจะมีผลต่อผู้ให้บริการ "รวม" ครั้งสุดท้ายเท่านั้นเนื่องจากการนับ จะถูกคำนวณเป็นผลรวมสะสม: กลไก SPF ได้รับการประเมินจากซ้ายไปขวาและการตรวจสอบจะ "เริ่มต้น" ในการผ่านดังนั้นจึงขึ้นอยู่กับว่าเซิร์ฟเวอร์เรียงลำดับปรากฏที่ใดในลำดับ
วิธีการนี้คือการใช้กลไกที่ไม่ก่อให้เกิดการค้นหา DNS เช่นip4และip6จากนั้นใช้mxถ้าเป็นไปได้เพราะจะทำให้คุณมีชื่อได้มากถึง 10 ชื่อซึ่งแต่ละอันสามารถมี IP ได้มากกว่าหนึ่งรายการ
เนื่องจาก SPF ส่งผลให้มีการร้องขอ DNS โดยพลการที่มีการเพิ่มขนาดแบบเอ็กซ์โปเนนเชียล มีขีด จำกัด ที่จงใจต่ำเพื่อป้องกันสิ่งนี้: มันไม่ได้ปรับขนาดตามที่คุณต้องการ
10 กลไก (กลไกอย่างเคร่งครัด + ตัวแก้ไข "การเปลี่ยนเส้นทาง") ที่ทำให้การค้นหา DNS ไม่เหมือนกับการค้นหา DNS 10 รายการ แม้กระทั่ง "การค้นหา DNS" ก็เปิดให้ตีความ แต่คุณไม่ทราบล่วงหน้าว่าต้องใช้การค้นหาแบบแยกกันจำนวนมากและคุณไม่รู้ว่าการค้นหาแบบแยกต่างหากจำนวนเท่าใดตัวแก้ปัญหาแบบเรียกซ้ำของคุณอาจต้องดำเนินการ (ดูด้านล่าง)
RFC 4408 §10.1 :
การใช้งาน SPF ต้อง จำกัด จำนวนกลไกและตัวดัดแปลงที่ทำการค้นหา DNS ให้มากที่สุด 10 รายการต่อการตรวจสอบ SPF รวมถึงการค้นหาใด ๆ ที่เกิดจากการใช้กลไก "รวม" หรือตัวดัดแปลง "เปลี่ยนเส้นทาง" หากเกินจำนวนนี้ในระหว่างการตรวจสอบจะต้องส่งคืน PermError กลไก "รวมถึง", "a", "mx", "ptr" และกลไก "มีอยู่" รวมถึงตัวดัดแปลง "เปลี่ยนเส้นทาง" จะนับรวมกับขีด จำกัด นี้ กลไก "all", "ip4" และ "ip6" ไม่ต้องการการค้นหา DNS ดังนั้นจึงไม่นับรวมกับขีด จำกัด นี้
[ ... ]
เมื่อประเมินกลไก "mx" และ "ptr" หรือแมโคร% {p} ต้องมีขีด จำกัด ไม่เกิน 10 MX หรือ PTR RR ที่ค้นหาและตรวจสอบ
ดังนั้นคุณอาจใช้กลไกได้มากถึง 10 กลไก / ตัวดัดแปลงซึ่งจะทำการค้นหา DNS (ข้อความที่นี่ไม่ดี: ดูเหมือนว่าจะระบุเฉพาะขอบเขตบนของขอบเขตการดำเนินการยืนยันอาจมีขีด จำกัด ที่ 2)
§5.4สำหรับกลไกmxและ§5.5สำหรับกลไกptrแต่ละอันมีการ จำกัด ชื่อที่ค้นหา 10 รายการและใช้กับการประมวลผลของกลไกนั้นเท่านั้นเช่น:
เพื่อป้องกันการโจมตี Denial of Service (DoS) ชื่อ MX มากกว่า 10 ชื่อจะต้องไม่ถูกค้นหาในระหว่างการประเมินกลไก "mx" (ดูหัวข้อที่ 10)
นั่นคือคุณอาจมีกลไก 10 mx ที่มีชื่อ MX มากถึง 10 ชื่อดังนั้นแต่ละรายการอาจทำให้เกิดการดำเนินการ DNS 20 รายการ (10 MX + 10 A การค้นหา DNS แต่ละรายการ) รวม 200 รายการซึ่งคล้ายกับptrหรือ% {p}คุณ สามารถค้นหากลไก10 ptr ได้ดังนั้น 10x10 PTRs แต่ละ PTR ต้องใช้การค้นหา A อีกครั้งรวม 200
นี่คือสิ่งที่ชุดการทดสอบ 2009.10ตรวจสอบดูการทดสอบ " ขีด จำกัด การประมวลผล "
ไม่มีข้อ จำกัด สูงสุดที่ระบุไว้อย่างชัดเจนเกี่ยวกับจำนวนการดำเนินการค้นหา DNS ของลูกค้าทั้งหมดต่อการตรวจสอบ SPF ผมตรวจสอบว่าเป็นการให้หรือรับโดยปริยาย 210 นอกจากนี้ยังมีข้อเสนอแนะเพื่อ จำกัด ปริมาณข้อมูล DNS ต่อการตรวจสอบ SPF ไม่แนะนำขีด จำกัด ที่แท้จริง คุณสามารถประมาณการคร่าวๆได้เนื่องจากระเบียน SPF นั้น จำกัด ไว้ที่ 450 ไบต์ (ซึ่งแบ่งปันอย่างเศร้ากับระเบียน TXT อื่น ๆ ทั้งหมด) แต่ผลรวมอาจเกิน 100kiB หากคุณใจกว้าง ค่าทั้งสองนั้นเปิดกว้างสำหรับการใช้ในทางที่ผิดเนื่องจากการโจมตีแบบขยายซึ่งเป็นสิ่งที่§10.1บอกไว้ว่าคุณต้องหลีกเลี่ยง
หลักฐานเชิงประจักษ์แสดงให้เห็นว่ามีกลไกการค้นหาทั้งหมด 10 รายการที่ใช้กันทั่วไปในเรคคอร์ด (ตรวจสอบค่า SPF สำหรับ microsoft.com ที่ดูเหมือนว่าจะมีความยาวพอที่จะเก็บไว้ที่ 10) เป็นการยากที่จะรวบรวมหลักฐานของความล้มเหลวในการค้นหามากเกินไปเนื่องจากรหัสข้อผิดพลาดที่ได้รับคำสั่งนั้นเป็นเพียง "PermError" ซึ่งครอบคลุมทุกปัญหา ( การรายงานDMARCอาจช่วยได้)
คำถามที่พบบ่อยเกี่ยวกับ OpenSPF จะเพิ่มขีด จำกัดจำนวน "การค้นหา DNS 10 รายการ" แทนการ "10 DNS ที่ก่อให้เกิดกลไกหรือการเปลี่ยนเส้นทางที่แม่นยำยิ่งขึ้น" คำถามที่พบบ่อยนี้ผิดที่จริงเพราะมันบอกว่า:
เนื่องจากมีการค้นหา DNS ไม่เกิน 10 รายการต่อเรคคอร์ด SPF การระบุที่อยู่ IP [... ]
ซึ่งไม่เห็นด้วยกับ RFC ซึ่งกำหนดข้อ จำกัด ในการดำเนินการ "ตรวจสอบ SPF" ไม่ จำกัด การดำเนินการค้นหา DNS ด้วยวิธีนี้และระบุอย่างชัดเจนว่าระเบียน SPFเป็นข้อความ DNS RR เดียว คำถามที่พบบ่อยจะหมายความว่าคุณเริ่มนับใหม่เมื่อคุณดำเนินการ "รวม" เนื่องจากเป็นระเบียน SPF ใหม่ ช่างเป็นระเบียบ
การค้นหา DNS
"การค้นหา DNS" คืออะไร ในฐานะที่เป็นผู้ใช้ ฉันจะพิจารณา " ping www.microsoft.com" เพื่อค้นหา DNS เดียว "การค้นหา": มีชื่อเดียวที่ฉันคาดว่าจะเปลี่ยนเป็น IP เดียว ง่าย? ไม่น่าเศร้า
ในฐานะผู้ดูแลระบบฉันรู้ว่า www.microsoft.com อาจไม่ใช่เร็กคอร์ด A ที่มี IP เดียวมันอาจเป็น CNAME ที่จะต้องค้นหาแบบแยกเพื่อหาเร็กคอร์ด A แม้ว่าจะเป็นตัวแก้ไขอัพสตรีมของฉันก็ตาม มากกว่าตัวแก้ไขบนเดสก์ท็อปของฉัน วันนี้สำหรับฉัน www.microsoft.com เป็นเครือข่ายของ 3 CNAME ที่ในที่สุดก็กลายเป็นระเบียน A บน akamaiedge.net นั่นคือการดำเนินการสืบค้น DNS (อย่างน้อย) 4 รายการสำหรับใครบางคน SPF อาจเห็น CNAME ด้วยกลไก "ptr" เรคคอร์ด MX ไม่ควรเป็น CNAME
ในที่สุดในฐานะผู้ดูแลระบบ DNSฉันรู้ว่าการตอบ (เกือบ) คำถามใด ๆ ที่เกี่ยวข้องกับการดำเนินการ DNS ที่ไม่ต่อเนื่องหลายคำถามแต่ละรายการและคำตอบธุรกรรม (UDP ดาตาแกรม) - สมมติว่าแคชว่างเปล่าตัวแก้ปัญหาแบบเรียกซ้ำ ลง: . →การcom→การmicrosoft.com→การwww.microsoft.comขอเฉพาะประเภทของระเบียน (NS, A ฯลฯ ) ตามความต้องการและการจัดการกับ CNAMEs คุณสามารถเห็นสิ่งนี้ได้dig +trace www.microsoft.comแม้ว่าคุณอาจจะไม่ได้รับคำตอบที่แน่นอนเหมือนกันเนื่องจากมีการใช้ตำแหน่งทางภูมิศาสตร์ (ตัวอย่างที่นี่ ) (มีความซับซ้อนเพิ่มขึ้นเล็กน้อยตั้งแต่ SPF piggybacks ในระเบียน TXT และข้อ จำกัด ล้าสมัย 512 ไบต์สำหรับคำตอบ DNS อาจหมายถึงการลองสืบค้นผ่าน TCP อีกครั้ง)
ดังนั้น SPF จะพิจารณาเป็นอะไร เป็นจุดที่ใกล้ที่สุดกับมุมมองของผู้ดูแลระบบซึ่งจำเป็นต้องทราบข้อมูลเฉพาะของการสืบค้น DNS แต่ละประเภท (แต่ไม่ถึงจุดที่จำเป็นต้องนับแต่ละดาตาแกรม DNS หรือการเชื่อมต่อ)