डोमेन नाम प्रणाली

इतिहास

नेटवर्क पर एक मशीन के संख्यात्मक पते के स्थान पर मनुष्य के पठन योग्य नामों का प्रचलन TCP/IP से भी पहले का है। यह प्रचलन ARPAnet युग का है। इसके बाद एक अलग प्रणाली का प्रयोग किया गया। DNS का अविष्कार 1983 में TCP/IP के शीघ्र बाद ही किया गया। पुराने सिस्टम में, नेटवर्क पर SRI (अब SRI इंटरनेशनल) पर स्थित प्रत्येक कंप्यूटर से एक कंप्यूटर HOSTS.TXT नामक फ़ाईल प्राप्त करता था। HOSTS.TXT फ़ाईल में ढूंढे गये नामों का संख्यात्मक पता होता था। आधुनिक ऑपरेटिंग सिस्टम पर आज भी एक होस्ट फ़ाइल या तो डिफॉल्ट रूप में या सैटिंग के माध्यम से मौजूद होती है और उपयोगकर्ताओं को एक आईपी पता निर्धारित करने (उदाहरण 208.77.188.166) और DNS की जाँच किये बिना एक होस्ट नाम के लिए अनुमति देती है। (उदाहरण www.example.net). होस्ट फ़ाइलों पर आधारित सिस्टम की कुछ मूलभूत सीमाएं हैं, क्योंकि यह एक स्पष्ट आवश्यकता है कि जब भी कंप्यूटर का IP पता बदले तो उससे संपर्क करने की कोशिश करने वाले कम्प्यूटरों को भी इसकी होस्ट फ़ाइल से अपडेट करने की आवश्यकता पड़ेगी.
नेटवर्किंग के विकास को और अधिक विश्वसनीय प्रणाली की आवश्यकता थी जो होस्ट में पते के बदलाव को केवल एक जगह पर रिकॉर्ड करे. दूसरे होस्ट एक सूचना प्रणाली के माध्यम से इस बदलाव के बारे में स्वयं जानकारी प्राप्त करेंगे जिससे सभी होस्ट नामों और उनसे सम्बंधित IP पतों तक पहुँच सुलभ हो जाएगी.
जॉन पोस्टेल के अनुरोध पर, पॉल मोकापेट्रिस ने 1983 में पहली डोमेन नाम प्रणाली का आविष्कार किया और इसे लागू करने का ढंग लिखा. मूल व्याख्या RFC 882 और RFC 883 में दिखाई गयी है जिन्हें नवम्बर 1987 में RFC 1034 और RFC 1035 से बदला गया। टिप्पणी के लिए कई अतिरिक्त अनुरोध मिलने के पर मूल DNS प्रोटोकॉल के विस्तार का प्रस्ताव किया गया है।
1984 में, चार बर्कले में पढ़ने वाले छात्रों डगलस टेरी, मार्क पेंटर, डेविड रिगल और सोंनिया झोउ ने पहला UNIX कार्यान्वन लिखा जिसे बाद में राल्फ कैंपबेल द्वारा पूरा किया गया। 1985 में, DEC के केविन डनलप ने पुनः DNS कार्यान्वयन लिखा और इसका नाम BIND रखा जिसका मतलब था बर्कले इंटरनेट नेम डोमेन. तब से माइक कैरेल, फिल एल्मक्विस्ट और पॉल विक्सी ने BIND को जिन्दा रखा है। 1990 के दशक के आरम्भ में BIND को विंडोज NT मंच पर स्थापित किया गया।
BIND को व्यापक रूप से, विशेषकर यूनिक्स सिस्टम पर वितरित किया गया और यह इंटरनेट पर प्रयोग होने वाला सबसे प्रभावी DNS सॉफ्टवेयर है। अत्यधिक उपयोग और इसके मुक्त स्रोत कोड की जांच के परिणामस्वरूप, साथ ही साथ तेजी से और अधिक परिष्कृत हमले के तरीकों की वजह से BIND में कई सुरक्षा खामियां पाई गईं। इससे कई वैकल्पिक नेम सर्वर और रिसोल्वर प्रोग्रामों का विकास हुआ। BIND को स्क्रैच से संस्करण 9 में पुनः लिखा गया जिसका सुरक्षा रिकॉर्ड दूसरे आधुनिक इंटरनेट सॉफ्टवेयर से तुलना योग्य है।

डोमेन नेम स्पेस

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

DNS सर्वर

डोमेन नाम प्रणाली को एक वितरित डाटाबेस प्रणाली द्वारा नियंत्रित किया जाता है है, जो क्लाइंट (ग्राहक) -सर्वर मॉडल का उपयोग करता है। इस डाटाबेस के नोड नाम सर्वर हैं। प्रत्येक डोमेन या उपडोमेन एक या एक से अधिक आधिकारिक DNS सर्वर हैं जो कि डोमेन और इसके अधीन किसी भी डोमेन के नाम सर्वर के बारे में जानकारी सार्वजनिक कर देते हैं। श्रंखल में शीर्ष पर रूट नेमसर्वर हैं : शीर्ष स्तर डोमेन नाम (TLD) देखते (ढूंढते) समय इनसे पूछताछ की जाती है।

सर्कुलर निर्भरता और ग्लू रिकॉर्ड

डेलीगेशन में नाम सर्वर IP पते से सूचीबद्ध होने की बजाए नाम से प्रदर्शित होते हैं। इसका अर्थ यह है कि एक रिसोल्विंग नाम सर्वर को एक निर्दिष्ट किये गये सर्वर के IP पते को ढूँढने के लिए एक अन्य DNS अनुरोध अवश्य भेजना चाहिए। चूंकि इस वजह से सर्कुलर निर्भरता की स्थिति हो सकती है, यदि एक डोमेन के तहत एक नेम सर्वर को निर्दिष्ट किया जाये जो इसके अधीन है, तो यह आवश्यक है कि ऐसे मामले में नेम सर्वर डेलीगेशन को अगले नेम सर्वर का IP पता भी अवश्य प्रदान करे. यह रिकॉर्ड एक ग्लू रिकॉर्ड कहलाता है।
उदाहरण के लिए मानिए कि उप-डोमेन en.wikipedia.org के और भी उप-डोमेन हैं (जैसे something.en.wikipedia.org) और यह कि इनका आधिकारिक नाम सर्वर ns1.something.en.wikipedia.org है। एक कंप्यूटर जो ns1.something.en.wikipedia.org को ढूँढने का प्रयास कर रहा है, उसे पहले something.en.wikipedia.org को ढूँढने का प्रयास करना होगा। चूंकि Ns1 भी something.en.wikipedia.org उपडोमेन के अंतर्गत है, इसलिए ns1.something.en.wikipedia.org को ढूँढने के लिए something.en.wikipedia.org को ढूंढना पड़ेगा जो कि निश्चित तौर पर एक सर्कुलर निर्भरता है, जैसे कि ऊपर बताया गया है। इस निर्भरता को en.wikipedia.org के नेम सर्वर के ग्लू रिकॉर्ड द्वारा तोडा जाता है जो कि अनुरोधकर्ता को सीधे ही ns1.something.en.wikipedia.org का IP पता प्रदान करता है जो ns1.somethingen.wikipedia.org को bootstrap प्रक्रिया द्वारा ढूँढने की प्रक्रिया के लिए सक्षम बनाता है।

कैशिंग और जीवन समय

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

कैशिंग समय

इस वितरित और कैशिंग संरचना के एक उल्लेखनीय परिणाम के रूप में, DNS रिकॉर्ड में परिवर्तन हमेशा तुरंत और दुनिया भर में प्रभावी नहीं होते. इसे एक उदाहरण के माध्यम से अच्छी तरह से स्पष्ट किया ज़ा सकता है : यदि किसी एडमिनिसट्रेटर ने होस्ट www.wikipedia.org के लिए 6 घंटे का टीटीएल सेट किया है और इसके बाद IP पता जिसमें 12:01pm पर www.wikipedia.org को ढूँढा जाना है, एडमिनिस्ट्रेटर को यह सोचना चाहिए कि वह व्यक्ति जिसने 12:00 बजे दोपहर में पुराने आईपी पते से एक प्रतिक्रिया को कैश्ड किया होगा, वह 6:00pm तक DNS सर्वर से संपर्क नहीं कर सकेगा। इस उदाहरण में 12:01pm और 6:00pm के बीच की अवधि को कैशिंग समय कहा जाता है, जो कि एक ऐसे समय के रूप में सर्वश्रेष्ठ ढंग से परिभाषित है जो तब शुरू होता है जब आप DNS रिकॉर्ड में बदलाव करते हैं तथा तब समाप्त होता है जब टीटीएल द्वारा निर्दिष्ट समय की अधिकतम सीमा समाप्त हो जाती है। डीएनएस में परिवर्तन करते समय इसे एक महत्वपूर्ण तार्किक सोच के रूप में देखा जाता है : यह आवश्यक नहीं कि प्रत्येक वा देख रहा हो जो आप देख रहे हैं। RFC 1912 टीटीएल स्थापित करने के बुनियादी नियमों को बताने में मदद करता है।
शब्द "प्रसार" पर ध्यान दें हालांकि यह इस संदर्भ में बहुत व्यापक रूप से प्रयुक्त होता है, अच्छी तरह से कैशिंग के प्रभाव का वर्णन नहीं करता है। विशेष रूप से, इसका अर्थ है कि [1] जब आप एक DNS परिवर्तन करते हैं, यह किसी तरह अन्य DNS सर्वरों में फ़ैल जाता है (बजाए इसके कि आपकी ज़रुरत के समय अन्य DNS सर्वर आप के साथ जांच करें) और [2] कि आपका कैश्ड किये गये रिकॉर्ड के समय की मात्रा पर कोई नियंत्रण नहीं है (आप NS रिकॉर्ड और आपके डोमेन नाम का उपयोग करने वाले दूसरे आधिकारिक DNS सर्वर के अलावा अपने डोमेन में सभी DNS रिकॉर्ड के लिए टीटीएल मूल्य नियंत्रित करते हैं).
कुछ रिसोल्वर टीटीएल मूल्यों को भी पार कर जाते हैं क्योंकि प्रोटोकॉल कैशिंग के लिए 68 साल तक या बिल्कुल कैशिंग नहीं, का समर्थन करता है। नकारात्मक कैशिंग (रिकॉर्ड का अस्तित्व में न होना) एक ज़ोन के अधिकृत नाम सर्वर द्वारा निर्धारित की जाती है जिसमें स्टार्ट ऑफ़ ऑथोरिटी (SOA) रिकॉर्ड का अवश्य उल्लेख किया जाना चाहिए जब अनुरोध के जवाब में कोई भी डाटा रिपोर्टिंग के लिए उपलब्ध नहीं है। SOA रिकार्ड के न्यूनतम क्षेत्र और खुद SOA के टीटीएल का प्रयोग नकारात्मक जवाब के लिए टीटीएल स्थापित करने में होता है। RFC 2308
जब आप एक DNS में परिवर्तन करते हैं तो बहुत से लोग गलत तरीके से रहस्यमय 48 घंटे या 72 घंटे को प्रचार समय मानते हैं। यदि कोई किसी डोमेन का DNS रिकॉर्ड बदल दे या एक डोमेन के अधिकृत DNS सर्वरों के होस्ट नामों का IP पता (यदि कोई हो तो) बदल दे सभी DNS सर्वरों को नयी सूचना का प्रयोग करने से पहले लम्बा समय लग सकता है। यह इसलिए हैं क्योंकि वो रिकॉर्ड ज़ोन पैरेन्ट DNS सर्वरों (उदाहरण के लिए। Com डीएनएस सर्वर यदि आपका डोमेन example.com है), द्वारा नियंत्रित किये जा रहे हैं जो आम तौर पर 48 घंटे के लिए उन रिकॉर्ड को कैश (संग्रहित) करते हैं। हालांकि, ये DNS परिवर्तन किसी भी DNS सर्वर के लिए तत्काल उपलब्ध होंगे जिसने उन्हें कैश्ड नहीं किया होगा। और आपके डोमेन पर NS रिकॉर्ड और अधिकृत DNS सर्वर नाम के अलावा कोई भी DNS परिवर्तन लगभग तुरंत होगा, यदि आप ऐसे करना चाहते हैं। (TTL को एक या दो बार समय से आगे कर के और तब तक प्रतीक्षा कर के जब तक की परिवर्तन से पहले पुराना TTL ख़त्म नहीं हो जाता).

रिवर्स लुकअप (खोज)

"रिवर्स लुकअप" शब्द दिए गये IP पते से जुड़े नाम को खोजने के लिए DNS पूछताछ को संदर्भित करता है।
DNS विशेष डोमेन में IP पते को PTR रिकॉर्ड के रूप में संग्रहित करता है। IPv4 के लिए, डोमेन in-addr.arpa है। IPv6 के लिए, रिवर्स लुकअप डोमेन ip6.arpa है।
रिवर्स लुकअप की प्रक्रिया करते समय, DNS क्लाइंट पते को DNS में प्रयुक्त प्रारूप में बदल देता है, तथा इसके बाद हमेशा की तरह डेलिगेशन श्रंखला का पालन करता है। उदाहरण के लिए, IPv4 पता '208.80.152.2', 2.152.80.208.in-addr.arpa में बदल जाता है। DNS रिसोल्वर की पूछताछ रूट सर्वरों से होती है जो 208.in-addr.arpa ज़ोन के लिए ARIN सर्वर की ओर संकेत करता है। वहाँ से 152.80.208.in के लिए विकीमिडिया सर्वर नियुक्त किये गये हैं और PTR विकीमिडिया नेम सर्वर से 2.152.80.208.in-addr.arpa के लिए पूछताछ करके लुकअप (खोज) पूर्ण करता है, जिसके परिणामस्वरूप एक एक आधिकारिक परिणाम मिलता है।

क्लाइंट/ग्राहक लुकअप

उपयोगकर्ता आम तौर पर सीधे एक DNS रिसोल्वर के साथ संपर्क नहीं करते. इसके बजाय DNS रेसोल्यूशन एप्लीकेशन प्रोग्राम में पारदर्शी ढंग से जगह बनाता है जैसे कि वेब ब्राउज़र, ई मेल ग्राहक और अन्य इंटरनेट एप्लीकेशन/प्रोग्राम. प्रोग्राम एप्लीकेशन के एक ऐसे अनुरोध जिसके लिए डोमेन नेम लुकअप की आवश्यकता है, ऐसे प्रोग्राम रेसोल्यूशन अनुरोध को स्थानीय ऑपरेटिंग सिस्टम में DNS रिसोल्वर को भेजते हैं जो बदले मैं आवश्यक संचार नियंत्रित करता है।
DNS रिसोल्वर में लगभग हमेशा ही हाल में प्रयुक्त किये गये लुकअप का कैश/संग्रह (ऊपर देखें) होता है। यदि कैश अनुरोध का उत्तर दे पाए तो रिसोल्वर कैश का उत्तर अनुरोध करने वाले प्रोग्राम को देगा। यदि कैश में उत्तर न हो तो रिसोल्वर एक या अधिक निर्दिष्ट DNS सर्वरों को अनुरोध भेज देगा। ज्यादातर घरेलू उपयोगकर्ताओं के मामले में, इंटरनेट सेवा प्रदाता जिससे मशीन संपर्क स्थापित करती है, आम तौर पर इस DNS सर्वर की आपूर्ति करता है: ऐसे उपयोगकर्ता का सर्वर पता मैन्युअल रूप से कॉन्फ़िगर होगा या DHCP को निर्धारित करने की अनुमति देगा, लेकिन जहां सिस्टम एडमिनिस्ट्रेटर द्वारा अपने DNS सर्वर प्रयोग करने के लिए सिस्टम कॉन्फ़िगर किये गये हैं, उनका DNS रिसोल्वर संगठन के अलग रखे गये नेम सर्वर की ओर संकेत करता है। किसी भी परिस्थिति में, पूछताछ किये जाने वाला नेम सर्वर ऊपर दी गयी प्रक्रिया का पालन करेगा जब तक कि सफलतापूर्वक परिणाम का पता न लग जाए अथवा न लगा सके। तब यह अपना परिणाम DNS रिसोल्वर को यह मानते हुए भेज देता है कि इसने उत्तर ढूंढ लिया है, रिसोल्वर उत्तर को भविष्य के लिए कैश्ड (संग्रहित) कर लेता है और उत्तर को उस सॉफ्टवेर के पास वापिस भेज देता है जिसने शुरुआत में प्रश्न पूछा था।

टूटे हुए रिसोल्वर

जब रिसोल्वर DNS प्रोटोकॉल के नियमों का उल्लंघन करता है तो एक अतिरिक्त स्तर की जटिलता उभरती है। बड़ी संख्या में इंटरनेट सेवा प्रदाताओं (ISPs) ने अपने DNS सर्वर नियमों का उल्लंघन करने के लिए यह मानते हुए सेट कर रखे हैं कि उन्हें पूर्ण नियमबद्ध रिसोल्वर के बजाए एक कम महंगा हार्डवेयर चलाने की अनुमति मिली हुई है।
जटिलता के अंतिम स्तर के रूप में, कुछ एप्लीकेशन (जैसे कि वेब ब्राउज़र) के भी अपने DNS कैश होते है, ताकि वे स्वयं DNS रिसोल्वर पुस्तकालय/लाईब्रेरी का प्रयोग कम करें। इसमें अतिरिक्त मुश्किल तब और जुड़ जाती है जब DNS मुद्दों की डिबगिंग (गल्तियाँ सुधारना) होती है, क्योंकि यह डाटा की ताजगी का पता लगाना और/या यह बताना कि डाटा किस कैश से आ रहा है, कठिन बना देता है। ये कैश आम तौर पर बहुत कम कैशिंग समय - एक मिनट के आदेश पर - काम करते हैं। इंटरनेट एक्सप्लोरर एक उल्लेखनीय अपवाद प्रस्तुत करता है : recent के अनुसार  संस्करण आधे घंटे तक DNS रिकॉर्ड को कैश करता है।

प्रोटोकॉल विवरण

DNS मुख्यतः पोर्ट संख्या 53 पर यूज़र डाटाग्राम प्रोटोकॉल (UDP) का प्रयोग अनुरोध का उत्तर देने के लिए करता है। DNS पूछताछ में ग्राहक द्वारा पूछे गये एक UDP प्रश्न का जवाब सर्वर द्वारा एक UDP परिणाम द्वारा दिया जाता है। ट्रांसमिशन कंट्रोल प्रोटोकॉल (TCP) का प्रयोग तब किया जाता है जब उत्तर के रूप में डाटा का आकार 512 बाइट्स से अधिक है या फिर ज़ोन स्थानान्तरण जैसे कार्यों में किया जाता है। कुछ ऑपरेटिंग सिस्टम जैसे कि HP-UX में कुछ ऐसे रिसोल्वर लागू किये गये हैं जो कि सभी तरह की पूछताछ में TCP का तब भी प्रयोग करते हैं, जब इसके लिए केवल UDP ही पर्याप्त है।

वाइल्डकार्ड DNS रिकॉर्ड

डोमेन नाम प्रणाली वाइल्डकार्ड डोमेन नाम का समर्थन करती है जो ऐसे नाम हैं जो एस्टरिस्क लेबल, '*', के साथ शुरू होते हैं जैसे, *.example।  वाइल्डकार्ड डोमेन नाम से सम्बंधित DNS रिकॉर्ड एक DNS ज़ोन में रिसोर्स नाम उत्पन्न करने के लिए, सभी लेबलों में से पूछे गये नाम से मिलते जुलते नाम घटा कर, जिसमें निर्दिष्ट वंशावली भी शामिल है, नियम निर्धारित करता है। 
उदाहरण के लिए, DNS ज़ोन x.example में, निम्नलिखित सेटअप बताता है कि x.example के सभी उपडोमेन (जिनमें उपडोमेन के उपडोमेन भी शामिल हैं) मेल एक्सचेंजर a.x.example का उपयोग करते हैं। मेल एक्सचेंजर को निर्दिष्ट करने के लिए a.x.example के लिए रिकॉर्ड की जरूरत है। चूंकि यह परिणाम वाइल्डकार्ड के मिलान से डोमेन नेम तथा इसे उपडोमेन छोड़ कर प्राप्त हुआ है, a.x.example के सभी उपडोमेन वाइल्डकार्ड परिणामों में अवश्य परिभाषित होने चाहिएं.
X.EXAMPLE. MX 10 A.X.EXAMPLE. 
*.X.EXAMPLE. MX 10 A.X.EXAMPLE. 
*.A.X.EXAMPLE. MX 10 A.X.EXAMPLE. 
A.X.EXAMPLE. MX 10 A.X.EXAMPLE. 
A.X.EXAMPLE. AAAA 2001:db8::1
वाइल्डकार्ड रिकॉर्ड की भूमिका RFC 4592 में परिष्कृत की गयी थी क्योंकि RFC 1034 में मूल परिभाषा अधूरी थी और जिसके कारण इसको लागू करने वाले सही ढंग से व्याख्या नहीं कर प् रहे थे।

प्रोटोकॉल एक्सटेंशन

मूल DNS प्रोटोकॉल में नई सुविधाओं के विस्तार के लिए सीमित प्रावधान थे। 1999 में पॉल विक्सी ने RFC 2671 में एक विस्तार प्रणाली सार्वजनिक की जिसे DNS के लिए विस्तार तंत्र(EDNS) कहा जाता है जिसमें बिना खर्च बढ़ाए प्रयुक्त न होने वाले वैकल्पिक प्रोटोकॉल तत्व थे। ऐसा बनावटी रिसोर्स रिकॉर्ड ऑप्ट के माध्यम से किया गया जो केवल प्रोटोकॉल के तार प्रसारण में मौजूद था, किन्तु किसी भी ज़ोन फाइलों में नहीं था। प्रारंभिक विस्तारों का भी सुझाव दिया गया (EDNS0), जैसे UDP डाटाग्राम में DNS संदेश के आकार में वृद्धि.

डाइनेमिक ज़ोन अपडेट

एक आधिकारिक DNS सर्वर पर ज़ोन डाटा बेस में रखे रिकार्डों को डाइनेमिक DNS अपडेट के अपडेट DNS opcode की सहायता से जोड़ या हटा कर, डाइनेमिक ढंग से अपडेट करता है। यह सुविधा RFC 2136 में वर्णित है। इस सुविधा से DNS में नेटवर्क के ग्राहकों को रजिस्टर किया जाता है जब वे बूट करते हैं या नेटवर्क पर उपलब्ध होते हैं। चूंकि बूटिंग करने वाले ग्राहक को हर बार DHCP सर्वर द्वारा एक अलग IP पत सौंपा जा सकता है, इस तरह के ग्राहकों के लिए स्थिर DNS उपलब्ध कराना संभव नहीं है।

अंतर्राष्ट्रीयकृत डोमेन नाम

यद्यपि तकनीकी रूप से डोमेन नाम में प्रयुक्त किये जाने वाले वर्णों पर कोई प्रतिबंध नहीं है और उसमें गैर-ASCII वर्ण भी शामिल हो सकते हैं, पर होस्ट नाम के लिए यह लागू नहीं होता।  होस्ट नामों को ज्यादातर लोग ई-मेल और वेब ब्राउज़िंग के लिए देखते और प्रयोग करते हैं। होस्ट नाम ASCII वर्णों के एक छोटे सबसेट तक ही सीमित हैं जिन्हें LDH के रूप में जाना जाता है, L A-Z तक छोटे और बड़े अक्षर, D संख्या 0-9 तक, H हाइफन, और LDH लेबलों को अलग करने के लिए डॉट; विस्तृत जानकारी के लिए RFC 3696 खंड 2 देखें. इससे कई स्थानीय भाषाओं के नामों तथा शब्दों के प्रदर्शन पर अंकुश लग गया। ICANN ने पूनीकोड आधारित IDNA प्रणाली को मंज़ूरी दे दी है, जो इस विषय पर काम करते हुए यूनिकोड वाक्यों को वैध वर्ण समूह में बदलता है। कुछ रजिस्ट्रियों ने भी IDNA को स्वीकार कर लिया है।

सुरक्षा मुद्दे

शुरुआत में DNS को बनाते समय सुरक्षा को ध्यान में नहीं रखा गया था।
कमियों का एक स्वरूप DNS कैश दूषित होना है, जो DNS सर्वर को यह विश्वास दिलाता है कि प्रामाणिक जानकारी प्राप्त हो गयी है जबकि वास्तविकता में ऐसा नहीं होता।
पारंपरिक रूप से DNS परिणाम क्रिप्टोग्राफी द्वारा हस्ताक्षरित नहीं होते जिससे हमले की कई संभावनाएं बढ़ जाती हैं; डोमेन नाम प्रणाली सुरक्षा विस्तार (DNSSEC), DNS को क्रिप्टोग्राफी द्वारा हस्ताक्षरित परिणाम देने के लिए परिवर्तित कर देता है। ज़ोन स्थानान्तरण जानकारी का समर्थन करने कई विस्तार भी उप्लभ हैं।
यहां तक कि एन्क्रिप्शन द्वारा भी, एक DNS सर्वर एक वायरस के साथ समझौता कर (या कहें कि असंतुष्ट कर्मचारियों द्वारा) जो कि सर्वर के IP पते को एक लम्बे TTL के साथ एक गलत पते पर निर्देशित करेंगे। यह इंटरनेट उपयोगकर्ताओं के लाखों लोगों पर दूरगामी संभावित प्रभाव डाल सकते हैं, अगर व्यस्त DNS सर्वर खराब IP डाटा को कैश (संग्रहित) कर लेता है। इसे ख़त्म करने के लिए सभी प्रभावित DNS कैश को मैन्युअल ढंग से साफ़ करना पड़ेगा जो लम्बे TTL (68 साल तक) तक हो सकता है।
कुछ डोमेन नाम दूसरे, मिलते जुलते डोमेन नामों के द्वारा धोखा दे सकते हैं। उदाहरण के लिए, "paypal.com" और "paypa1.com" अलग नाम हैं, फिर भी उपयोगकर्ता अंतर बताने में असमर्थ हो सकता है जब उपयोगकर्ता का टाइप फेस (फ़ॉन्ट) स्पष्ट रूप से वर्ण l और अंक 1 में अंतर नहीं दिखाता. 
यह समस्या उन सिस्टमों में अधिक गंभीर है जो अन्तराष्ट्रीयकृत डोमेन नामों का समर्थन करते हैं। 
चूंकि कई अक्षर हैं जो ISO 10646 के दृष्टिकोण से अलग हैं, 
कुछ खास कंप्यूटर स्क्रीन पर समान दिखाई देते हैं। इस कमजोरी का फायदा अक्सर फ़िशिंग में उठाया जाता है।
कुछ फॉरवर्ड कनफर्म्ड रिवर्स DNS तकनीकों द्वारा भी DNS परिणाम मान्य करने में सहायता मिलती है।
.

दुरुपयोग और विनियमन

आलोचक अक्सर डोमेन नाम पर प्रशासनिक सत्ता के दुरुपयोग का दावा करते हैं। विशेष रूप से उल्लेखनीय VeriSign साइट खोजक प्रणाली है जो सभी अपंजीकृत .Com और .NET डोमेन को VeriSign वेबपेज पर भेज देती थी। उदाहरण के लिए, VeriSign के साथ एक सार्वजनिक सभा में SiteFinder के बारे में तकनीकी चिंताओं पर बहस करते हुए, IETF और अन्य तकनीकी संस्थाओं में सक्रिय कई लोगों ने समझाया कि वे कैसे VeriSign द्वारा, इंटरनेट की बुनियादी सुविधाओं के एक प्रमुख घटक के बदलने से चकित थे, जिसने इसके लिए आम सहमति प्राप्त नहीं की थी। पहले पहल SiteFinder को, वेबसाइट से हर इंटरनेट पूछताछ के लिए प्रयुक्त किया गया और इसने धन कमाने के लिए प्रश्नों के लिए गलत डोमेन नाम का प्रयोग उपयोगकर्ता को VeriSign खोज साइट पर ले जा कर किया। दुर्भाग्य से, अन्य एप्लीकेशन जैसे कि ईमेल के कई प्रयोगों, प्रश्न के उत्तर की कमी के कारणों, ने एक संकेत दिया कि डोमेन मौजूद नहीं है और यह संदेश न भेजे सकने योग्य सन्देश के रूप में समझा जा सकता है। मूल VeriSign कार्यान्वयन ने मेल के लिए इस धारणा को तोड़ दिया, क्योंकि वह हमेशा गलत डोमेन नाम को SiteFinder पर भेज देते थे। जबकि VeriSign ने बाद में ईमेल के साथ SiteFinder का व्यवहार बदल दिया, फिर भी VeriSign द्वारा किये गये इस कृत्य के बारे में घोर विरोध प्रदर्शन किया गया कि कैसे VeriSign ने इंटरनेट संरचना घटक, जिसकी सुरक्षा का जिम्मेवार VeriSign था, के हित के बजाए अपने वित्तीय हितों की तरफ अधिक ध्यान दिया।
व्यापक आलोचना के बावजूद, VeriSign ने अनिच्छा से इसे हटाया जब नाम और नंबर प्रदान करने के लिए इंटरनेट कॉरपोरेशन (ICANN) ने रूट नाम सर्वर के प्रबंधन के अनुबंध को रद्द करने की धमकी दी। ICANN ने व्यापक संख्या में विचार विमर्श पत्र, समिति की रिपोर्ट और ICANN के निर्णय सार्वजनिक किए। 
ICANN पर अमेरिका के राजनीतिक प्रभाव के बारे में बेचैनी भी महत्वपूर्ण है। यह एक .XXX -शीर्ष स्तर डोमेन को बनाने के प्रयास के दौरान एक महत्वपूर्ण मुद्दा था और इसने वैकल्पिक DNS रूट की ओर ध्यान खींचा जो किसी एक देश के नियंत्रण से बाहर होगा। 
इसके अतिरिक्त, डोमेन नेम "फ्रंट रनिंग" सम्बंधित कई आरोप हैं, जिसके तहत रजिस्ट्रार को जब whois प्रश्न दिए जाते हैं, स्वचालित रूप से अपने लिए डोमेन नाम रजिस्टर कर लेते हैं। हाल ही में, नेटवर्क सोल्यूशन पर इस का आरोप लगाया गया है।

डोमेन नाम अधिनियम का सत्य

संयुक्त राज्य अमेरिका में, डोमेन नाम में सत्य के अधिनियम 2003 व 2003 के रक्षा अधिनियम का संयोजन, भ्रामक डोमेन नामों का उपयोग बैन करता है जो लोगों को इंटरनेट पर अश्लील साहित्य युक्त साइटों पर जाने के लिए आकर्षित करते हैं।