DNS: उप डोमेन जो एक MX रिकॉर्ड और CNAME दोनों की आवश्यकता है


17

हम कहते हैं कि हम अपने क्षेत्र mywebservice.com के मालिक हैं।

मैं चाहूंगा कि मेरे प्रत्येक ग्राहक को अपना स्वयं का उपडोमेन प्राप्त हो, जैसे customer.mywebservice.com।

customer.mywebservice.com को किसी दिए गए सर्वर ऑफसाइट में CNAME होना चाहिए। चूँकि वह साइट अपने उपकरणों का प्रबंधन करती है और किसी भी समय पते को बदल सकती है, CNAME एक आवश्यकता है।

लोगों को इनबॉक्स @customer.mywebservice.com पर ईमेल भेजने में भी सक्षम होना चाहिए, जिसके लिए एक सरल एमएक्स रिकॉर्ड की आवश्यकता होगी।

हालाँकि, और यह वह जगह है जहाँ मुझे कुछ मार्गदर्शन चाहिए:

RFC 1034 के अनुसार :

If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.

मैंने यह भी सत्यापित किया है कि मेरा DNS सर्वर कुछ भी सेवा करने से इंकार कर देगा, लेकिन मेजबानों के लिए एक CNAME जो उनका उपयोग करता है।

तो, ऐसा लगता है कि मेरे पास खोने की स्थिति हो सकती है। अगर मुझे MX रिकॉर्ड का उपयोग करना है, तो मुझे CNAME के ​​बजाय A का उपयोग करने की आवश्यकता है।

क्या कोई भी वर्कअराउंड के बारे में सोच सकता है? धन्यवाद!

जवाबों:


20

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

CNAME रिकॉर्ड का उपयोग करने के बजाय, आपको नामों को अलग करने के बजाय सीधे ग्राहक साइटों के आईपी पते के साथ 'ए' रिकॉर्ड का उपयोग करना होगा।


हाँ, मुझे लगता है कि मैं अभी इस का सामना करने जा रहा हूँ। धन्यवाद!
माइकल गोरसच

2
मुझे यह भी ध्यान देना चाहिए कि सड़क पर इसे पढ़ने वालों के लिए, इस सीमा का कारण यह है कि एक CNAME को होस्ट के लिए "कैनोनिकल नाम" का उल्लेख करना चाहिए। उदाहरण के लिए, यदि आपके पास एक होस्ट है, x2.example.com जो कि CNAME रिकॉर्ड है जो X1.example.com की ओर इशारा करता है, तो x2 को देखने वाले किसी भी रिज़ॉल्वर को CNAME देखना चाहिए, जो भी यह x2 के लिए X1 के साथ कर रहा है, उसे प्रतिस्थापित करें और शुरू करें । यदि आपके पास CNAME के ​​अलावा x2 के लिए MX रिकॉर्ड है, तो अगर X1 में MX भी होता है, तो एक मौका होता है कि वे भिन्न होंगे जो अवांछनीय है, इसलिए वे बस इसे अस्वीकार कर देते हैं।
जस्टिन स्कॉट

18

यहां बहुत सारे काम और शोध के बाद, मुझे एक स्वीकार्य समाधान मिला है। सबसे पहले, यह महत्वपूर्ण है कि हम सभी RFC का अनुसरण करें। मैंने अपने DNS सर्वर को RFC का उल्लंघन करने के लिए पैच किया, और मुझे पता चला कि कई अन्य प्रमुख DNS सर्वर परिवर्तन का सम्मान नहीं करेंगे।

CNAME को इंगित करने वाले होस्ट पर MX लगाने के लिए उपयुक्त चाल है। तो, अगर customer.mywebservice.com एक CNAME है जो कि रिकॉर्ड loadbalancer.mywebservice.com है, तो यह भी loadbalancer.mywebservice.com के लिए MX रिकॉर्ड बनाना उचित है। मैंने सत्यापित किया है कि यह सभी प्रमुख रिज़ॉल्वर के साथ काम करता है।

यदि customer.mywebservice.com के लिए MX क्वेरी बनाई गई है, तो रिज़ॉल्वर लाइब्रेरी CNAME का अनुसरण करेगी और अंतिम A रिकॉर्ड के लिए उचित MX प्राप्त करेगी। हुर्रे!


4

customer.mywebservice.com को किसी दिए गए सर्वर ऑफसाइट में CNAME होना चाहिए। चूँकि वह साइट अपने उपकरणों का प्रबंधन करती है और किसी भी समय पते को बदल सकती है, CNAME एक आवश्यकता है।

क्या कोई भी वर्कअराउंड के बारे में सोच सकता है? धन्यवाद!

आपके पास एक आवश्यकता है कि ग्राहकों को पता बदलने में सक्षम होना चाहिए, क्या आपने ग्राहक को अपने स्वयं के रिकॉर्ड को गतिशील रूप से अपडेट करने की अनुमति देने पर विचार किया है? डायनामिक डीएनएस के साथ आप ए रिकॉर्ड का उपयोग कर सकते हैं, और ग्राहक रिकॉर्ड को आवश्यकतानुसार बदल सकते हैं। यह थोड़ा काम करेगा, लेकिन आप प्रत्येक व्यक्ति को अलग-अलग क्षेत्र के रूप में उप-डोमेन दे सकते हैं ताकि आप यह सुनिश्चित कर सकें कि एक ग्राहक केवल अपने क्षेत्र को छू सकता है।

मैंने इसकी कोशिश नहीं की है, लेकिन प्रमाणीकरण से निपटने और अपने DNS सर्वर पर बहुत सारे ज़ोन स्थापित करने के बिना गतिशील अपडेट की सुविधा के लिए gnudip एक खुला स्रोत उपकरण प्रतीत होता है।


3

यदि आपका MX रिकॉर्ड इन सभी रिकॉर्डों के लिए समान होगा, तो आप XYZ.mywebservice.com को host.mywebservice.com पर पुनर्निर्देशित करने के लिए DNAME का उपयोग करने का प्रयास कर सकते हैं। Hosting.mywebservice.com के तहत अपने relavent MX और A रिकॉर्ड जोड़ें।

मुझे कहना होगा कि मैंने कभी भी उत्पादन में DNAME रिकॉर्ड का उपयोग नहीं किया है, लेकिन आप RFC2672 में उनके बारे में अधिक पढ़ सकते हैं ।


मैं अपने कुछ SSL डोमेन के साथ DNAME का उपयोग करने का प्रयास करना चाहता था, लेकिन मैंने सुना है कि पुराने DNS सर्वरों के साथ अभी भी समस्याएं हैं, आदि क्या यह प्रासंगिक है? या DNAME उत्पादन सर्वर पर उपयोग करने के लिए सुरक्षित है?
जुबान

अगर मुझे अनुमान लगाना होता, तो कई एप्लिकेशन DNAME रिकॉर्ड की उम्मीद नहीं करते और शायद उनका इस्तेमाल करते समय टूट जाते। क्या सभी मेल सर्वर DNAME को MX रिकॉर्ड देखने के लिए फॉलो करते हैं? मुझे नहीं पता, लेकिन उन्हें करना चाहिए। आपके SSL समस्या के लिए, DNS सर्वर जो DNAME को नहीं समझते हैं, इसके बजाय CNAME संदर्भ प्राप्त करना चाहिए। मैं इसे लागू करने से पहले इसका पूरी तरह से परीक्षण करूंगा।
डग लक्सम

आवेदन निश्चित रूप से DNAME रिकॉर्ड की प्रक्रिया के लिए नहीं है! यह केवल नाम सर्वर में किया जाता है।
bortzmeyer

3

क्या customer.mywebservice.com CNAME के ​​RHS में MX प्रविष्टि है?

यदि ऐसा है, तो मेल सर्वर उस एमएक्स का उपयोग करने के लिए मेल सर्वर का उपयोग करेगा। उम्मीद है कि आप इसे नियंत्रित कर सकते हैं।


1

माइकल गोर्सच का जवाब काफी हद तक सही है, CNAME -> A + MX श्रृंखला काम करती है ... ज्यादातर । हालांकि, यह कुछ एमटीए में कुछ बुरे व्यवहार को ट्रिगर करता है। मैंने इस समाधान को बड़े पैमाने पर सभ्य तरीके से चलाया है:

  • कुछ एमटीए केवल रिकॉर्ड खोजने से इनकार करेंगे।
  • अन्य लोग गलत तरीके से एक रिकॉर्ड को बदल देंगे जहां CNAME होना चाहिए: यानी मैंने "joe@foo.example.com" को मेल भेजा, जो CNAMES को web.example.com, जिसमें एक mail.example.com का MX है, और MTA ने लिफाफे के हेडर को "To: joe@web.example.com" के रूप में फिर से लिखा।

यह अभी तक स्पष्ट नहीं है कि ये मुद्दे कितने व्यापक हैं (google / hotmail / yahoo / etc) यह सब सही तरीके से व्यवहार करते हैं), लेकिन वे निश्चित रूप से बेहतर समाधानों की तलाश में हैं।


2
यह सही है; RFC5321- अनुरूप SMTP सर्वर के लिए प्रलेखित व्यवहार डोमेन के लिए MX रिकॉर्ड के अस्तित्व की जाँच करने के लिए है, और यदि वह विफल रहता है, तो A रिकॉर्ड के अस्तित्व की जाँच करें। यह व्यवहार वास्तविक, तकनीकी कारण है कि एमएक्स को CNAME नहीं होना चाहिए: यह पहले उपयोग योग्य उत्तर के बाद हल करना बंद कर देगा।
एडाप्ट्र

0

एक संभावित और वैध समाधान यह होगा कि आप अपने सभी ग्राहकों के लिए एक बेसिक होस्टनाम बनाएं और इसे ऑफ-साइट वेबसर्वर और आपके mx के aaaaa रिकॉर्ड में सेट करें, फिर अपने सभी कस्टमर्स डोमेन को उस सिंगल होस्टनाम पर CNAME करें। इस तरह से आपको केवल एक रिकॉर्ड बदलना होगा जब ऑफ-साइट का आईपी पता बदलता है।

यह एकमात्र वैध और संभव तरीका है, क्योंकि CNAME रिकॉर्डों के एक पूर्ण सेट के लिए एक उपनाम है, न कि केवल एक।


-4

एमएक्स और CNAME पूरी तरह से अलग रिकॉर्ड हैं - पहले एक दिए गए डोमेन के लिए मेल सर्वर को निर्धारित करता है, दूसरा एक डोमेन के लिए पता देता है। यह काम करना चाहिए:

@ SOA ns1.mywebservice.com पर। root.mywebservice.com। (
                        2009060201
                        12h
                        1 घंटे
                        1 माह
                        8h
)

                        NS ns1.mywebservice.com
                        NS ns2.mywebservice.com

ग्राहक CNAME offsite.host
ग्राहक MX 10 mail.server।

4
यह काम कर सकता है, लेकिन यह RFC1034 और RFC1219 का उल्लंघन करता है जो बताता है कि कोई अन्य संसाधन रिकॉर्ड CNAME के ​​समान नाम नहीं हो सकता है।
डग लक्सम

मेरा डीएनएस डेमॉन आरएफसी सख्त है, जो एमएक्स के लिए प्रतिक्रिया भेजने से इनकार कर देता है। मेरा मानना ​​है कि अगर हम इसे लागू करने के लिए क्लाइंट की ओर से कुछ संभावित कैशिंग मुद्दे हैं।
माइकल गोरसच

कौन सा डीएनएस डेमॉन? मैं BIND9 का उपयोग कर रहा हूं जो बिना किसी समस्या के उस कॉन्फ़िगरेशन के साथ काम करना चाहिए। शायद यह अपग्रेड करने का समय है? बड़ा इंफ्रास्ट्रक्चर, मुझे लगता है?
जुबान

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

@Maciej - यकीन है, आपका आधिकारिक सर्वर इन रिकॉर्डों को होस्ट करने में सक्षम हो सकता है। वे सबसे अधिक किसी भी पुनरावर्ती सर्वर से नर्क को भ्रमित करेंगे जो उनसे प्रश्न करता है।
अलनीतक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.