[ DNS और डोमेन ]

अनेक आधिकारिक नाम सर्वरों से उत्तरों की तुलना करें

हानिरहित उत्तर क्रम से वास्तविक प्रकाशन अंतर को अलग करने के लिए आधिकारिक सर्वरों में सटीक रिकॉर्ड सेट की तुलना करें।

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

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

  • प्रत्येक विज्ञापित प्राधिकारी समापन बिंदु से पूर्ण प्रतिक्रियाओं की तुलना करें।
  • TXT स्ट्रिंग सीमाओं को बदले बिना रिकॉर्ड-सेट क्रम को सामान्य करें।
  • SOA धारावाहिकों का मिलान ज़ोन सामग्री के मेल को साबित नहीं करता है।
इस पेज पर

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

स्थापित करें कि कौन से सर्वर मायने रखते हैं

सन्दर्भ: RFC 1034 §4.2, RFC 1035 §4.1.1.

मूल प्रतिनिधिमंडल पढ़ें और इसकी तुलना चाइल्ड एपेक्स एनएस सेट से करें। विज्ञापित सर्वर नामों को पते में हल करें और रिकॉर्ड करें कि कौन सा पता पूछा गया था। एक होस्टनाम में कई पते हो सकते हैं, और एनीकास्ट एक ही पते को विभिन्न उदाहरणों पर रूट कर सकता है। इसलिए एक सफल क्वेरी यह साबित नहीं करती कि हर संभावित बैकएंड चालू है।

जैसे प्रत्यक्ष गैर-पुनरावर्ती क्वेरी का उपयोग करें खोदो @SERVER_IP _dmarc.example .test। TXT +नोरेकर्स. प्रतिक्रिया कोड और एए ध्वज, उत्तर और प्राधिकरण अनुभाग, और किसी भी उपनाम का निरीक्षण करें। जिस सर्वर से आप आधिकारिक होने की उम्मीद करते हैं, उससे रेफरल या गैर-आधिकारिक प्रतिक्रिया पुरानी सामग्री वाले आधिकारिक उत्तर से अलग खोज है।

संरचना को नष्ट किए बिना डेटा की तुलना करें

सन्दर्भ: RFC 2181 §5, RFC 1035 §3.3.14, RFC 1982 §3.2.

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

सहायक संदर्भ के रूप में SOA को क्वेरी करें। एक SOA सीरियल ज़ोन का हैश नहीं है। मिलान करने वाले धारावाहिक मिलान रिकॉर्ड साबित नहीं कर सकते हैं, और एक बड़ा मुद्रित पूर्णांक सार्वभौमिक रूप से नया नहीं है क्योंकि धारावाहिक अंकगणित लपेटता है। RFC 1982 के तहत, सीरियल स्पेस के ठीक आधे हिस्से की तुलना अपरिभाषित है; उन्हें नए/पुराने ऑर्डर देने के लिए बाध्य न करें। अनुरोधित डेटा की सीधे तुलना करें और अंतर समझाने के लिए प्रदाता के स्थानांतरण या प्रकाशन लॉग का उपयोग करें।

असहमति और हानिरहित पुनर्व्यवस्था को पुन: प्रस्तुत करें

उदाहरण के लिए दो अलग-अलग प्राधिकरण बनाएं। परीक्षण। दोनों एक ही MX सेट प्रकाशित करते हैं, लेकिन इसके रिकॉर्ड अलग-अलग क्रम में लौटाते हैं। अपेक्षित सामान्यीकृत तुलना बराबर है. इसके बाद अधिकार ए दें _dmarc.example.test TXT "v=DMARC1; p=none" और बी _dmarc.example.test TXT "v=DMARC1; p=reject". अपेक्षित तुलना असमान है, भले ही दोनों SOA धारावाहिक जानबूझकर समान हों।

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

प्रकाशन पथ को सुधारें

सन्दर्भ: RFC 1034 §4.3.5, RFC 8767 §4.

जांचें कि क्या एक सर्वर पुराना सेकेंडरी है, एक सेवानिवृत्त प्रदाता अभी भी प्रतिनिधिमंडल में मौजूद है, या एक गंतव्य जिसे कभी भी इच्छित अपडेट प्राप्त नहीं हुआ है। कई पैनलों में यादृच्छिक बार-बार संपादन करने के बजाय समर्थित प्रकाशन या स्थानांतरण पथ की मरम्मत करें। परिवर्तन के बाद प्रत्येक परीक्षण प्राधिकारी पर समान अपेक्षित डेटा की पुष्टि करें।

किसी भी कास्ट या स्प्लिट व्यू पर संदेह होने पर प्रासंगिक नेटवर्क से अवलोकन दोहराएँ। जानबूझकर की गई नीति को आकस्मिक सार्वजनिक असंगति से अलग करें। पुनरावर्ती और प्रतिनिधि मेल साक्ष्य के साथ समाप्त करें क्योंकि अकेले आधिकारिक समझौता पहले से ही कैश किए गए उत्तरों को समाप्त नहीं कर सकता है या किसी संदेश के प्रमाणीकरण को साबित नहीं कर सकता है।

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

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

दो लूपबैक फिक्स्ड-ज़ोन प्राधिकारियों को वास्तविक यूडीपी क्वेरीज़ लौटा दी गईं p=none और p=reject उसी पूर्ण TXT स्वामी के लिए। दोनों प्रतिक्रियाओं में AA सेट था। कैप्चर प्रत्येक समापन बिंदु, यूटीसी समय, टीटीएल, प्रतिक्रिया प्रकार, कोड और वायर बाइट्स को संरक्षित करता है। यह वास्तविक रूप से देखी गई प्रयोगशाला असंगतता को प्रदर्शित करता है; यह किसी सार्वजनिक एनीकास्ट सेवा का सर्वेक्षण नहीं करता है। कैप्चर लेबल अथॉरिटी_ए_पॉलिसी हैं; प्राधिकरण_बी_नीति. ऐतिहासिक साक्ष्य के रूप में इस समीक्षा पैकेज में बनाए गए धावक और कच्ची कैद को शामिल किया गया है। उनका निरीक्षण किया गया, इस समीक्षा के लिए दोबारा नहीं चलाया गया। उत्पादन DNS , DNSSEC और SMTP परिणाम अप्रयुक्त रहते हैं।

[ ले लेना ]

SOA धारावाहिकों का मिलान ज़ोन सामग्री के मेल को साबित नहीं करता है।

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

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

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

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

संरचित रिकॉर्ड की तुलना करें

फ़ॉर्मेटिंग अंतर वास्तविक बेमेल को छुपा या बढ़ा-चढ़ाकर पेश कर सकते हैं।

अगले कदम

  1. प्रत्येक विज्ञापित समापन बिंदु को क्वेरी करें।
  2. झंडे और प्रतिक्रिया कोड सुरक्षित रखें.
  3. TXT सीमाएँ अक्षुण्ण रखें।

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

अधिकार को विश्वास से अलग करें

एक आधिकारिक ध्वज क्रिप्टोग्राफ़िक सत्यापन साबित नहीं करता है।

अगले कदम

  1. अस्पष्टीकृत विचारों की जाँच करें।
  2. कच्चे सबूत रखें.
  3. DNSSEC अलग से सत्यापित करें.

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

सभी मार्गों से साक्ष्य की आवश्यकता है

एक हरा लुकअप एक पुराने प्राधिकारी को मिस कर सकता है।

अगले कदम

  1. DNS स्वामित्व निर्दिष्ट करें.
  2. प्रदाता संक्रमण इतिहास बनाए रखें.
  3. घटना बंद करने के मानदंड निर्धारित करें.

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

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

क्या रिकॉर्ड ऑर्डर मायने रखता है?

किसी अव्यवस्थित DNS रिकॉर्ड सेट की तुलना करने के लिए नहीं; एक रिकॉर्ड के भीतर TXT स्ट्रिंग क्रम अभी भी मायने रखता है।

RFC 2181 §5 RFC 1035 §3.3.14

क्या समान SOA सीरियल समान सामग्री साबित करता है?

नहीं, वास्तविक अनुरोधित रिकॉर्ड की तुलना करें।

RFC 1982 §3.2

क्या मुझे अकेले +शॉर्ट का उपयोग करना चाहिए?

सबूत पकड़ने के लिए नहीं. झंडे, कोड और अनुभाग भी बनाए रखें।

क्या एक सर्वर नाम एकाधिक समापन बिंदुओं का प्रतिनिधित्व कर सकता है?

हाँ। यह एकाधिक पतों का समाधान कर सकता है या एनीकास्ट का उपयोग कर सकता है।

AA का क्या मतलब है?

प्रासंगिक संदर्भ में पूछे गए नाम के लिए उत्तर को आधिकारिक के रूप में चिह्नित किया गया है; यह DNSSEC सत्यापन नहीं है.

RFC 1035 §4.1.1

क्या जानबूझकर DNS दृश्य भिन्न हो सकते हैं?

हाँ। अंतर को आकस्मिक कहने से पहले दृश्य नीति और क्वेरी की उत्पत्ति का दस्तावेजीकरण करें।

क्या एक सर्वर को ठीक करने से पुनरावर्ती कैश साफ़ हो जाएगा?

नहीं, पहले से संग्रहीत डेटा बना रह सकता है।

RFC 8767 §4

समापन साक्ष्य क्या है?

इच्छित प्राधिकारी डेटा का मिलान, एक स्पष्ट प्रकाशन स्थिति और अनुवर्ती रिज़ॉल्वर और मेल जांच।

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

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

  1. RFC 1034

    धारा §4.2 · §4.3.5

  2. RFC 1035

    धारा §3.3.14 · §4.1.1

  3. RFC 1982

    धारा §3.2

  4. RFC 2181

    धारा §5

  5. RFC 8767

    धारा §4

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

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

[ शब्दकोष ]

शब्दकोष

एए झंडा
DNS प्रतिक्रिया में आधिकारिक-उत्तर ध्वज।

RFC 1035 §4.1.1

आरआरसेट
एक ही स्वामी, वर्ग और प्रकार के रिकॉर्ड।

RFC 2181 §5

एनीकास्ट
एक ही सेवा पते को विभिन्न नेटवर्क स्थानों पर रूट करना।

उद्यम उद्गम

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

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

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

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

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

ज्ञानधार