[ DNS और डोमेन ]

प्रमाणीकरण लुकअप में DNS प्रतिक्रिया ट्रंकेशन और टीसीपी फ़ॉलबैक

अनुपस्थित प्रमाणीकरण नीति के साथ परिवहन विफलता को भ्रमित किए बिना काटे गए DNS प्रतिक्रियाओं और अवरुद्ध टीसीपी का निदान करें।

EmailAuth अनुसंधान टीम द्वारा

[ प्रमुख बिंदु ]

  • एक संक्षिप्त प्रतिक्रिया पूर्ण प्रमाणीकरण-नीति उत्तर नहीं है।
  • स्टब-टू-रिज़ॉल्वर और रिज़ॉल्वर-टू-अथॉरिटी पथों का अलग-अलग परीक्षण करें।
  • एकाधिक SPF नीतियां बनाए बिना परिवहन विफलता को सुधारें।
इस पेज पर

DNS लुकअप विफल हो सकता है क्योंकि प्रतिक्रिया प्रयोग करने योग्य यूडीपी एक्सचेंज में फिट नहीं होती है और फ़ॉलबैक पथ पूरा नहीं हो सकता है। बड़ा TXT रिकॉर्ड, DNSSEC सामग्री और प्रतिक्रिया संरचना इस समस्या को उजागर कर सकती है। केवल इसलिए किसी कुंजी को न हटाएं या पॉलिसी को छोटा न करें क्योंकि चेकर कोई रिकॉर्ड रिपोर्ट नहीं करता है; पहले यह निर्धारित करें कि रिज़ॉल्वर को पूर्ण उत्तर प्राप्त हुआ या नहीं।

ट्रंकेशन सिग्नल पढ़ें

सन्दर्भ: RFC 1035 §4.1.1, RFC 7766 §5, RFC 6891 §6.2.3.

DNS हेडर का टीसी बिट ट्रंकेशन को इंगित करता है। एक क्लाइंट जिसे लापता डेटा की आवश्यकता होती है वह सामान्यतः टीसीपी का उपयोग करके पुनः प्रयास करता है। आधुनिक DNS कार्यान्वयन को RFC 7766 के तहत टीसीपी का समर्थन करना चाहिए; DNS केवल यूडीपी सेवा नहीं है। ईडीएनएस एक अनुरोधकर्ता को बड़े यूडीपी पेलोड आकार का विज्ञापन करने की सुविधा देता है, लेकिन वह विज्ञापन इस बात की गारंटी नहीं है कि पथ पर प्रत्येक नेटवर्क पैकेट ले जाएगा।

आईपी ​​विखंडन, फ़ायरवॉल और टूटे हुए मिडिलबॉक्स बड़े यूडीपी प्रतिक्रियाओं में हस्तक्षेप कर सकते हैं। टीसीपी की आवश्यकता स्वतंत्र रूप से हो सकती है चाहे वेब पैनल में कोई विशेष TXT मान छोटा दिखाई दे। प्रतिक्रिया और पथ को मापें, न कि केवल आपके द्वारा चिपकाए गए वर्णों की संख्या को।

दोनों रिज़ॉल्वर पैरों को अलग करें

सन्दर्भ: RFC 7766 §5, RFC 7208 §4.4.

स्टब-टू-रिकर्सिव और रिकर्सिव-टू-आधिकारिक आदान-प्रदान अलग-अलग हैं। आपके लैपटॉप से ​​सार्वजनिक रिज़ॉल्वर तक सफल टीसीपी यह साबित नहीं करता है कि मेल रिसीवर का रिज़ॉल्वर टीसीपी पर आपके अधिकार तक पहुंच सकता है। इसी तरह, एक प्रत्यक्ष प्राधिकरण परीक्षण एक रिसीवर द्वारा उपयोग किए गए प्रत्येक अग्रेषण रिज़ॉल्वर को पुन: उत्पन्न नहीं करता है।

रिकॉर्ड क्वेरी स्वामी, प्रकार, सर्वर, परिवहन, ईडीएनएस विकल्प, प्रतिक्रिया आकार, झंडे और समय। एक काटी गई आंशिक प्रतिक्रिया को चयनित के पूर्ण सेट के रूप में नहीं समझा जाना चाहिए SPF नीतियाँ. SERVFAIL और टाइमआउट इस बात का सबूत नहीं हैं कि नाम मौजूद नहीं है। एप्लिकेशन रिकॉर्ड बदलने से पहले सटीक त्रुटि को सुरक्षित रखें।

नियंत्रित फ़ॉलबैक दोष को पुन: उत्पन्न करें

एक डिस्पोजेबल DNS लैब में, एक उत्तर को इतना बड़ा कॉन्फ़िगर करें कि वह जानबूझकर छोटे स्वीकृत यूडीपी प्रतिक्रिया आकार से अधिक हो। पहले यूडीपी और टीसीपी दोनों को अनुमति दें। उसी मालिक से अनुरोध करें और पैकेट या रिज़ॉल्वर ट्रेस टाइप करें और कैप्चर करें। अपेक्षित साक्ष्य में एक संक्षिप्त यूडीपी प्रतिक्रिया और उसके बाद एक सफल टीसीपी उत्तर शामिल होता है जब ग्राहक फ़ॉलबैक करता है।

इसके बाद चुनी गई सीमा पर केवल लैब के टीसीपी पथ को ब्लॉक करें। समान इनपुट और नियंत्रित कैश स्थिति के साथ क्वेरी को दोहराएं। कार्यशील यूडीपी एक्सचेंज के बावजूद अपेक्षित परिणाम उस सीमा पर असफल पूर्ण लुकअप है। परीक्षण के तुरंत बाद नियम बहाल करें. यह एक प्रयोगशाला विनिर्देश है, उत्पादन नेटवर्क सुरक्षा को बदलने की अनुमति नहीं है; इस आलेख के लिए फ़ायरवॉल-आधारित प्रक्रिया निष्पादित नहीं की गई है। नीचे दिया गया ऐतिहासिक सर्विस-क्लोज़ प्रयोग एक अलग, संकीर्ण परीक्षण है।

इन विकल्पों का समर्थन करने वाले स्थापित BIND dig संस्करण के साथ, dig @AUTH स्वामी TXT +bufsize=512 +अनदेखा करें स्वचालित टीसीपी पुनः प्रयास के बिना यूडीपी प्रतिक्रिया को उजागर कर सकता है खोदो @AUTH मालिक TXT +tcp स्पष्ट रूप से टीसीपी का अनुरोध करता है। प्रयोगशाला मूल्यों को प्रतिस्थापित करें, संस्करण की सहायता का निरीक्षण करें और पूर्ण आउटपुट बनाए रखें। इस समीक्षा में आदेशों को यहां क्रियान्वित नहीं किया गया है। बनाए रखा गया कस्टम-क्लाइंट कैप्चर डिग व्यवहार को मान्य नहीं करता है।

नीति को नया स्वरूप देने से पहले परिवहन की मरम्मत करें

सन्दर्भ: RFC 7766 §5, RFC 7208 §3.2, RFC 7208 §3.3.

पुष्टि करें कि सेवा दोनों ट्रांसपोर्टों को सुनती है और अधिकृत नेटवर्क पथ आवश्यक ट्रैफ़िक की अनुमति देता है। जिम्मेदार ऑपरेटर से फ़ायरवॉल या लोड-बैलेंसर परिवर्तनों की समीक्षा करवाएं। उसी उत्तर का पुनः परीक्षण करें और इच्छित पथ पर पूर्णता प्राप्त करें।

प्रतिक्रियाओं को परिचालनात्मक रूप से प्रबंधनीय रखना उपयोगी है, लेकिन TXT मान को एक रिकॉर्ड के अंदर स्ट्रिंग्स में विभाजित करने से ट्रांसपोर्ट दोषों को हल करने के लिए कुल DNS प्रतिक्रिया स्वाभाविक रूप से कम नहीं होती है। एक SPF नीति को कई नीति रिकॉर्ड में विभाजित करने से एक अलग मानक उल्लंघन होता है। समस्या को परिवहन साक्ष्य और फिर प्रतिनिधि प्रमाणीकरण परिणामों के साथ बंद करें, न कि छोटे दिखने वाले डैशबोर्ड मान के साथ।

ऐतिहासिक प्रयोगशाला साक्ष्य सुरक्षित रखे गए

बरकरार रखा गया कैप्चर दिनांक 7 नवंबर 2026 का है। निम्नलिखित उस ऐतिहासिक अवलोकन का वर्णन करता है, न कि किसी नए निष्पादन या EmailAuth.ai के परीक्षण का।

पृथक DNS सेवा ने जानबूझकर बड़े TXT प्रतिक्रिया के लिए खाली UDP उत्तर के साथ TC उत्सर्जित किया। टीसीपी पर वही प्रश्न टीसी स्पष्ट और 512 बाइट्स से अधिक तार की लंबाई के साथ पूर्ण उत्तर देता है। परीक्षण सेवा में स्वीकृत टीसीपी कनेक्शन बंद करने से क्लाइंट विफल हो गया। कोई फ़ायरवॉल या उत्पादन नेटवर्क सेटिंग नहीं बदली गई. यह फोर्स्ड ट्रंकेशन के तहत वास्तविक यूडीपी और टीसीपी एक्सचेंजों का परीक्षण करता है; यह DNS सर्वर की स्वचालित आकार सीमा या डिग के स्वयं के फ़ॉलबैक कार्यान्वयन का परीक्षण करने का दावा नहीं करता है। कैप्चर लेबल बड़े_udp_truncated हैं; बड़ा_tcp_पूर्ण; tcp_failure.json. ऐतिहासिक साक्ष्य के रूप में इस समीक्षा पैकेज में बनाए गए धावक और कच्ची कैद को शामिल किया गया है। उनका निरीक्षण किया गया, इस समीक्षा के लिए दोबारा नहीं चलाया गया। उत्पादन DNS , DNSSEC और SMTP परिणाम अप्रयुक्त रहते हैं।

[ ले लेना ]

एकाधिक SPF नीतियां बनाए बिना परिवहन विफलता को सुधारें।

[भूमिका के अनुसार]

आपके लिए इसका क्या मतलब है

व्यावहारिक अगले चरणों के लिए अपनी भूमिका चुनें।

आईटी/मेल एडमिन

विफल परिवहन पैर का पता लगाएं

स्टब, रिकर्सिव और अथॉरिटी पथों को अलग-अलग अवलोकन की आवश्यकता है।

अगले कदम

  1. टीसी और प्रतिक्रिया आकार कैप्चर करें।
  2. यूडीपी और टीसीपी की तुलना करें.
  3. रिज़ॉल्वर त्रुटि विवरण बनाए रखें.

सीआईएसओ/सेकऑप्स

नियंत्रण दोष इंजेक्शन

नेटवर्क नियम बदलने से परीक्षण क्वेरी से अधिक प्रभावित हो सकता है।

अगले कदम

  1. एक पृथक प्रयोगशाला का प्रयोग करें.
  2. सटीक नेटवर्क परिवर्तन स्वीकृत करें.
  3. बेसलाइन को पुनर्स्थापित और सत्यापित करें।

संस्थापक/गैर-तकनीकी

रुक-रुक कर होने वाले लुकअप को उपलब्धता दोष मानें

एक रिकॉर्ड मौजूद हो सकता है जबकि रिसीवर इसे पुनः प्राप्त नहीं कर सकता है।

अगले कदम

  1. एक नेटवर्क स्वामी नियुक्त करें.
  2. आपातकालीन नीति को कमजोर करने से बचें.
  3. पुनरुत्पादित पुनर्प्राप्ति साक्ष्य की आवश्यकता है.

[ पूछे जाने वाले प्रश्न ]

अक्सर पूछे जाने वाले प्रश्नों

टीसी का क्या मतलब है?

DNS प्रतिक्रिया छोटा कर दी गई है; इसे पूर्ण उत्तर न मानें.

RFC 1035 §4.1.1

क्या आधुनिक कार्यान्वयन के लिए DNS टीसीपी वैकल्पिक है?

RFC 7766 को सामान्य DNS कार्यान्वयन के लिए TCP समर्थन की आवश्यकता होती है।

RFC 7766 §5

क्या ईडीएनएस बड़ी यूडीपी डिलीवरी की गारंटी देता है?

नहीं, विज्ञापित पेलोड क्षमता पथ व्यवहार की गारंटी नहीं देती है।

RFC 6891 §6.2.3

क्या टाइमआउट का मतलब यह है कि कोई SPF रिकॉर्ड मौजूद नहीं है?

नहीं, परिवहन या समाधान विफलता प्रमाणित या सामान्य अनुपस्थिति से भिन्न होती है।

RFC 7208 §4.4

क्या मैं इसे दो SPF रिकॉर्ड के साथ ठीक कर सकता हूँ?

नहीं, एकाधिक चयनित SPF नीतियां स्थायी त्रुटि का कारण बनती हैं।

RFC 7208 §4.5

क्या स्थानीय टीसीपी की सफलता साबित करती है कि रिसीवर टीसीपी काम करता है?

नहीं, रिसीवर एक अलग रिज़ॉल्वर और नेटवर्क पथ का उपयोग कर सकता है।

क्या TXT स्ट्रिंग्स को विभाजित करने से पूरा संदेश कम हो जाता है?

यह एक रिकॉर्ड के भीतर प्रतिनिधित्व को सुरक्षित रखता है लेकिन सामान्य प्रतिक्रिया-आकार की मरम्मत नहीं है।

RFC 7208 §3.3

क्या इस आलेख के लिए फ़ायरवॉल बदला गया था?

बरकरार ऐतिहासिक परीक्षण में कोई फ़ायरवॉल नहीं बदला गया। एक लूपबैक परीक्षण सेवा ने स्वीकृत टीसीपी कनेक्शन बंद कर दिए; उत्पादन परिवहन और फ़ायरवॉल व्यवहार का परीक्षण नहीं किया गया।

[ सूत्रों का कहना है ]

सूत्रों का कहना है

  1. RFC 1035

    धारा §4.1.1

  2. RFC 6891

    धारा §6 · §6.2.3

  3. RFC 7208

    धारा §3.2 · §3.3 · §4.4 · §4.5

  4. RFC 7766

    धारा §5

  5. बाइंड 9 डिग मैनुअल

    धारा क्वेरी विकल्प

[ शब्दकोष ]

शब्दकोष

टीसी बिट
DNS हेडर फ़्लैग एक संक्षिप्त प्रतिक्रिया का संकेत देता है।

RFC 1035 §4.1.1

EDNS
DNS एक्सटेंशन तंत्र जो यूडीपी पेलोड क्षमता का विज्ञापन कर सकता है।

RFC 6891 §6

मैदान छोड़ना
अपूर्ण या असफल प्रयास के बाद किसी अन्य परिवहन पर बाद का आदान-प्रदान।

RFC 7766 §5

उद्यम उद्गम

शीर्ष वित्तीय संस्थान और सरकारें ही क्यों? अपने ईमेल सुरक्षा डैशबोर्ड हटा दिए।

पारंपरिक ईमेल प्रमाणीकरण प्लेटफ़ॉर्म आपको एक डैशबोर्ड बेचते हैं और आपके इंजीनियरों से काम करने के लिए कहते हैं। उच्च जोखिम वाले वातावरण में, मैन्युअल निरीक्षण का अर्थ है विलंबित प्रवर्तन, कॉन्फ़िगरेशन बहाव और अनियंत्रित छाया डोमेन।

EmailAuth एजेंटिक ईमेल उद्गम मंच है। हमारे एजेंट लागू करते हैं p=reject, तृतीय-पक्ष प्रेषकों को संरेखित रखें और अपने डोमेन को पूर्ण रूप से स्थानांतरित करें RFC 9989 अनुपालन, नया DMARC मानक, मानव-इन-द-लूप ऑडिटेबिलिटी के साथ।

सरकारों बड़े उद्यम टियर-1 वित्तीय संस्थान

सास · समर्पित किरायेदारी · एयर-गैप्ड ऑन-प्रिमाइसेस · BYOK एन्क्रिप्शन

ज्ञानधार