Domain Name System (DNS) डोमेन नामों को IP पतों में बदलता है। जानिए DNS कैसे काम करता है, इसके मुख्य रिकॉर्ड प्रकार क्या हैं, और SEO व साइट माइग्रेशन के लिए DNS क्यों मायने रखता है।

इस पेज पर
Domain Name System (DNS) वह प्रणाली है जो इंसानों के लिए पढ़ने योग्य डोमेन नामों, जैसे example.com, को उन संख्यात्मक IP पतों में बदलती है जिनसे कंप्यूटर सर्वर ढूँढते हैं। जब भी कोई वेब पेज खोलता है, ईमेल भेजता है, या कोई सर्च इंजन बॉट कोई URL लाता है, तो पहले एक DNS लुकअप होता है, जो आम तौर पर कुछ मिलीसेकंड में पूरा हो जाता है।
DNS को अक्सर इंटरनेट की फ़ोन बुक कहा जाता है। जब यह सही चलता है तो दिखता नहीं, और जब विफल होता है तो सब कुछ रोक देता है: अगर DNS बंद है या गलत कॉन्फ़िगर है, तो साइट की सामग्री कितनी भी अच्छी हो, विज़िटर और क्रॉलर दोनों के लिए वह पहुँच से बाहर होती है।
DNS एक वितरित, श्रेणीबद्ध (hierarchical) डेटाबेस है, जो 1983 में बनाया गया और RFC 1034 तथा RFC 1035 (1987) में मानकीकृत हुआ। कोई एक सर्वर हर रिकॉर्ड नहीं रखता। इसके बजाय ज़िम्मेदारी रूट सर्वरों, टॉप-लेवल डोमेन सर्वरों (.com, .fr, .de) और हर डोमेन मालिक द्वारा चुने गए authoritative नेम सर्वरों के बीच बँटी होती है, जो आम तौर पर किसी रजिस्ट्रार, होस्ट या Cloudflare जैसे प्रदाता के पास होते हैं।
डोमेन नाम किसी URL का पढ़ा जा सकने वाला हिस्सा है। DNS इस नाम को तकनीकी संसाधनों से जोड़ता है: वेब सर्वर, मेल सर्वर, और तीसरे पक्ष की सेवाओं के लिए verification टोकन। इन जोड़ों को बदलने के लिए डोमेन के zone में DNS रिकॉर्ड संपादित किए जाते हैं।
जब ब्राउज़र को www.example.com का IP पता चाहिए, तो वह पहले एक recursive resolver से पूछता है, जो आम तौर पर इंटरनेट प्रदाता या 1.1.1.1 अथवा 8.8.8.8 जैसी सार्वजनिक सेवा चलाती है। अगर जवाब कैश में नहीं है, तो resolver एक रूट सर्वर से पूछता है, वह .com सर्वरों की ओर इशारा करता है, वे example.com के authoritative नेम सर्वरों की ओर, और अंत में वे IP पता लौटाते हैं।
हर जवाब के साथ एक TTL (time to live) आता है, जो resolvers को बताता है कि उसे कितनी देर कैश में रखना है। लंबा TTL लुकअप घटाता है और बार-बार आने वाले विज़िट तेज़ करता है; छोटा TTL बदलावों को तेज़ी से फैलने देता है। इसी वजह से DNS बदलाव हर जगह दिखने में कुछ मिनट से लेकर 48 घंटे तक लग सकते हैं।
एक DNS zone में कई तरह के रिकॉर्ड होते हैं, और हर एक की अपनी स्पष्ट भूमिका होती है:
कम आम रिकॉर्ड में CAA (जो बताता है कि कौन से certificate authorities SSL certificate जारी कर सकते हैं), SRV (सेवाओं के लिए) और PTR (reverse lookup के लिए) शामिल हैं। किसी मार्केटिंग साइट के लिए A, AAAA, CNAME, MX और TXT लगभग हर ज़रूरत पूरी कर देते हैं।
DNS अपने आप में कोई रैंकिंग फ़ैक्टर नहीं है, पर यह दो ऐसी चीज़ों को प्रभावित करता है जो मायने रखती हैं। पहली है उपलब्धता: अगर नेम सर्वर विफल होते हैं, तो Googlebot साइट तक नहीं पहुँच पाता, और बार-बार विफलता से क्रॉलिंग घटती है। दूसरी है गति: DNS resolution हर पेज लोड का पहला चरण है, और धीमा resolution पहली बाइट से पहले देरी जोड़ता है, जिससे पहली बार आने वाले विज़िटरों के लिए page speed पर असर पड़ता है।
ज़्यादातर आधुनिक DNS प्रदाता कई जगहों से कुछ मिलीसेकंड में जवाब देते हैं। तेज़ anycast DNS, जो अक्सर content delivery network के साथ आता है, यह रुकावट हटा देता है। भरोसेमंद प्रदाता चुनना, जिसमें redundancy हो, उपयोगकर्ताओं और क्रॉलरों दोनों की सुरक्षा का एक सरल तरीका है।
कई रोज़मर्रा के SEO कार्यों में DNS शामिल होता है। Google Search Console में डोमेन property का verification एक TXT रिकॉर्ड से होता है, जो एक साथ हर protocol और subdomain को कवर करता है। किसी blog subdomain को होस्टेड प्लेटफ़ॉर्म की ओर इंगित करने के लिए CNAME इस्तेमाल होता है। न्यूज़लेटर के ईमेल की deliverability SPF, DKIM और DMARC रिकॉर्ड पर निर्भर करती है।
माइग्रेशन सबसे जोखिम भरा समय है। साइट को नए होस्ट या नए डोमेन पर ले जाने का मतलब है रिकॉर्ड बदलना, और एक गलती पूरी साइट को ऑफ़लाइन कर सकती है या HTTPS तोड़ सकती है। एक दिन पहले TTL घटाएँ, बदलाव शांत समय में करें, redirect checker से जाँचें कि हर पुराना URL सही status लौटाता है, और उसके बाद के दिनों में crawl errors पर नज़र रखें।
सबसे आम गलतियाँ हैं डोमेन का expire होने देना, किसी ऐसे रिकॉर्ड को हटाना जो अभी भी किसी सेवा में इस्तेमाल हो रहा है, और एक ही नाम के लिए दो आपस में टकराने वाले रिकॉर्ड छोड़ देना। एक और पुरानी गलती है रूट डोमेन और www वर्ज़न को अलग-अलग सर्वरों पर इंगित करना, जिससे अगर redirects सेट न हों तो साइट के डुप्लीकेट वर्ज़न बन जाते हैं।
सुरक्षा दूसरा जोखिम है। हटाए गए cloud संसाधनों की ओर इशारा करने वाले dangling CNAME रिकॉर्ड पर हमलावर कब्ज़ा कर सकते हैं, और अनलॉक्ड डोमेन hijack हो सकते हैं। Registrar lock, registrar खाते पर two-factor authentication, और जहाँ समर्थित हो वहाँ DNSSEC चालू करें।
SEO के लिए DNS अदृश्य नींव का हिस्सा है: जो साइट तेज़ी और भरोसे से resolve होती है, उसकी क्रॉलिंग लगातार होती है और असली उपयोगकर्ताओं के लिए वह तेज़ लोड होती है। इस स्तर की समस्याएँ सारे कंटेंट और लिंक के काम को बेअसर कर देती हैं, क्योंकि जिन पेजों तक पहुँचा नहीं जा सकता, उन्हें index नहीं किया जा सकता।
GEO के लिए वही नियम GPTBot, ClaudeBot या PerplexityBot जैसे AI crawlers पर लागू होता है। वे पेज उसी DNS और HTTP स्टैक से लाते हैं जिससे Googlebot। जब कोई AI assistant किसी सवाल का जवाब देने के लिए असली समय में पेज पढ़ने की कोशिश करता है और डोमेन resolve नहीं होता, तो वह पेज किसी दूसरे स्रोत के पक्ष में बस छोड़ दिया जाता है।
Domain Name System resolvers और नेम सर्वरों की एक श्रेणी के ज़रिए डोमेन नामों को IP पतों में बदलता है, और इसके रिकॉर्ड जैसे A, CNAME, MX और TXT हैं। यह कोई रैंकिंग फ़ैक्टर नहीं है, पर यह उपलब्धता, गति, साइट verification और माइग्रेशन को तय करता है, इसलिए यह SEO और GEO की एक चुपचाप ज़रूरी शर्त है।
संदर्भ स्रोत: MDN Web Docs और Wikipedia.
स्रोत
DNS का पूरा नाम Domain Name System है। यह example.com जैसे डोमेन नामों को उन IP पतों में बदलता है जिन पर वेब साइट, ईमेल और दूसरी सेवाएँ होस्ट होती हैं।
यह रिकॉर्ड के TTL और resolver कैश पर निर्भर करता है। कई बदलाव कुछ मिनटों में दिख जाते हैं, पर हर जगह पहुँचने में 48 घंटे तक लग सकते हैं। नियोजित बदलाव से पहले TTL घटाने से फैलाव तेज़ होता है।
अप्रत्यक्ष रूप से, हाँ। अगर डोमेन resolve नहीं होता, तो Googlebot साइट को क्रॉल नहीं कर सकता और उपयोगकर्ता उस तक नहीं पहुँच सकते। छोटी रुकावटें आम तौर पर हानिरहित होती हैं, पर बार-बार या लंबी विफलताएँ क्रॉलिंग घटाती हैं और पेज index से बाहर हो सकते हैं।
आपसे पहले लोगों ने Sorank आज़माया है
