DNS कॉन्फ़िगर होने के कारण कुछ प्रेषकों से मेल नहीं मिल रहे हैं

Question

मैंने अपने Google Apps डोमेन के अजीब व्यवहार को देखा है। अधिकांश मेल के माध्यम से आप उम्मीद के रूप में आते हैं, लेकिन समय की अवधि में मैं इस निष्कर्ष पर पहुंचा हूं कि कुछ प्रेषकों से मेल के माध्यम से नहीं आते हैं। ऐसे एक प्रेषक की पहचान करने के बाद, जिसके मेल नहीं आएंगे, मैंने उससे कहा है कि मुझे ईमेल भेजने की कोशिश करें और "डिलीवरी फेलियर" को आगे बढ़ाने के लिए अपने नियमित जीमेल पर भेजें।

डिलीवरी की विफलता प्रतिक्रिया में निम्नलिखित स्निपेट शामिल थे:

----- सत्र का प्रतिलेख इस प्रकार है -----
<[e-mail]>... आस्थगित: कनेक्शन ghs.l.google.com के साथ समाप्त हो गया है।

इसने मुझे त्वरित खोज करके समस्या को पहचानने में मदद की जिसने मुझे Google Apps सहायता फ़ोरम पर इस पृष्ठ पर ले गया। वास्तव में, मैंने अपने डोमेन के लिए DNS रिकॉर्ड की जाँच की, और @ghs.google.com पर सेट किया गया। (CNAME), जो यह नहीं होना चाहिए। उसको बदलकर @ 74.125.93.121 (A)* समस्या का समाधान किया।

मैं समझता हूं कि जिन मामलों में मेल नहीं आएंगे, मेरे डोमेन नाम को CNAME लुकअप के माध्यम से विहित नाम से प्रतिस्थापित किया गया था, इसलिए मेल को [e-mail]इसके बजाय भेजा गया था [e-mail]। लेकिन यह प्रेषकों के विशाल बहुमत के लिए क्यों काम किया? क्या जिन मेलर्स के माध्यम से मेल नहीं आएंगे, वे कुछ अलग तरह के मेल प्रोटोकॉल, कुछ अजीब डीएनएस सेटिंग्स, या इसका क्या उपयोग कर सकते हैं?

मैं Google पर समस्या पर शोध करके क्या देख सकता हूं, यह एक व्यापक प्रसार वाला मुद्दा लगता है (बहुत सारे लोग जो बैटल से आने वाले ईमेल के बारे में शिकायत कर रहे हैं, यह एक लोकप्रिय उदाहरण नहीं होगा), केवल लोगों को ऐसा प्रतीत नहीं होता है यह जानने के लिए कि समस्या उनकी स्वयं की DNS सेटिंग्स में है, बल्कि तब प्रेषकों के पक्ष में है।

तो यह कैसे समझाया जा सकता है?

^{* मैंने जो भी यहाँ पढ़ा है उसकी वजह से मैंने इस IP का उपयोग किया है , लेकिन मुझे लगता है कि कोई भी IP यह ट्रिक करेगा। क्या कोई इसकी पुष्टि कर सकता है? ध्यान दें कि केवल @रिकॉर्ड को हटाने से समस्या का समाधान नहीं हुआ, इसे बदलना पड़ा।}

Answer 1

RFC 2821 "सिंपल मेल ट्रांसफर प्रोटोकॉल" सेक्शन 5 "एड्रेस रेजोल्यूशन एंड मेल हैंडलिंग":

लुकअप पहले नाम से जुड़े MX रिकॉर्ड का पता लगाने का प्रयास करता है। यदि इसके बजाय CNAME रिकॉर्ड पाया जाता है, तो परिणामी नाम को संसाधित किया जाता है जैसे कि यह प्रारंभिक नाम था।

सामान्य तौर पर, यह कैसे CNAME काम करता है। वे अक्सर गलत उपयोग, गलत समझ और गलत तरीके से लागू होते हैं। :-)

यदि आपका डोमेन example.com है, तो संभवतः आपके पास मौजूदा MX रिकॉर्ड सामान्य Google Apps होस्ट की ओर इशारा करते हैं।

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

ऐसा लगता है कि आपके पास भी इस तरह की प्रविष्टि थी:

example.com. CNAME ghs.l.google.com.

RFC 1034 "डोमेन कॉन्सेप्ट्स एंड फैसिलिटीज़" स्टेट्स इन सेक्शन 3.6.2 "एलियासेस एंड कैनोनिकल नेम" इस कॉन्फ़िगरेशन के खिलाफ सिफारिश करता है:

यदि CNAME RR नोड पर मौजूद है, तो कोई अन्य डेटा मौजूद नहीं होना चाहिए; यह सुनिश्चित करता है कि एक विहित नाम और उसके उपनामों का डेटा अलग-अलग नहीं हो सकता है।

आपके द्वारा चिपकाए गए त्रुटि के मामले में, मेल सर्वर और / या DNS सर्वर भेजने वाले छोर पर आपके डोमेन के लिए MX रिकॉर्ड (ओं) को देखने का प्रयास किया, example.com, और ghs.l.google की ओर इशारा करते हुए CNAME पाया। कॉम। इसके बाद ghs.l.google.com के लिए MX रिकॉर्ड देखने की कोशिश की गई। उस डोमेन में वर्तमान में कोई MX रिकॉर्ड नहीं है, इसलिए मेल सर्वर ghs.l.google.com के A रिकॉर्ड के माध्यम से गिर गया होगा। वह IP पता SMTP पोर्ट पर नहीं सुन रहा था, इसलिए परिणाम "ghs.l.n.com के साथ समयबद्ध कनेक्शन" त्रुटि है।

CNAME रिकॉर्ड को हटाकर, आपने अपनी मेल समस्याओं को ठीक कर लिया है। यदि आपके द्वारा अपने स्थान पर परिभाषित किया गया IP पता Google के अंत में बदल गया है, तो आप समस्याओं का सामना कर सकते हैं।

आप इसके बजाय www.example.com के लिए cname परिभाषित कर सकते हैं:

www.example.com. CNAME ghs.l.google.com.

और जिस भी IP पर आप example.com पर एक छोटा सा वेबसर्वर चलाएं, जो बस http://www.example.com/ पर एक HTTP रीडायरेक्ट करता है ।

यह कुछ आश्चर्य की बात है कि इसने भी काम किया। पोस्टेल के कानून को वहां कुछ श्रेय जाता है, मेरा मानना ​​है। :-)

RFC 1034 2.6.2 पर वापस:

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

इसलिए, इस मामले में यह तर्क दिया जा सकता है कि DNS सर्वर MX लुकअप में CNAME का पालन नहीं करेगा / करना चाहिए जब तक कि कोई MX रिकॉर्ड नहीं मिले।

मेल भेजते समय, Sendmail और qmail (और संभवतः अन्य) एक ईमेल पते के दाईं ओर उपयोग किए गए किसी भी CNAME को पुन: उपयोग करने के लिए डिफ़ॉल्ट नाम से कैनोनिकल नाम पर भेज देंगे।

वास्तव में, कुछ साइटों ने इस व्यवहार पर भरोसा किया। djb कुछ विस्तार से बताता है कि वह क्यों सोचता है कि लोगों को उसके "CNAME रिकॉर्ड इन मेल" दस्तावेज़ पर भरोसा करना बंद कर देना चाहिए ।

Comments

इस संपूर्ण उत्तर के लिए धन्यवाद! :) इसलिए संक्षेप में, आप कहेंगे कि यह कारण है कि यह कुछ के लिए काम करता है, लेकिन अन्य प्रेषकों के लिए नहीं, यह है कि वे विभिन्न एमटीए का उपयोग करते हैं जो एमएक्स रिकॉर्ड होने के बावजूद CNAME का अनुसरण करते हैं, जो कि RFC 1034 2.6.2 के अनुसार हो सकता है दोषपूर्ण व्यवहार माना जाता है?

— 0sh

मुझे यकीन नहीं है कि मैं व्यवहार को "दोषपूर्ण" कहूंगा। अन्य रिकॉर्ड (एमएक्स, एनएस, आदि) के साथ एक CNAME का कॉन्फ़िगरेशन कुछ ऐसा है जो टूट गया / अनुशंसित नहीं था, और अलग-अलग मेजबानों ने अलग-अलग तरीकों से इसकी व्याख्या की।

— जेफ

क्या यह एक 'आम तौर पर हाँ' है, लेकिन आपको यकीन नहीं है कि आप व्यवहार को दोषपूर्ण कहेंगे, या क्या मैं पूरी तरह से इस बिंदु को याद नहीं कर पाया?

— 0sh

बारीकियों में गड़बड़ है, इसलिए 'आम तौर पर हाँ' :-)

— जेफ

@एमएक्स रिकॉर्ड के लिए ईमेल पते के बाद एक एमटीए डोमेन को क्वेरी करना चाहिए और कुछ नहीं। यदि यह किसी भी हो जाता है, यह तुरंत सबसे कम एमएक्स रिकॉर्ड में से एक को डिलीवरी का प्रयास करना चाहिए। यदि सभी एमएक्स सर्वर कनेक्ट करने में विफल रहते हैं या एमएक्स रिकॉर्ड नहीं मिलते हैं, तो इसे डोमेन से कनेक्ट करने का प्रयास करना चाहिए। प्रश्न में एमटीए स्पष्ट रूप से जानकारी को हल करने में बहुत दूर जा रहा है, या यह निर्धारित करने के लिए नियमों का पालन नहीं कर रहा है कि किस मेल सर्वर से जुड़ना है। आपके डोमेन बिंदु को CNAME के ​​पास होने में कुछ भी गलत नहीं होना चाहिए - लेकिन आपको काम करने के लिए ईमेल के एमएक्स रिकॉर्ड की आवश्यकता है।

— एली सैंड

Answer 2

@एक BIND रिकॉर्ड में प्रतीक डोमेन लिखने की सिर्फ एक आशुलिपि तरीका है। यदि आप के लिए एक रिकॉर्ड बना रहे हैं example.com, तो @बस के लिए एक उपनाम है example.com। यह कहना कि @रिकॉर्ड एक आईपी होना था एक बयान है जो महत्वपूर्ण जानकारी को याद कर रहा है - आपने हमें यह नहीं बताया कि यह किस प्रकार का रिकॉर्ड था।

डिलीवरी रिपोर्ट से, ऐसा लगता है कि आपने शायद अपने DNS के साथ दूरस्थ मेल सर्वर के कारण अपने डोमेन को ghs.l.google.com पर फिर से लिखने के लिए किया है - बहुत अजीब (PS, एक रिकॉर्ड एक IP, एक CNAME रिकॉर्ड होना चाहिए एक आईपी या अन्य CNAME रिकॉर्ड नहीं होना चाहिए )।

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

यह मेरी तरह लगता है, बशर्ते बहुत कम जानकारी दी गई है, कि आपने Google के निर्देशों का पालन नहीं किया कि कैसे अपने DNS को ईमेल के लिए ठीक से कॉन्फ़िगर करें। संभवतः आपकी ज़ोन फ़ाइल में भी कुछ त्रुटियां हैं - क्या उन्होंने एक सक्षम ज़ोन व्यवस्थापक द्वारा जाँच की है।

Comments

सबसे पहले, मैंने उल्लेख किया कि @रिकॉर्ड CNAME प्रकार का था। दूसरा, डीएनएस I का उपयोग खरीद पर Google द्वारा आपूर्ति किया गया है, इसलिए मेरे पास ज़ोन फ़ाइल तक पहुंच भी नहीं है। मैंने Google द्वारा प्रदान की गई डिफ़ॉल्ट सेटिंग्स का उपयोग किया। और अंतिम लेकिन कम से कम नहीं, "प्रदान की गई बहुत कम जानकारी" स्पष्ट रूप से किसी के लिए सक्षम, संतोषजनक और (अपने खुद के विपरीत) सौहार्दपूर्ण उत्तर प्रदान करने के लिए पर्याप्त थी।

— 0sh

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

— एली सैंड