दोनों libspf2(C) और Mail::SPF::Query(perl, sendmail-spf-milter में प्रयुक्त ) 10 DNS-कारण तंत्रों की एक सीमा को लागू करते हैं , लेकिन बाद वाला (AFAICT) MX या PTR सीमा लागू नहीं करता है। mx और ptr में से libspf2प्रत्येक को भी 10 तक सीमित करता है ।
Mail::SPF(पर्ल) में 10 डीएनएस-कारण तंत्रों की सीमा होती है, और प्रति एमएक्स और पीटीआर प्रति तंत्र में 10 देखने की सीमा होती है। (दो पर्ल पैकेज आमतौर पर, डिफ़ॉल्ट रूप से नहीं होते हैं, MIMEDefang में उपयोग किए जाते हैं ।)
pyspfसभी पर 10 की सीमाएं हैं: "लुक्स", एमएक्स, पीटीआर, CNAME; लेकिन यह स्पष्ट रूप से ऑपरेशन के दौरान MAX_LOOKUPS को 4 से गुणा करता है। जब तक "सख्त" मोड में, यह MAX_MX और MAX_PTR को 4 से गुणा नहीं करता है।
मैं वाणिज्यिक / मालिकाना कार्यान्वयन पर टिप्पणी नहीं कर सकता, लेकिन उपरोक्त (छोड़कर pyspf) स्पष्ट रूप से 10 DNS-ट्रिगर तंत्र (उस पर अधिक) की एक ऊपरी सीमा को लागू करते हैं, दे या लेते हैं, हालांकि अधिकांश मामलों में इसे चलाने पर ओवरराइड किया जा सकता है- पहर।
आपके विशिष्ट मामले में आप सही हैं, इसमें 12 शामिल हैं और यह 10. की सीमा से अधिक है। मुझे उम्मीद है कि अधिकांश SPF सॉफ्टवेयर "PermError" को वापस कर देंगे , हालांकि , असफलता केवल अंतिम "शामिल" प्रदाता (नों) को प्रभावित करेगी क्योंकि गिनती एक चल रहे कुल के रूप में गणना की जाएगी: एसपीएफ़ तंत्र का मूल्यांकन बाएं से दाएं किया जाता है और चेक पास पर "जल्दी-आउट" होगा, इसलिए यह इस बात पर निर्भर करता है कि भेजने वाले सर्वर के अनुक्रम में कहां है।
इसके आस-पास का तरीका उन तंत्रों का उपयोग करना है जो DNS लुकअप को ट्रिगर नहीं करते हैं, जैसे ip4और ip6फिर, mxयदि संभव हो तो उपयोग करें जो आपको 10 और नामों तक पहुंचाता है, जिनमें से प्रत्येक में एक से अधिक आईपी हो सकते हैं।
चूंकि एसपीएफ़ संभावित घातीय स्केलिंग के साथ मनमाने ढंग से डीएनएस अनुरोधों के परिणामस्वरूप होता है, इसलिए इसे आसानी से डॉस / प्रवर्धन हमलों के लिए उपयोग किया जा सकता है। इसे रोकने के लिए जानबूझकर कम सीमाएं हैं: यह आपके इच्छित तरीके को मापता नहीं है।
10 तंत्र (कड़ाई से तंत्र + "पुनर्निर्देशित" संशोधक) के कारण DNS लुक-अप बिल्कुल वैसा नहीं है जैसा कि 10 DNS लुक-अप। यहां तक कि "DNS लुकअप" व्याख्या के लिए खुला है, आप पहले से नहीं जानते हैं कि कितने असतत लुकअप की आवश्यकता है, और आपको नहीं पता है कि आपके रिर्सचिव रिवाल्वर में कितने असतत लुकअप प्रदर्शन करने की आवश्यकता है (नीचे देखें)।
RFC 4408 §10.1 :
SPF कार्यान्वयन आवश्यक रूप से "शामिल" तंत्र या "पुनर्निर्देशन" संशोधक के उपयोग के कारण होने वाले किसी भी लुकअप सहित SPF जाँच में अधिकतम 10 पर DNS लुकअप करने वाले तंत्र और संशोधक की संख्या को सीमित करता है। यदि चेक के दौरान यह संख्या पार हो जाती है, तो एक PermError MUST को लौटा दिया जाना चाहिए। "शामिल", "ए", "एमएक्स", "पीटीआर", और "मौजूद" तंत्र के साथ-साथ "रीडायरेक्ट" संशोधक इस सीमा के खिलाफ गिनती करते हैं। "सभी", "ip4", और "ip6" तंत्रों को DNS लुकअप की आवश्यकता नहीं होती है और इसलिए इस सीमा के विरुद्ध गणना नहीं की जाती है।
[...]
जब "एमएक्स" और "पीटीआर" तंत्र, या% {p} मैक्रो का मूल्यांकन करते हैं, तो वहां 10 से अधिक एमएक्स या पीटीआर आरआर की सीमा नहीं होनी चाहिए और जांच की गई।
तो आप 10 तंत्र / संशोधक का उपयोग कर सकते हैं जो DNS लुकअप को ट्रिगर करते हैं। (यहां शब्दांकन खराब है: यह केवल सीमा की ऊपरी सीमा को बताता है, एक पुष्टि कार्यान्वयन की सीमा हो सकती है 2.)
§5.4 के लिए mx तंत्र, और §5.5 के लिए ptr तंत्र प्रत्येक नाम उस तरह के 10 लुकअप की एक सीमा होती है, और कहा कि केवल कि तंत्र, जैसे के प्रसंस्करण के लिए लागू होता है:
सेवा से इनकार (DoS) हमलों को रोकने के लिए, 10 mx से अधिक नामों को "mx" तंत्र के मूल्यांकन के दौरान नहीं देखा जाना चाहिए (धारा 10 देखें)।
यानी आपके पास 10 mx नाम के साथ 10 mx तंत्र हो सकते हैं, इसलिए उनमें से प्रत्येक 200 के कुल के लिए 20 DNS ऑपरेशन (10 MX + 10 A DNS लुकअप प्रत्येक) का कारण हो सकता है। यह ptr या % {p} के लिए समान है , आप 10 ptr तंत्र देख सकते हैं , इसलिए 10x10 PTR, प्रत्येक PTR को भी A लुकअप की आवश्यकता होती है, फिर से कुल 200।
यह वास्तव में 2009.10 परीक्षण सूट की जांच करता है, " प्रसंस्करण सीमाएं " परीक्षण देखें।
क्लाइंट DNS लुकअप ऑपरेशंस की कुल संख्या पर एसपीएफ-चेक की कोई स्पष्ट रूप से ऊपरी सीमा नहीं है , मैं इसे अनुमानित रूप से 210 की गणना करता हूं, देना या लेना। डीएनएस डेटा प्रति एसपीएफ-चेक की मात्रा को सीमित करने के लिए एक सुझाव भी है, हालांकि वास्तविक सीमा का सुझाव नहीं दिया गया है। आप एक मोटा अनुमान लगा सकते हैं क्योंकि एसपीएफ़ रिकॉर्ड 450 बाइट्स तक सीमित है (जो दुखद रूप से अन्य सभी TXT रिकॉर्ड्स के साथ साझा किया गया है), लेकिन यदि आप उदार हैं तो कुल 100kiB से अधिक हो सकता है। उन दोनों मूल्यों को स्पष्ट रूप से प्रवर्धन हमले के रूप में संभावित दुरुपयोग के लिए खुला है, जो कि वास्तव में .110.1 कहता है कि आपको बचने की आवश्यकता है।
अनुभवजन्य साक्ष्य बताते हैं कि कुल 10 लुकअप मैकेनिज्म को आमतौर पर रिकॉर्ड में लागू किया जाता है (microsoft.com के लिए SPF की जाँच करें जो ऐसा लगता है कि इसे 10 तक रखने के लिए कुछ लंबाई में गए हैं)। बहुत-से-लुकअप विफलता के साक्ष्य एकत्र करना कठिन है क्योंकि अनिवार्य त्रुटि कोड केवल "PermError" है, जो सभी प्रकार की समस्याओं को कवर करता है ( DMARC रिपोर्टिंग हालांकि उस के साथ मदद कर सकती है)।
OpenSPF FAQ , कुल सटीक "10 DNS तंत्र या पुनर्निर्देशन" के बजाय "10 DNS लुकअप" की कुल सीमा को समाप्त करता है । यह अकसर पूछे जाने वाले प्रश्न गलत है क्योंकि यह वास्तव में कहता है:
चूंकि एसपीएफ रिकॉर्ड के अनुसार 10 डीएनएस लुकअप की सीमा है, आईपी पते को निर्दिष्ट करते हुए […]
जो RFC के साथ असहमति में है जो एक "SPF जांच" ऑपरेशन पर सीमाएं लगाता है, इस तरह से DNS लुकअप ऑपरेशन को सीमित नहीं करता है, और स्पष्ट रूप से बताता है कि SPF रिकॉर्ड एक एकल DNS पाठ RR है। एफएक्यू का मतलब यह होगा कि जब आप एक "एसपीएफ" प्रक्रिया शुरू करते हैं तो गिनती को फिर से शुरू करें क्योंकि यह एक नया एसपीएफ़ रिकॉर्ड है। क्या झंझट है।
डीएनएस लुकअप
वैसे भी "DNS लुकअप" क्या है? एक उपयोगकर्ता के रूप में । मैं ping www.microsoft.comएक एकल डीएनएस "लुकअप" को शामिल करने के लिए " " विचार करूंगा : एक नाम है जिसे मैं एक आईपी में बदलने की उम्मीद करता हूं। सरल? अफसोस की बात नहीं।
एक व्यवस्थापक के रूप में मुझे पता है कि www.microsoft.com एक एकल आईपी के साथ एक साधारण ए रिकॉर्ड नहीं हो सकता है, यह एक CNAME हो सकता है जो बदले में एक रिकॉर्ड प्राप्त करने के लिए एक और असतत लुकअप की आवश्यकता है, जो कि मेरे अपस्ट्रीम रिज़ॉल्वर का प्रदर्शन करेगा मेरे डेस्कटॉप पर रिज़ॉल्वर के बजाय। आज, मेरे लिए, www.microsoft.com 3 CNAME की एक श्रृंखला है जो अंत में akamaiedge.net पर A रिकॉर्ड के रूप में समाप्त होती है, यह किसी के लिए (कम से कम) 4 DNS क्वेरी ऑपरेशन है। SPF "ptr" तंत्र के साथ CNAME को देख सकता है, हालांकि MX रिकॉर्ड CNAME नहीं होना चाहिए।
अंत में, एक DNS प्रशासक के रूप में मुझे पता है कि किसी भी प्रश्न का उत्तर देना (लगभग) कई असतत DNS संचालन, व्यक्तिगत प्रश्न और उत्तर लेनदेन (UDP डेटाग्राम) शामिल हैं - खाली कैश मानकर, एक पुनरावर्ती रिज़ॉल्वर को DNS रूट पर शुरू करने और अपने तरीके से काम करने की आवश्यकता है नीचे: . → com→ microsoft.com→ आवश्यकता www.microsoft.comके अनुसार विशिष्ट प्रकार के रिकॉर्ड (NS, A आदि) मांगने और CNAME से निपटने के लिए। आप के साथ कार्रवाई में देख सकते हैं dig +trace www.microsoft.com, हालांकि आप शायद नहीं ठीक उसी जवाब जियोलोकेशन प्रवंचना की वजह से (उदाहरण के मिल जाएगा यहाँ )। (TXT रिकॉर्ड्स पर SPF पिग्गीबैक के बाद से इस जटिलता के लिए थोड़ा और भी अधिक है, और DNS उत्तरों पर 512 बाइट्स की अप्रचलित सीमा का मतलब टीसीपी पर प्रश्नों को पुनः प्राप्त करना हो सकता है।)
तो एसपीएफ़ एक खोज के रूप में क्या विचार करता है? यह वास्तव में देखने के व्यवस्थापक बिंदु के सबसे करीब है , इसे प्रत्येक प्रकार के DNS क्वेरी की बारीकियों के बारे में पता होना चाहिए (लेकिन उस बिंदु तक नहीं जहां इसे वास्तव में व्यक्तिगत DNS डेटाग्राम या कनेक्शन की गणना करने की आवश्यकता है)।