DNS क्या है और VPS के लिए इसे कैसे कॉन्फ़िगर करें

DNS क्या है, और आपका डोमेन अभी तक आपके VPS तक क्यों नहीं पहुँच रहा है

DNS (domain name system) example.com जैसे नाम को 203.0.113.10 जैसे IP (internet protocol) पते में बदल देता है। ब्राउज़र किसी नाम से कनेक्ट नहीं हो सकता है। यह एक पते से कनेक्ट होता है, इसलिए हर पेज लोड एक DNS प्रश्न और उत्तर के साथ शुरू होता है। यदि आपने अभी-अभी एक डोमेन और अपना खुद का VPS खरीदा है, और कुछ भी लोड नहीं हो रहा है, तो दो में से एक बात सही है: अभी तक कोई रिकॉर्ड नाम को आपके सर्वर के पते से नहीं जोड़ रहा है, या कोई रिकॉर्ड मौजूद है लेकिन रास्ते में कहीं से पुराना उत्तर मिल रहा है।

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

यहाँ हर जाँच dig का उपयोग करती है, जो एक नए Ubuntu या Debian मशीन पर डिफ़ॉल्ट रूप से इंस्टॉल नहीं होता है।

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameservers, DNS host: किसे edit करें

ये तीन नाम अलग-अलग कार्यों को दर्शाते हैं। इन्हें आपस में मिला देना सबसे आम कारण है कि क्यों एक बदलाव करने के बाद भी कुछ नहीं होता।

• Registrar वह कंपनी है जिससे आपने domain खरीदा है। इसका मुख्य कार्य delegation है: यह उस registry को बताता है जो आपके TLD (top-level domain, यानी .com हिस्सा) को चलाती है कि आपके domain के लिए कौन से nameservers authoritative हैं।
• Authoritative nameservers आपके zone के लिए वास्तविक records रखते हैं। एक zone आपका domain और उसके अंतर्गत आने वाले नाम होते हैं।
• DNS host वह है जो उन nameservers को संचालित करता है। यह registrar हो सकता है, कोई अलग provider हो सकता है, या आपके द्वारा स्वामित्व वाले सर्वर पर चल रहा bind9 हो सकता है।

आप registrar के पास खरीदारी करते हैं। आप DNS host पर edit करते हैं। यदि आपने अपना domain किसी दूसरे provider के nameservers पर move कर लिया है, तो भी registrar का अपना DNS panel आपको एक zone दिखाएगा, आपके edits को save करेगा, और internet पर कोई भी उस zone से सवाल नहीं पूछेगा। records असली हैं। उन्हें बस कभी देखा ही नहीं जाता।

पता लगाएँ कि दुनिया कहाँ पूछ रही है:

dig example.com NS +short
dig +trace example.com

पहली command उन nameservers को print करती है जो आज domain के लिए जवाब दे रहे हैं। दूसरी command root servers से शुरू होकर chain को follow करती है और उस referral को print करती है जो TLD servers देते हैं, जो कि वह delegation है जिसे आपका registrar नियंत्रित करता है। यदि वे नाम किसी ऐसे provider के हैं जिसे आप नहीं पहचानते, तो उस provider के पास ही वह panel है जिसकी आपको आवश्यकता है।

एक सिंगल लुकअप कैसे काम करता है

इसमें चार पक्ष शामिल होते हैं, और प्रत्येक पक्ष जो सीखता है उसकी एक कॉपी अपने पास रखता है।

1. आपकी मशीन पर मौजूद stub resolver। यह कोई खोज नहीं करता है। यह एक कॉन्फ़िगर किए गए सर्वर से पूछता है और उत्तर पर विश्वास कर लेता है। Ubuntu पर, /etc/resolv.conf आमतौर पर /run/systemd/resolve/stub-resolv.conf का एक symlink होता है और 127.0.0.53 को नाम देता है, जो कि स्थानीय रूप से अपने स्वयं के कैश के साथ चल रहा systemd-resolved है।
2. recursive resolver। यह वह resolver है जिसे आपका ISP (इंटरनेट सेवा प्रदाता) चलाता है, या 1.1.1.1 जैसी कोई सार्वजनिक सेवा, या जिसे आप स्वयं चलाते हैं। यह उत्तर खोजने का वास्तविक कार्य करता है।
3. root और TLD सर्वर। recursive resolver एक root सर्वर से पूछता है, जो आपका पता नहीं जानता है लेकिन .com सर्वरों के लिए एक रेफरल के साथ उत्तर देता है। वे आपके nameservers के लिए रेफरल के साथ उत्तर देते हैं।
4. authoritative nameserver। यह किसी से नहीं पूछता है। यह आपके ज़ोन से उत्तर देता है और उत्तर को authoritative के रूप में चिह्नित करता है।

dig +trace example.com आपको यह प्रक्रिया दिखाता है, क्योंकि यह सीधे root से शुरू होता है और कैश से पूछने के बजाय प्रत्येक रेफरल को प्रिंट करता है। यह देखने का सबसे तेज़ तरीका है कि क्या डेलिगेशन और ज़ोन एक-दूसरे से सहमत हैं।

सर्वर चलाते समय महत्वपूर्ण DNS रिकॉर्ड्स

• A: एक नाम को IPv4 पते से जोड़ता है। example.com. A 203.0.113.10। यह वह रिकॉर्ड है जो आपके डोमेन को आपके VPS की ओर निर्देशित करता है।
• AAAA: एक नाम को IPv6 पते से जोड़ता है, जैसे कि 2001:db8::10। इसे केवल तभी प्रकाशित करें जब आपकी सर्विस वास्तव में उस पते पर listen कर रही हो। IPv6 नेटवर्क पर क्लाइंट्स सबसे पहले AAAA उत्तर का प्रयास करते हैं, इसलिए जिस पते पर कोई उत्तर नहीं मिलता, वह हर विजिट में देरी (stall) पैदा करता है।
• CNAME: एक नाम से दूसरे नाम का उपनाम (alias)। www.example.com. CNAME example.com., www के विजिटर्स को उस पते पर भेजता है जिस पर bare domain resolve होता है। एक CNAME apex (bare example.com) पर नहीं रह सकता, क्योंकि apex के पास अपना स्वयं का SOA (start of authority) और NS रिकॉर्ड होना चाहिए, और CNAME को किसी अन्य रिकॉर्ड के साथ नाम साझा करने की अनुमति नहीं है। प्रोवाइडर्स ALIAS, ANAME या CNAME flattening जैसे नामों के तहत इसके विकल्प प्रदान करते हैं।
• MX: जहाँ डोमेन के लिए मेल डिलीवर किया जाता है। इसमें एक hostname और एक preference नंबर होता है, और कम नंबर वाले को पहले आजमाया जाता है। एक MX को ऐसे नाम की ओर इशारा करना चाहिए जिसका अपना address record हो। इसे CNAME की ओर पॉइंट करना अमान्य है, और कुछ भेजने वाले सर्वर इसे अस्वीकार कर देंगे।
• TXT: फ्री टेक्स्ट, जिसका उपयोग प्रमाण और नीति के लिए किया जाता है। मेल ऑथेंटिकेशन रिकॉर्ड्स (SPF, DKIM, DMARC) यहीं रहते हैं, साथ ही ACME (automatic certificate management environment) टोकन भी, जो वाइल्डकार्ड सर्टिफिकेट जारी करता है।
• NS: कौन से nameservers ज़ोन को सर्व करते हैं। वह कॉपी जो यह तय करती है कि दुनिया कहाँ पूछेगी, वह parent zone में रहती है और आपके रजिस्ट्रार के डेलिगेशन से आती है, न कि आपके अपने ज़ोन के अंदर वाली कॉपी से।

दो विवरण रिकॉर्ड प्रकारों की तुलना में अधिक भ्रम पैदा करते हैं। डॉट पर समाप्त होने वाला नाम absolute होता है, इसलिए www.example.com. का अर्थ बिल्कुल वही है और उससे अधिक कुछ नहीं। अधिकांश पैनल एक relative नाम की अपेक्षा करते हैं और आपके लिए डोमेन जोड़ देते हैं, इसलिए नाम बॉक्स में www.example.com टाइप करने से आपको www.example.com.example.com मिलता है, जो किसी के लिए भी resolve नहीं होता। दूसरा विवरण @ है, जिसका अर्थ लगभग हर पैनल में apex होता है: डोमेन अपने आप में, बिना किसी सबडोमेन के।

अपने VPS पर A record पॉइंट करें

सबसे पहले वह IP address पता करें जिसे इंटरनेट आपके सर्वर के लिए देखता है:

curl -4 https://ifconfig.me
ip -brief -4 address show

इसके बाद अपने DNS host पर एक record बनाएँ: type A, name @, value में वह IP address डालें, और TTL (time to live) 300 रखें। www के लिए एक दूसरा record जोड़ें, या तो उसी address के साथ एक और A, या फिर apex पर पॉइंट करता हुआ एक CNAME।

अब यह सत्यापित करें कि यह resolve हो रहा है या नहीं, इसे सर्वर के बजाय अपने लैपटॉप से करना बेहतर है:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

पहली कमांड आपके मशीन के सामान्य पाथ का उपयोग करती है, जिसमें caches भी शामिल हैं। दूसरी कमांड आपकी local cache को छोड़ देती है और एक public recursive resolver से पूछती है। तीसरी कमांड सीधे आपके authoritative nameserver से पूछती है, इसलिए इसका उत्तर बिना किसी cache के वर्तमान स्थिति बताता है। जब तीसरी कमांड आपका address दिखाए और पहली न दिखाए, तो इसका मतलब है कि आपका DNS सही ढंग से कॉन्फ़िगर हो गया है और आप पुराने उत्तर की cached copy के हटने का इंतज़ार कर रहे हैं।

Resolving लोड नहीं हो रहा है

Name resolving यह साबित करता है कि DNS काम कर रहा है। यह आपके web server के बारे में कुछ भी साबित नहीं करता है। एक बार जब dig सही address लौटा देता है, तो connection का परीक्षण करें:

curl -I http://example.com

curl: (6) Could not resolve host: example.com एक DNS समस्या है। curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused DNS समस्या नहीं है: name resolve हो गया और packet पहुँच गया, इसलिए समस्या यह है कि उस port पर कुछ भी listening नहीं था। एक request जो hang हो जाती है और फिर time out हो जाती है, उसका मतलब आमतौर पर यह होता है कि firewall ने packet को refuse करने के बजाय चुपचाप drop कर दिया है। यहीं पर DNS का विषय समाप्त हो जाता है, और ports और listening sockets तथा आपके VPS पर ufw firewall rules का काम शुरू हो जाता है। Connection पूरा होने के बाद, page load का बाकी हिस्सा HTTP का काम होता है।

ब्राउज़र अभी भी पुराना होस्ट क्यों दिखाता है

DNS में कुछ भी propagate नहीं होता है। कोई भी सर्वर आपके बदलाव को बाहर की ओर पुश नहीं करता है। आपका authoritative nameserver आपके सेव करते ही नया मान (value) धारण कर लेता है, और पिछले उत्तर की हर cached कॉपी तब तक मान्य रहती है जब तक उसका अपना टाइमर समाप्त नहीं हो जाता। वह टाइमर TTL है, जो सेकंड में होता है, और रिकॉर्ड के साथ ही दिया जाता है।

कॉपी उन जगहों पर भी रहती हैं जहाँ लोग उम्मीद नहीं करते: ब्राउज़र का अपना छोटा कैश, मशीन पर मौजूद stub resolver, उस नेटवर्क द्वारा उपयोग किया जाने वाला recursive resolver, और क्लाइंट पर इंस्टॉल किया गया कोई भी VPN। प्रत्येक अपने पास मौजूद कॉपी को प्राप्त TTL तक रखता है। दो अलग-अलग नेटवर्क पर दो लोग घंटों तक दो अलग-अलग उत्तर देख सकते हैं, और दोनों मशीनें सही व्यवहार कर रही होती हैं।

caching resolver के विरुद्ध काउंटडाउन देखें:

dig @1.1.1.1 example.com +noall +answer

इसे कुछ सेकंड के अंतराल पर दो बार चलाएं। उत्तर में TTL कम हो जाता है। जब यह शून्य तक पहुँच जाता है, तो resolver रिकॉर्ड को हटा देता है और आपके nameserver से फिर से पूछता है।

एक दूसरा कैश भी है जिसका हिसाब लगभग कोई नहीं रखता: negative answers। जब किसी resolver को बताया जाता है कि कोई नाम मौजूद नहीं है, तो वह उस NXDOMAIN को भी कैश कर लेता है, जो आपके zone के SOA रिकॉर्ड के अंतिम फ़ील्ड द्वारा निर्धारित समय तक रहता है।

dig example.com SOA +short

उस लाइन पर अंतिम संख्या negative TTL है, जो अक्सर 3600 होती है। इसलिए, staging.example.com को बनाने से पहले उसे सर्च करने पर, वह रिकॉर्ड आपके बनाने के एक घंटे बाद तक आपसे छिपा रह सकता है। पहले रिकॉर्ड बनाएं, फिर उसे query करें।

nameservers को बदलना रिकॉर्ड बदलने की तुलना में धीमा है, और इसका कारण यांत्रिक है। .com zone में delegation रिकॉर्ड 172800 सेकंड के TTL के साथ सर्व किए जाते हैं, जो कि दो दिन है, इसलिए जिस resolver ने आपके पुराने nameservers को कैश किया है, वह इतने समय तक उनसे पूछता रह सकता है। "48 घंटे तक का समय दें" वाली सलाह यहीं से आती है। यह nameserver परिवर्तनों पर लागू होती है, न कि सामान्य रिकॉर्ड संपादन पर।

TTL से लड़ने के बजाय उसके अनुसार माइग्रेशन की योजना बनाएं:

1. रिकॉर्ड के TTL को 300 तक कम करें और उसे सेव करें।
2. पुराने TTL से अधिक समय तक प्रतीक्षा करें, ताकि पुराने मान वाली हर cached कॉपी समाप्त हो जाए।
3. पता (address) बदलें।
4. एक बार जब ट्रैफ़िक स्थानांतरित हो जाए, तो TTL को वापस 3600 या उससे अधिक पर बढ़ा दें, क्योंकि कम TTL का मतलब है कि हर resolver आपके nameservers से बहुत अधिक बार पूछता है।

अपनी मशीन पर जो डेटा है उसे साफ़ करने के लिए:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics एक कैश सेक्शन को hit और miss काउंटर्स के साथ प्रिंट करता है, इसलिए फ्लश करने के तुरंत बाद अगली lookup एक miss के रूप में दिखाई देती है। ब्राउज़र एक अलग कैश रखते हैं, जिसका अर्थ है कि सिस्टम कैश खाली होने के बाद भी Chrome पुराने उत्तर का उपयोग कर सकता है। उसे chrome://net-internals/#dns पर साफ़ करें। /etc/hosts की भी जाँच करें, क्योंकि वहाँ मौजूद कोई भी पुरानी लाइन उस मशीन पर DNS को ओवरराइड कर देती है। getent hosts example.com वह उत्तर दिखाता है जिसका उपयोग सिस्टम वास्तव में करेगा, जिसमें /etc/hosts भी शामिल है।

Wildcard certificates को TXT record के माध्यम से प्रमाणित किया जाता है

एक CA (certificate authority) certificate जारी करने से पहले नाम पर नियंत्रण की जाँच करता है। HTTP-01 challenge उस सटीक hostname पर port 80 के माध्यम से एक फ़ाइल प्रदान करता है, जो एक नाम के लिए सही ढंग से काम करता है। एक wildcard certificate *.example.com को कवर करता है, जो hostnames का एक ऐसा खुला सेट है जहाँ से CA फ़ाइल प्राप्त नहीं कर सकता, इसलिए Let's Encrypt केवल DNS-01 challenge के माध्यम से ही wildcard जारी करता है। आप _acme-challenge.example.com पर एक TXT record प्रकाशित करते हैं जिसमें CA द्वारा दिया गया एक token होता है, और zone का नियंत्रण ही इसका प्रमाण होता है।

यह आपके DNS host को certificate renewal का हिस्सा बना देता है। Certbot को हर renewal पर आपकी अनुपस्थिति में उस TXT record को बनाना और हटाना पड़ता है, इसलिए इसे आपके provider के लिए एक API और एक matching plugin की आवश्यकता होती है। जब validation विफल हो जाता है, तो सामान्य संदेश DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com होता है, जिसका अर्थ है कि CA ने record के दिखाई देने से पहले ही पूछ लिया था: या तो इसे कभी save नहीं किया गया था, या फिर एक negative उत्तर अभी भी cached था। पूरी प्रक्रिया DNS-01 challenge के साथ wildcard certificates के लिए गाइड में उपलब्ध है।

जब VPN आपके resolver पर नियंत्रण कर लेता है

VPN (virtual private network) client सामान्यतः कनेक्ट होने पर system resolver को बदल देता है, क्योंकि local network पर lookup भेजने से उस network को आपके द्वारा देखी जाने वाली हर site के नाम का पता चल जाएगा। यह सही व्यवहार है, और यह दो दिशाओं में विफल हो सकता है।

यदि tunnel चालू हो जाती है और addresses काम करते रहते हैं लेकिन names resolve होना बंद हो जाते हैं, तो client द्वारा install किया गया resolver tunnel के अंदर से पहुँच योग्य नहीं है। ping 1.1.1.1 सफल होता है और curl https://example.com, curl: (6) Could not resolve host: example.com लौटाता है। यदि इसके विपरीत tunnel चालू हो जाती है और lookup अभी भी उस network पर जाते हैं जहाँ आप स्थित हैं, तो आपका traffic tunnel हो जाता है जबकि local resolver आपके द्वारा पूछे गए हर नाम को देखता रहता है।

resolvectl status

यह प्रत्येक link के लिए उपयोग में आने वाले resolver को print करता है, ताकि आप देख सकें कि tunnel ने कौन सा install किया है और क्या वह वही है जिसे आप चाहते थे। WireGuard tunnel इसे client config में DNS = line से set करता है, और WireGuard द्वारा resolver लेने पर DNS को ठीक करना systemd-resolved और resolvconf के मामलों को विस्तार से कवर करता है।

रिप्लाई कोड और उनका अर्थ

• NXDOMAIN: एक authoritative सर्वर बताता है कि नाम मौजूद नहीं है। स्पेलिंग की जाँच करें, देखें कि कहीं डोमेन सफ़िक्स दो बार तो नहीं है, और यह सुनिश्चित करें कि आपने उसी ज़ोन को एडिट किया है जिस पर आपका डेलिगेशन पॉइंट करता है।
• NOERROR और साथ में खाली ANSWER SECTION: नाम मौजूद है, लेकिन इसमें उस प्रकार का कोई रिकॉर्ड नहीं है जिसे आपने मांगा है। जब केवल A मौजूद हो और आप AAAA के लिए अनुरोध करते हैं, तो ठीक यही परिणाम मिलता है।
• SERVFAIL: रिज़ॉल्वर ने प्रयास किया लेकिन उत्तर नहीं दे सका। इसके दो सामान्य कारण हैं: authoritative सर्वर जो कभी रिप्लाई नहीं देते, और DNSSEC (domain name system security extensions) वैलिडेशन का विफल होना। dig @1.1.1.1 example.com A +cd के साथ टेस्ट करें, जो वैलिडेशन को डिसेबल कर देता है। यदि इसके बिना उत्तर +cd और SERVFAIL के साथ आता है, तो इसका मतलब है कि समस्या सिग्नेचर में है। ऐसा अक्सर nameserver बदलने के बाद होता है, जहाँ पैरेंट अभी भी पुराना DS (delegation signer) रिकॉर्ड पब्लिश कर रहा होता है।
• REFUSED: जिस सर्वर से आपने पूछा है वह उस प्रश्न का उत्तर नहीं देगा, आमतौर पर इसलिए क्योंकि आपने dig को ऐसे authoritative सर्वर पर पॉइंट किया है जो उस डोमेन को सर्व नहीं करता है।
• ;; connection timed out; no servers could be reached: dig कभी रिज़ॉल्वर तक नहीं पहुँचा। यह आपकी ओर से नेटवर्क या रिज़ॉल्वर की समस्या है, इसलिए डोमेन इसका कारण नहीं है।

ping: example.com: Temporary failure in name resolution उसी प्रकार की विफलता है जिसे dig के बजाय glibc द्वारा रिपोर्ट किया जाता है।

क्या आपको अपने VPS पर nameservers चलाने चाहिए?

आप ऐसा कर सकते हैं। bind9, knot या nsd आपके सर्वर से आपकी zone को सर्व करेंगे, और यह आपको किसी भी पैनल की तुलना में DNS के बारे में अधिक सिखाएगा। आपत्तियां व्यावहारिक हैं। एक domain के पास कम से कम दो nameservers अलग-अलग networks पर होने चाहिए, इसलिए एक अकेला VPS उस domain की हर सेवा के लिए, जिसमें mail भी शामिल है, विफलता का एक बिंदु (failure point) बन जाता है। जिन nameservers का नाम उसी domain के भीतर रखा जाता है जिसे वे सर्व करते हैं, उन्हें registrar के पास glue records की आवश्यकता होती है। यह ns1.example.com का वह पता है जो parent zone में संग्रहीत होता है, क्योंकि इसके बिना lookup शुरू होने का कोई तरीका नहीं होता। जब कोई resolver आपके nameserver तक नहीं पहुँच पाता, तो वह आपकी website पर वापस नहीं लौटता है: उस user के लिए पूरा domain गायब हो जाता है। अधिकांश लोगों के लिए API के साथ Hosted DNS कम जोखिम वाला विकल्प है। अपनी मशीनों के लिए अपने VPS पर caching resolver चलाना एक अलग काम है, और इसमें बहुत कम जिम्मेदारी शामिल है।

FAQ

DNS परिवर्तन अभी तक लागू क्यों नहीं हुआ है?

कुछ भी propagate नहीं होता है। आपके authoritative nameservers में नया मान उसी क्षण सुरक्षित हो जाता है जब आप उसे save करते हैं, और हर resolver जिसने पहले पूछताछ की है, वह अपनी cached copy को तब तक रखता है जब तक कि उसे प्राप्त TTL समाप्त नहीं हो जाता। dig @ns1.your-dns-host.net example.com A +short का उपयोग करके सीधे authoritative server से पूछें। यदि वह नया पता दिखाता है, तो परिवर्तन live है और बाकी सब केवल caching का मामला है। यदि आपने records के बजाय nameservers बदले हैं, तो इसमें काफी अधिक समय लग सकता है, क्योंकि TLD delegations दो दिन के TTL के साथ जारी किए जाते हैं।

मैं यह कैसे पता लगाऊं कि मेरा domain वास्तव में किन nameservers का उपयोग कर रहा है?

dig example.com NS +short उन nameservers को print करता है जो अभी domain के लिए उत्तर दे रहे हैं, और dig +trace example.com root से referral chain दिखाता है, जिसमें TLD servers द्वारा दी गई delegation भी शामिल है। यदि वे नाम उस provider के नहीं हैं जिसका panel आप edit कर रहे हैं, तो यही आपकी त्रुटि है। या तो delegation में नामित provider के records को edit करें, या अपने registrar के पास delegation बदलें ताकि वह वहां point करे जहां आप चाहते हैं।

मेरा domain resolve हो रहा है लेकिन site load नहीं हो रही है। अब क्या करें?

जैसे ही dig example.com A +short आपके server का पता लौटाता है, DNS का काम पूरा हो जाता है। उसके बाद, समस्या connection की है। curl -I http://example.com का Connection refused लौटाने का मतलब है कि उस port पर कोई service listening नहीं है। एक request जो timeout होने तक लटकी रहती है, उसका मतलब है कि firewall ने packet को drop कर दिया है। जाँचें कि आपका web server चल रहा है और public address पर bound है, फिर server के firewall और अपने provider के control panel में मौजूद network firewall की जाँच करें।

मैं अपने root domain पर CNAME क्यों नहीं लगा सकता?

CNAME का अर्थ है कि एक नाम दूसरे नाम का alias है, और जिस नाम में CNAME होता है, उस पर कोई अन्य record रखने की अनुमति नहीं होती है। आपके root domain पर zone के रूप में अस्तित्व में रहने के लिए SOA और NS records होने चाहिए, इसलिए यह CNAME नहीं हो सकता। root पर पता रखने के लिए A record का उपयोग करें, या ALIAS, ANAME या CNAME flattening के रूप में बेची जाने वाली provider सुविधा का उपयोग करें, जो एक नाम को store करती है और queries का उत्तर उस पते के साथ देती है जिस पर वह नाम वर्तमान में resolve होता है।