DNS को समझना: डोमेन रूट CNAME क्यों नहीं हो सकता और मुख्य DNS बेसिक्स

यह पोस्ट DNS, dig, A रिकॉर्ड्स, CNAME रिकॉर्ड्स, और ALIAS/ANAME रिकॉर्ड्स को एक शुरुआती के दृष्टिकोण से समझने के लिए उपरोक्त प्रश्न का उपयोग करेगा। तो चलिए शुरू करते हैं।

पहले, कुछ परिभाषाएं

• डोमेन नेम सिस्टम (DNS): एक मानव-स्मरणीय डोमेन नाम (example.com) को IP पते (93.184.216.34) में बदलने के लिए समग्र प्रणाली। IP पता एक सर्वर का है, आमतौर पर एक वेब सर्वर, जहां वेबपेज प्रदर्शित करने के लिए आवश्यक फाइलें संग्रहीत हैं।
• DNS सर्वर (इसे नेम सर्वर या नेमसर्वर के रूप में भी जाना जाता है): डोमेन पतों के बारे में जानकारी संग्रहीत करने के लिए DNS सॉफ्टवेयर का उपयोग करता है। कई स्तर हैं — प्रत्येक ISP से संबंधित, रूट (दुनिया भर में 13 कुल), टॉप लेवल डोमेन (TLD, जैसे '.com'), और डोमेन लेवल DNS सर्वर।
• डोमेन नाम: डोमेन (example) TLD (.com) के साथ संयुक्त। शब्द 'डोमेन' का उपयोग अक्सर डोमेन नाम के पर्याय के रूप में किया जाता है, हालांकि वे अलग हैं। जब आप किसी रजिस्ट्रार या रीसेलर से 'डोमेन' खरीदते हैं, तो आप एक विशिष्ट डोमेन नाम (example.com) के अधिकार खरीदते हैं, और कोई भी सबडोमेन जो आप बनाना चाहते हैं (my-site.example.com, mail.example.com, आदि)।

उच्च-स्तरीय क्वेरी प्रवाह

जब आप अपने ब्राउज़र में "example.com" टाइप करते हैं तो क्या होता है इसका उच्च-स्तरीय प्रवाह ISP, रूट, और TLD DNS सर्वर के हॉप्स को हटाकर नीचे सरलीकृत किया जा सकता है:

एक डोमेन में आमतौर पर दो या अधिक नेम सर्वर होते हैं, जिनमें डोमेन नाम (example.com) से संबंधित रिकॉर्ड होते हैं।

कई प्रकार के रिकॉर्ड संग्रहीत किए जा सकते हैं, जिनमें से अधिकांश प्रति प्रकार कई प्रविष्टियां हो सकती हैं:

• A: एड्रेस रिकॉर्ड जो डोमेन नाम को IP पते पर मैप करते हैं
• CNAME: कैनोनिकल नेम रिकॉर्ड। एक डोमेन नाम (या सबडोमेन नाम) को दूसरे के लिए उपनाम के रूप में उपयोग किया जाता है। हम इसे बाद में विस्तार से देखेंगे।
• MX: मेल एक्सचेंज रिकॉर्ड जो ईमेल डिलीवरी एजेंट्स को बताते हैं कि उन्हें आपका ईमेल कहां डिलीवर करना चाहिए
• TXT: लचीले टेक्स्ट रिकॉर्ड, विभिन्न उपयोगों के लिए स्ट्रिंग्स संग्रहीत करने के लिए
• SOA: डोमेन के शीर्ष स्तर पर रखा गया एकवचन स्टार्ट ऑफ अथॉरिटी रिकॉर्ड। डोमेन के बारे में विशिष्ट आवश्यक जानकारी रखता है, उदाहरण के लिए इसका प्राथमिक नेम सर्वर
• NS: डोमेन से जुड़े नेम सर्वर

जब आपका डिवाइस एक क्वेरी भेजता है जो नेम सर्वर तक पहुंचती है, तो सर्वर डोमेन के रिकॉर्ड नोड में एक A रिकॉर्ड और उससे जुड़ा संग्रहीत IP पता (example.com: 93.184.216.34) ढूंढता है। यह तब डिवाइस को वापस कर दिया जाता है, ताकि अनुरोधित वेबपेज या संसाधन को पुनः प्राप्त करने के लिए सही वेब सर्वर को अनुरोध भेजा जा सके।

‘dig’ का उपयोग करना

dig (डोमेन इन्फॉर्मेशन ग्रोपर) DNS सर्वर को क्वेरी करने के लिए एक कमांड-लाइन टूल है। इस कमांड का उपयोग आमतौर पर समस्या निवारण के लिए, या अब एक सिस्टम के सेटअप को अधिक समझने के लिए किया जाता है।

$ dig example.com के परिणामस्वरूप टर्मिनल पर एक लंबा रिस्पॉन्स प्रिंट होता है, जिसका डिफ़ॉल्ट आउटपुट यहां विस्तृत है, जिसमें हम ANSWER SECTION में रुचि रखते हैं।

;; ANSWER SECTION: example.com. 72703 IN A 93.184.216.34

और वहां हम देख सकते हैं कि example.com A रिकॉर्ड 93.184.216.34 देता है। कभी-कभी डोमेन में एक से अधिक A रिकॉर्ड होंगे, यदि एक से अधिक वेब सर्वर आवश्यक जानकारी प्रदान कर सकते हैं।

और भी बहुत कुछ है! यदि हम कुछ अन्य उदाहरण आज़माते हैं, तो हम जल्द ही देख सकते हैं कि एक और सामान्य रिकॉर्ड प्रकट होता है: CNAME।

$ dig www.skyscanner.net:

;; ANSWER SECTION: www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net. www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net. e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.

e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

+short फ्लैग का उपयोग करके हम स्पष्ट रूप से बने पथ को देख सकते हैं:

$ dig www.skyscanner.net +short

www.skyscanner.net.edgekey.net. e11316.a.akamaiedge.net. 23.217.6.192

CNAME

एक CNAME रिकॉर्ड एक डोमेन नाम को दूसरे कैनोनिकल (सच्चे) डोमेन के लिए उपनाम के रूप में उपयोग करने की अनुमति देता है।

जब DNS सर्वर एक CNAME रिकॉर्ड लौटाता है, तो वह उसे क्लाइंट को वापस नहीं करेगा। बल्कि यह फिर से लौटाए गए डोमेन नाम को देखेगा, और बदले में A रिकॉर्ड का IP पता लौटाएगा। यह श्रृंखला कई CNAME स्तरों तक गहरी जारी रह सकती है, लेकिन फिर कैशिंग होने से पहले कई लुकअप से मामूली प्रदर्शन हिट का सामना करती है।

इसका एक सरल उदाहरण यह हो सकता है यदि आपके पास एक सर्वर है जहां आप अपनी सभी तस्वीरें रखते हैं। आप सामान्य रूप से इसे photos.example.com के माध्यम से एक्सेस कर सकते हैं। हालांकि, आप इसे photographs.example.com के माध्यम से एक्सेस की अनुमति भी देना चाह सकते हैं। इसे संभव बनाने का एक तरीका photographs को photos पर इंगित करने वाला एक CNAME रिकॉर्ड जोड़ना है। इसका मतलब है कि जब कोई photographs.example.com पर जाता है तो उन्हें photos.example.com के समान सामग्री दी जाएगी।

क्वेरी $ dig photographs.example.com का उपयोग करके हम देखेंगे:

photographs.example.com IN CNAME photos.example.com photos.example.com IN A xx.xxx.x.xxx

यह ध्यान रखना महत्वपूर्ण है कि CNAME वह टुकड़ा है जो दाईं ओर है। बाईं ओर उपनाम नाम, या लेबल है।

एक और आम उपयोग www सबडोमेन के लिए है। example.com खरीदने के बाद आप शायद यह भी चाहेंगे कि जो उपयोगकर्ता www.example.com टाइप करते हैं वे वही सामग्री देखें।

यह ध्यान देने योग्य है कि example.com को एपेक्स, रूट, या नेकेड डोमेन नाम कहा जा सकता है।

एक विकल्प एक और A रिकॉर्ड सेट करना होगा, जो example.com के समान IP पते पर इंगित करता है। यह पूरी तरह से वैध है, और असली example.com यही करता है, लेकिन यह अच्छी तरह से स्केल नहीं करता। क्या होता है यदि आपको उस IP पते को अपडेट करने की आवश्यकता है जिस पर example.com इंगित करता है? आपको www सबडोमेन के लिए भी इसे अपडेट करना होगा, और आपके द्वारा उपयोग किए जा सकने वाले किसी अन्य के लिए।

यदि www.example.com को example.com पर इंगित करने के लिए एक CNAME रिकॉर्ड का उपयोग किया जाता है तो केवल रूट डोमेन को अपडेट करना होगा, क्योंकि अन्य सभी नोड्स उस पर इंगित करते हैं।

CNAME सीमाएं

जब DNS मानक लिखे गए थे, तो उनके उपयोग को नियंत्रित करने के लिए कुछ नियम निर्धारित किए गए थे। RFC 1912 और RFC 2181 निर्धारित करते हैं कि:

• SOA और NS रिकॉर्ड रूट डोमेन पर मौजूद होने के लिए अनिवार्य हैं
• CNAME रिकॉर्ड केवल एकल रिकॉर्ड के रूप में मौजूद हो सकते हैं और किसी अन्य संसाधन रिकॉर्ड के साथ संयुक्त नहीं किए जा सकते (DNSSEC SIG, NXT, और KEY RR रिकॉर्ड को छोड़कर)

यह रूट डोमेन पर CNAME के उपयोग को बाहर करता है, क्योंकि दोनों नियम एक दूसरे का विरोध करेंगे।

यहां महत्वपूर्ण बात यह है कि यह एक संविदात्मक सीमा है, तकनीकी नहीं। रूट पर CNAME का उपयोग करना संभव है, लेकिन यह अप्रत्याशित त्रुटियों का परिणाम हो सकता है, क्योंकि यह व्यवहार के अपेक्षित अनुबंध को तोड़ रहा है।

Cloudflare द्वारा बताया गया इसका एक उदाहरण, Microsoft Exchange मेल सर्वर के साथ उनके द्वारा सामना की गई समस्याओं का वर्णन करता है जब उन्होंने अपने रूट डोमेन पर CNAME का उपयोग किया था:

डोमेन आमतौर पर MX रिकॉर्ड के रूप में जानी जाने वाली चीज़ के माध्यम से अपने ईमेल को संभालने वाले सर्वर को नामित करते हैं। समस्या यह थी कि Exchange सर्वर … रूट रिकॉर्ड पर CNAME को चुन सकते थे और फिर MX रिकॉर्ड पर सेट CNAME का ठीक से सम्मान नहीं कर सकते थे। आप वास्तव में Exchange को दोष नहीं दे सकते। वे DNS विशिष्टता द्वारा निर्धारित धारणाओं के तहत काम कर रहे थे।

यहां आप कई सर्वर सॉफ्टवेयर्स या लाइब्रेरीज में दिखाई देने वाले नकारात्मक पहलू को देखते हैं। क्योंकि एक मानक है कि एक CNAME एक नोड पर एकमात्र रिकॉर्ड होना चाहिए, कोई अन्य रिकॉर्ड नहीं खोजे जाते। अन्य सभी रिकॉर्ड चेतावनी या त्रुटि संदेशों के बिना चुपचाप अनदेखा कर दिए जाएंगे। यहां तक कि अगर ईमेल प्राप्त करने के लिए एक MX रिकॉर्ड सेट किया गया था, तो MX को नजरअंदाज कर दिया जाएगा जैसे कि यह मौजूद नहीं है क्योंकि CNAME का पहले मूल्यांकन किया जाता है। वही सच है अगर वहां एक A रिकॉर्ड था: CNAME प्राथमिकता लेगा और A रिकॉर्ड पढ़ा नहीं जाएगा।

आधुनिक इंटरनेट

तो यह एक समस्या क्यों है? आप अपने रूट डोमेन के लिए CNAME का उपयोग क्यों करना चाहेंगे? निश्चित रूप से वह आपके कंटेंट को होस्ट करने वाले वेब सर्वर के IP पते की तलाश में पथ का अंत है?

आधुनिक इंटरनेट परिदृश्य में, अब ऐसा नहीं है। दुनिया बहुत अलग है जब DNS मानक लिखे गए थे।

आप हेरोकू जैसे प्लेटफॉर्म एज अ सर्विस (PaaS) प्रदाता का उपयोग करना चुन सकते हैं और अपने कंटेंट को उनके वेब सर्वर पर स्टोर कर सकते हैं। आप कंटेंट को नियंत्रित करते हैं, लेकिन इन्फ्रास्ट्रक्चर को नहीं, और PaaS प्रदाता नेटवर्क रखरखाव का भारी काम करता है। वे आमतौर पर आपको एक URL (my-app.herokuapp.com) प्रदान करते हैं जो उनके रूट डोमेन का एक सबडोमेन है, और आप अपने कंटेंट के वेब सर्वर(एस) के IP पते देख सकते हैं। लेकिन ये पूरी तरह से PaaS प्रदाता के नियंत्रण में हैं, और बिना किसी चेतावनी के बदल जाएंगे।

PaaS प्रदाता द्वारा किए गए बैकएंड परिवर्तनों का पैमाना और आवृत्ति आपके रूट डोमेन A रिकॉर्ड को एक ही IP पते पर इंगित करते हुए बनाए रखना कठिन बना सकती है। आदर्श रूप से आप यह करना चाहेंगे:

example.com IN CNAME my-app.herokuapp.com.www.example.com IN CNAME my-app.herokuapp.com.example.com IN CNAME my-app.herokuapp.com. www.example.com IN CNAME my-app.herokuapp.com.

ताकि Heroku (या आपका चुना हुआ होस्ट प्रदाता) आपकी ओर से किसी भी बदलाव के बिना CNAME के इंगित A रिकॉर्ड को अपडेट करने का प्रबंधन कर सके। हालांकि, जैसा कि हम अब जानते हैं, यह DNS विशिष्टता को तोड़ता है, इसलिए यह एक बहुत बुरा विचार है।

इसे केवल example.com से www.example.com. पर 301/302 रीडायरेक्ट लागू करना संभव है। हालांकि, वह निर्देश या तो वेब सर्वर पर होता है (इसलिए अभी भी DNS में एक निश्चित A रिकॉर्ड का उपयोग करने की समस्या है जो उस वेब सर्वर को इंगित करता है), या एक कस्टम DNS प्रदाता रीडायरेक्ट (जो HTTPS के साथ जटिलताओं का सामना करता है)।

इसका साइड इफेक्ट यह भी है कि URL बार में आपके द्वारा देखे जाने वाले डोमेन को बदल देता है, जो आप नहीं चाहते होंगे। यह विधि तब के लिए अभिप्रेत है जब आपकी वेबसाइट स्थायी रूप से चली गई हो, या जब आप SEO रैंकिंग को संरक्षित करने की कोशिश कर रहे हों, बजाय हमारी समस्या को हल करने के कि एक जटिल बदलते बैकएंड को स्केलेबल तरीके से इंगित किया जाए।

समाधान

कई DNS प्रदाताओं ने अब इस समस्या को हल करने के लिए कस्टम समाधान विकसित किए हैं, जिनमें शामिल हैं:

• ALIAS DNSimple पर
• ANAME DNS Made Easy पर
• ANAME easyDNS पर
• CNAME (वर्चुअल) CloudFlare पर

ये सभी वर्चुअल रिकॉर्ड प्रकार हैं जो CNAME जैसा व्यवहार प्रदान करते हैं, बिना किसी नकारात्मक पहलू के। सटीक कार्यान्वयन भिन्न हो सकता है, लेकिन उच्च स्तर पर जब DNS सर्वर इन वर्चुअल रिकॉर्ड प्रकारों में से एक को देखता है, तो यह DNS रिज़ॉल्वर के रूप में कार्य करता है। यह उपनाम द्वारा बनाई गई श्रृंखला का अनुसरण करता है जब तक कि यह A रिकॉर्ड (या रिकॉर्ड्स) पर हल नहीं हो जाता और इन A रिकॉर्ड्स को DNS सर्वर को वापस करता है। यह CNAME श्रृंखला को वापस लौटाए गए A रिकॉर्ड(एस) में "समतल" करता है, और भेजी गई क्वेरी से अप्रभेद्य है। क्वेरी केवल एक शुद्ध A रिकॉर्ड देखती है, जो DNS विशिष्टता को नहीं तोड़ता, और CNAME के किसी भी नुकसान को नहीं झेलता।

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

DNSimple सेटअप के लिए, हम नीचे दिए अनुसार कॉन्फिगर करेंगे। इस समाधान में डोमेन नाम उपनाम के सभी फायदे हैं, और रूट स्तर पर इसका उपयोग करने के किसी भी जोखिम नहीं।

example.com IN ALIAS my-app.herokuapp.com.www.example.com IN CNAME my-app.herokuapp.com.

पढ़ने के लिए धन्यवाद! ?

हमेशा की तरह, किसी भी सुधार या अतिरिक्त बिंदुओं के लिए खुला।

संसाधन

• DNS सर्वर क्या है
• DNS नेम सर्वर सेट अप करें
• DNSimple सपोर्ट पेज और ALIAS ब्लॉग
• Cloudflare सपोर्ट और CNAME ब्लॉग
• dig HowTo
• कई बेहतरीन Stack Overflow या StackExchange पोस्ट
• अच्छी तरह से लिखे गए Wikipedia लेख
• Netlify ब्लॉग 'To www or not www'