वास्तव में, यह उससे अधिक जटिल है - बल्कि एक "केंद्रीय रजिस्ट्री (जो) एक तालिका रखती है जो DNS सर्वरों के लिए डोमेन (www.mysite.com) को मैप करती है", पदानुक्रम की कई परतें हैं
- उच्च-स्तरीय डोमेन सभी के लिए एन एस (नेम सर्वर) रिकॉर्ड: वहाँ एक केंद्रीय रजिस्ट्री (रूट सर्वर) जो केवल प्रविष्टियों का एक छोटा सा समूह होता है .com, .net, .org, .uk, .us, .au, और इतने पर।
उन सर्वरों में अगले स्तर के लिए एनएस रिकॉर्ड होते हैं। एक उदाहरण लेने के लिए, के लिए नेमसर्वर .ukडोमेन बस के लिए प्रविष्टियां हैं .co.uk, .ac.ukऔर ब्रिटेन में उपयोग में अन्य दूसरे स्तर के क्षेत्रों।
उन सर्वरों में बस अगले स्तर के लिए एनएस रिकॉर्ड होते हैं - उदाहरण जारी रखने के लिए, वे आपको बताते हैं कि एनएस रिकॉर्ड कहां खोजना है google.co.uk। यह उन सर्वरों पर है, जिन्हें आप अंततः होस्टनाम जैसे www.google.co.ukआईपी पते के बीच मैपिंग पाएंगे ।
एक अतिरिक्त शिकन के रूप में, प्रत्येक परत 'गोंद' रिकॉर्ड की भी सेवा करेगी। प्रत्येक NS रिकॉर्ड एक डोमेन को होस्टनाम के लिए मैप करता है - उदाहरण के लिए, सर्वर में से एक के रूप में .ukसूची के लिए एनएस रिकॉर्ड nsa.nic.uk। अगले स्तर तक पहुंचने के लिए, हमें एनएस के रिकॉर्ड्स का पता लगाना होगा nic.uk, और वे इसे भी शामिल करना चाहते हैं nsa.nic.uk। तो अब हमें आईपी पता करने की आवश्यकता है nsa.nic.uk, लेकिन यह पता लगाने के लिए कि हमें एक क्वेरी बनाने की आवश्यकता है nsa.nic.uk, लेकिन हम उस क्वेरी को तब तक नहीं बना सकते जब तक हम आईपी के लिए नहीं जानते nsa.nic.uk...
इस उलझन को हल करने के सर्वरों के लिए .ukके लिए एक रिकॉर्ड जोड़ने nsa.nic.ukमें ADDITIONAL SECTIONप्रतिक्रिया (संक्षिप्तता के लिए छंटनी की नीचे प्रतिक्रिया) का:
jamezpolley@li101-70:~$dig nic.uk ns
; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;nic.uk. IN NS
;; ANSWER SECTION:
nic.uk. 172800 IN NS nsb.nic.uk.
nic.uk. 172800 IN NS nsa.nic.uk.
;; ADDITIONAL SECTION:
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
इन अतिरिक्त गोंद रिकॉर्ड के बिना, हम कभी भी नेमसर्वर खोजने में सक्षम नहीं होंगे nic.uk.और इसलिए हम कभी भी वहां होस्ट किए गए किसी भी डोमेन को नहीं देख पाएंगे।
अपने प्रश्नों पर वापस जाने के लिए ...
क) क्या फायदा है? सीधे आईपी पते पर मैप क्यों नहीं?
एक बात के लिए, यह प्रत्येक व्यक्ति के क्षेत्र को वितरित करने के लिए संपादन की अनुमति देता है। यदि आप प्रविष्टि के लिए अद्यतन करना चाहते हैं www.mydomain.co.uk, तो आपको बस अपने mydomain.co.ukनाम के अनुसार जानकारी को संपादित करने की आवश्यकता है । केंद्रीय .co.ukसर्वर, या .ukसर्वर या रूट नेमसर्वर को सूचित करने की कोई आवश्यकता नहीं है । यदि केवल एक ही केंद्रीय रजिस्ट्री थी, जो पदानुक्रम के सभी स्तरों को मैप करती थी, जिसे एक डीएनएस प्रविष्टि के हर एक बदलाव के बारे में अधिसूचित किया जाना था, जो श्रृंखला के नीचे सभी तरह से होती है, तो यह ट्रैफ़िक के साथ पूरी तरह से स्वाहा हो जाएगा।
1982 से पहले, यह वास्तव में कैसे नाम संकल्प हुआ था। एक केंद्रीय रजिस्ट्री को सभी अपडेट के बारे में सूचित किया गया था, और उन्होंने एक फाइल वितरित की, hosts.txtजिसमें इंटरनेट पर प्रत्येक मशीन के होस्टनाम और आईपी पते शामिल थे। इस फ़ाइल का एक नया संस्करण हर कुछ हफ्तों में प्रकाशित किया गया था, और इंटरनेट पर हर मशीन को एक नई प्रति डाउनलोड करनी होगी। अच्छी तरह से 1982 से पहले, यह समस्याग्रस्त होने लगा था, और इसलिए डीएनएस का आविष्कार अधिक वितरित प्रणाली प्रदान करने के लिए किया गया था।
एक और बात के लिए, यह विफलता का एक एकल बिंदु होगा - यदि एकल केंद्रीय रजिस्ट्री नीचे चली गई, तो पूरा इंटरनेट ऑफ़लाइन होगा। एक वितरित प्रणाली होने का मतलब है कि विफलताएं केवल इंटरनेट के छोटे वर्गों को प्रभावित करती हैं, न कि पूरी चीज को।
(अतिरिक्त अतिरेक प्रदान करने के लिए, वास्तव में सर्वर के 13 अलग-अलग क्लस्टर हैं जो रूट ज़ोन की सेवा करते हैं। शीर्ष-स्तर के डोमेन रिकॉर्ड में कोई भी परिवर्तन सभी 13 को धकेलना होगा; हर एक बदलाव के लिए उनमें से सभी 13 को अपडेट करने के लिए समन्वय करने की कल्पना करना; दुनिया में कहीं भी किसी भी hostname ...)
b) यदि एक ही रिकॉर्ड जिसे बदलने की आवश्यकता है जब मैं एक DNS सर्वर को एक अलग आईपी पते पर इंगित करने के लिए कॉन्फ़िगर कर रहा हूं, तो DNS सर्वर पर स्थित है, तो प्रक्रिया तत्काल क्यों नहीं है?
क्योंकि DNS दोनों चीजों को गति देने और एनएसई पर लोड को कम करने के लिए बहुत सारे कैशिंग का उपयोग करता है। कैशिंग के बिना, हर बार जब आप google.co.ukअपने कंप्यूटर का दौरा करते हैं .uk, तब .co.uk, तब .google.co.uk, उसके लिए सर्वर को देखने के लिए नेटवर्क पर जाना होगा www.google.co.uk। वे जवाब वास्तव में ज्यादा नहीं बदलते हैं, इसलिए उन्हें हर बार देखना समय और नेटवर्क यातायात की बर्बादी है। इसके बजाय, जब NS आपके कंप्यूटर पर रिकॉर्ड करता है, तो इसमें एक TTL मान शामिल होगा, जो आपके कंप्यूटर को कई सेकंड के लिए परिणामों को कैश करने के लिए कहता है।
उदाहरण के लिए, एनएस के .ukपास 172800 सेकंड का टीटीएल है - 2 दिन। Google और भी अधिक रूढ़िवादी हैं - एनएस के google.co.ukपास 4 दिनों का टीटीएल है। जो सेवाएं जल्दी से अपडेट करने में सक्षम होने पर भरोसा करती हैं, वे बहुत कम टीटीएल चुन सकती हैं - उदाहरण के लिए, telegraph.co.ukउनके एनएस रिकॉर्ड पर सिर्फ 600 सेकंड का टीटीएल है।
यदि आप अपने ज़ोन के अपडेट निकट-तत्काल होना चाहते हैं, तो आप अपनी टीटीएल को नीचे की तरफ जितना चाहें उतना कम चुन सकते हैं। जितना कम आपका यह सेट होगा, उतना ही अधिक ट्रैफ़िक आपके सर्वर को दिखाई देगा, क्योंकि क्लाइंट अपने रिकॉर्ड को अधिक बार ताज़ा करते हैं। जब भी किसी क्लाइंट को क्वेरी करने के लिए आपके सर्वर से संपर्क करना पड़ता है, तो यह कुछ अंतराल का कारण होगा क्योंकि यह उनके स्थानीय कैश पर जवाब देखने की तुलना में धीमा है, इसलिए आप तेज़ अपडेट और तेज़ सेवा के बीच ट्रेडऑफ़ पर भी विचार करना चाहेंगे।
ग) यदि देरी का एकमात्र कारण डीएनएस कैश हैं, तो क्या उन्हें बायपास करना संभव है, इसलिए मैं देख सकता हूं कि वास्तविक समय में क्या हो रहा है?
हां, यह आसान है यदि आप मैन्युअल रूप से digया समान टूल के साथ परीक्षण कर रहे हैं - बस इसे बताएं कि किस सर्वर से संपर्क करना है।
यहाँ कैश्ड प्रतिक्रिया का एक उदाहरण दिया गया है:
jamezpolley@host:~$dig telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 319 IN NS ns1-63.akam.net.
telegraph.co.uk. 319 IN NS eur3.akam.net.
telegraph.co.uk. 319 IN NS use2.akam.net.
telegraph.co.uk. 319 IN NS usw2.akam.net.
telegraph.co.uk. 319 IN NS use4.akam.net.
telegraph.co.uk. 319 IN NS use1.akam.net.
telegraph.co.uk. 319 IN NS usc4.akam.net.
telegraph.co.uk. 319 IN NS ns1-224.akam.net.
;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb 2 05:46:02 2012
;; MSG SIZE rcvd: 198
यहां के झंडे खंड में aaध्वज नहीं है , इसलिए हम देख सकते हैं कि यह परिणाम एक आधिकारिक स्रोत से सीधे कैश के बजाय आया है। वास्तव में, हम देख सकते हैं कि यह कहा से आया है 97.107.133.4, जो लिनोड के स्थानीय डीएनएस रिज़ॉल्वर में से एक है। तथ्य यह है कि जवाब एक कैश से मेरे बहुत करीब से बाहर परोसा गया था, इसका मतलब है कि मुझे उत्तर पाने में 0msec का समय लगा; लेकिन जैसा कि हम एक क्षण में देखेंगे, मैं उस गति के लिए जो कीमत चुकाता हूं, वह यह है कि इसका उत्तर लगभग 5 मिनट का है।
लाइनोड की रिसोल्वर को बायपास करने और सीधे स्रोत पर जाने के लिए, बस उन में से एक को चुनें और सीधे इसे संपर्क करने के लिए खुदाई को कहें:
jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 600 IN NS use2.akam.net.
telegraph.co.uk. 600 IN NS eur3.akam.net.
telegraph.co.uk. 600 IN NS use1.akam.net.
telegraph.co.uk. 600 IN NS ns1-63.akam.net.
telegraph.co.uk. 600 IN NS usc4.akam.net.
telegraph.co.uk. 600 IN NS ns1-224.akam.net.
telegraph.co.uk. 600 IN NS usw2.akam.net.
telegraph.co.uk. 600 IN NS use4.akam.net.
;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb 2 05:48:47 2012
;; MSG SIZE rcvd: 198
आप देख सकते हैं कि इस बार, परिणाम सीधे स्रोत से परोसा गया - aaध्वज को नोट करें , जो इंगित करता है कि परिणाम एक आधिकारिक स्रोत से आए हैं। मेरे पहले उदाहरण में, परिणाम मेरे स्थानीय कैश से आए थे, इसलिए उनके पास aaध्वज की कमी थी । मैं देख सकता हूं कि इस डोमेन के लिए आधिकारिक स्रोत 600 सेकंड का TTL सेट करता है। स्थानीय कैश से पहले जो परिणाम मुझे मिले, उनमें सिर्फ 319 सेकंड का एक टीटीएल था, जो मुझे बताता है कि वे कैश में बैठे थे (600-319) सेकंड - लगभग 5 मिनट - इससे पहले कि मैंने उन्हें देखा।
हालांकि यहां टीटीएल केवल 600 सेकंड है, कुछ आईएसपी अपने DNS रिज़ॉल्वर को परिणाम के लिए अधिक समय तक कैश करने के लिए मजबूर कर सकते हैं - कुछ मामलों में, 24 घंटे या उससे अधिक के लिए। यह पारंपरिक है कि (हम-में-नहीं-तो-यह-यह-वास्तव में नेकसेरी-लेकिन-चलो-सुरक्षित तरीका है) मान लें कि आपके द्वारा किए गए किसी भी DNS परिवर्तन को हर जगह दिखाई नहीं देगा। 24-48 घंटे के लिए इंटरनेट।