DNS नाम रिज़ॉल्यूशन कैसे काम करता है, सिद्धांत रूप में?

Question

अभी मैं Linux sysadmin के लिए एक ऑनलाइन पाठ्यक्रम ले रहा हूं और मुझसे एक प्रश्न पूछा गया था जिसे मैं आमतौर पर नहीं समझता। मुझे पता है कि मुझे नाम सर्वर की खोज कैसे करनी है, अगर मैं कम से कम सही हूं तो अतिरिक्त अनुभाग कमांड में पता खोजने के लिए खुदाई कमांड का उपयोग कर रहा हूं, लेकिन निम्नलिखित प्रश्न पूछे जाने पर मैं थोड़ा खो गया।

मान लिया गया है कि आपके कॉन्फ़िगर किए गए नेमसर्वर के पास इसके निपटान में कोई भी कैश्ड परिणाम नहीं है, maps.google.com को हल करने के लिए कितने नेमसर्वर को आपकी नेमसेवर क्वेरी की आवश्यकता होगी? इन सभी नाविकों को खोजने के लिए आप किस कमांड का उपयोग करेंगे? प्रत्येक स्तर से एक सूची दें और बताएं कि इस स्तर की आवश्यकता क्यों है।

मुझे उत्तर नहीं चाहिए, मैं सिर्फ यह जानना चाहूंगा कि मुझे वास्तव में क्या करने के लिए कहा जा रहा है।

Comments

मैं सोच रहा था dig +trace, लेकिन मुझे यकीन नहीं है कि स्तरों से क्या मतलब है। यह सर्वर दोष के लिए एक प्रश्न हो सकता है।

— बिग मैकलारेग्यूज

हाय linux8807। मैंने आपके प्रश्न को उम्मीद से अधिक स्पष्ट करने के लिए संपादित किया; विशेष रूप से, मैंने इस पर एक बेहतर शीर्षक लगाने की कोशिश की। यदि आपको लगता है कि मैंने आपका इरादा बदल दिया है, तो संपादन को वापस करने के लिए स्वतंत्र महसूस करें ("संशोधित" लिंक पर क्लिक करें और फिर मूल संशोधन के ऊपर "रोलबैक")।

— एक CVn a

मुझे लगता है कि यह वीडियो इसे समझाता है: youtube.com/watch?v=2ZUxoi7YNgs

Answer 1

मान लिया गया है कि आपके कॉन्फ़िगर किए गए नेमसर्वर के पास इसके निपटान में कोई भी कैश्ड परिणाम नहीं है, maps.google.com को हल करने के लिए कितने नेमसर्वर को आपकी नेमसेवर क्वेरी की आवश्यकता होगी? इन सभी नाविकों को खोजने के लिए आप किस कमांड का उपयोग करेंगे? प्रत्येक स्तर से एक सूची दें और बताएं कि इस स्तर की आवश्यकता क्यों है।

अच्छा, चलो इस एक को अलग करो।

"मान लिया गया है कि आपके कॉन्फ़िगर किए गए नेमसर्वर के पास अपने निपटान में कोई कैश्ड परिणाम नहीं है" - सबसे पहले, यदि उसके पास कोई कैश्ड डेटा नहीं है , तो वह कुछ भी हल नहीं कर सकता है। रिज़ॉल्वर के कैश को प्राइम करने के लिए, आपके पास .(AKA रूट) ज़ोन के लिए NS और एड्रेस (A, AAAA) रिकॉर्ड होना चाहिए । यह रूट नाम सर्वर है, जो root-servers.net.जोन में पाए जाते हैं । उस क्षेत्र या उन DNS सर्वरों के बारे में कुछ भी जादुई नहीं है। हालाँकि, यह डेटा अक्सर DNS रिज़ॉल्वर को "बैंड से बाहर" प्रदान किया जाता है, जो कि रिज़ॉल्वर के कैश को प्राइम करने के लिए ठीक है। आधिकारिक-केवल नाम सर्वर को इस डेटा की आवश्यकता नहीं है, लेकिन नाम सर्वरों को हल करना है।

इसके अलावा, क्या करने के लिए "संकल्प"? उस नाम पर कोई RRtype? एक Aआरआर? या कुछ और? क्या वर्ग ( CH/ Chaosnet, IN/ इंटरनेट, ...)? सटीक प्रक्रिया अलग होगी, लेकिन सामान्य विचार समान है।

यदि हम मान सकते हैं कि हम जानते हैं कि रूट नाम सर्वरों को कैसे खोजना है, लेकिन इससे अधिक कुछ नहीं, और "समाधान" से हमारा मतलब है IN Aकि नाम के साथ जुड़े किसी भी आरआर की सामग्री प्राप्त करना , यह बहुत अधिक व्यावहारिक हो जाता है।

DNS नाम को हल करने के लिए, आप मूल रूप से नाम को लेबल में विभाजित करते हैं और फिर दाईं ओर से बाईं ओर अपना काम करते हैं। .अंत में मत भूलना ; आप वास्तव में maps.google.com.बजाय हल हो जाएगा maps.google.com। जो हमें हल करने की आवश्यकता के साथ छोड़ देता है (हम यह जानते हैं, लेकिन एक DNS रिज़ॉल्वर कार्यान्वयन शायद नहीं होगा):

• .
• com.
• google.com.
• maps.google.com.

पता लगाने के साथ शुरू करें कि सामग्री कहां से मांगनी है .। यह आसान है; हमारे पास पहले से ही वह जानकारी है: रूट नाम सर्वर नाम और आईपी पते । इसलिए हमारे पास एक रूट नाम सर्वर है। मान लें कि हम 198.41.0.4 का उपयोग करने का निर्णय लेते हैं (नाम a.root-servers.net, 2001: 503: ba3e :: 2: 30) नाम संकल्प को जारी रखने के लिए। व्यवहार में, रिज़ॉल्वर द्वारा की गई पहली चीजों में से एक रूट ज़ोन सर्वर से रूट ज़ोन के लिए नाम सर्वरों की सटीक सूची के लिए पूछने के लिए प्रदान किए गए रूट सर्वर डेटा का उपयोग करने की संभावना होगी, इस प्रकार यह सुनिश्चित करना कि यदि कोई हो नाम और आईपी पते वैध और पहुंच योग्य हैं, इसका संकल्प शुरू होने पर रूट ज़ोन के लिए डेटा का एक पूर्ण और पूरा सेट होगा।

maps.google.com. IN A198.41.0.4 के लिए DNS क्वेरी बंद करें । यह आपको जवाब में बताएगा कि "नहीं, यह मत करो, लेकिन यहाँ कोई है जो शायद जानता हो"; यह एक रेफरल है। इसमें NSनिकटतम क्षेत्र के रिकॉर्ड होते हैं, जिसके बारे में सर्वर को पता होता है कि किसी भी ग्लू रिकॉर्ड के साथ सर्वर उपलब्ध है। यदि कोई गोंद डेटा उपलब्ध नहीं है, तो आपको सबसे पहले उस एनएस रिकॉर्ड में नामित होस्ट को हल करना होगा जिसे आपने चुना था, इसलिए आईपी पते को प्राप्त करने के लिए एक अलग नाम का प्रस्ताव रखें; यदि गोंद डेटा उपलब्ध है, तो आपके पास एक नाम सर्वर का आईपी पता होगा जो उत्तर के लिए कम से कम "करीब" होगा। इस स्थिति में, यह com.क्षेत्र के लिए सर्वर का सेट होगा , और गोंद डेटा भी प्रदान किया जाएगा।

com.नाम सर्वर से एक ही सवाल पूछते हुए प्रक्रिया को दोहराएं । वे या तो नहीं जानते हैं, लेकिन आपको Google के आधिकारिक नाम सर्वरों के लिए संदर्भित करेंगे। इस बिंदु पर सामान्य मामले में यह हिट हो जाएगा या याद रखेगा कि गोंद डेटा प्रदान किया गया है या नहीं; comडोमेन को केवल नाम सर्वर में रखने से रोकने के लिए कुछ नहीं है nl, उदाहरण के लिए, जिस स्थिति में gTLD सर्वर से गोंद डेटा उपलब्ध होने की संभावना नहीं है। प्रदत्त गोंद डेटा भी अधूरा हो सकता है, या यदि आप वास्तव में अशुभ हैं तो यह गलत भी हो सकता है! आपको हमेशा उस अलग नाम प्रस्ताव को बंद करने के लिए तैयार रहना होगा जिसका मैंने ऊपर उल्लेख किया था।

मूल रूप से, आप तब तक चलते रहते हैं जब तक आपको aa(आधिकारिक उत्तर) ध्वज सेट के साथ उत्तर नहीं मिल जाता है । यही कारण है कि इस सवाल का जवाब आपको बता देंगे आप जो चाह रहे हैं, या जो RR आप के लिए मौजूद नहीं है (या तो पूछा NXDOMAIN, या NOERRORशून्य प्रतिक्रिया डेटा रिकॉर्ड के साथ)। प्रतिक्रियाओं की तलाश में रहें SERVFAIL(और एक कदम पीछे हटें और एक सर्वर प्राप्त करें, यदि आप एक प्राप्त करते हैं; यदि सभी नामित सर्वर वापस आते हैं SERVFAIL, तो नाम समाधान प्रक्रिया विफल हो जाती है और SERVFAILग्राहक को वापस आ जाती है )।

प्रत्येक सर्वर से पूर्ण RRname के लिए पूछने का विकल्प (जिसे बुरा व्यवहार माना जा सकता है) लेबल की विभाजित सूची का उपयोग करना है जिसे हमने पहले निर्धारित किया था, सर्वर द्वारा दिए गए नाम सर्वर से आगे रूट IN NSऔर IN A/ IN AAAARRs की ओर पूछें उस लेबल के लिए, और नाम समाधान प्रक्रिया को आगे बढ़ाने के लिए उन का उपयोग करें। यह व्यवहार में केवल थोड़ा भिन्न है, और यही प्रक्रिया अभी भी लागू होती है।

आप इस पूरी प्रक्रिया +traceको digउपयोगिता के विकल्प का उपयोग करके अनुकरण कर सकते हैं , जो कि BIND के हिस्से के रूप में, या set debugअंदर आता है nslookup।

यह भी याद रखने योग्य है कि कुछ RRtypes (विशेष रूप NSसे MXऔर कुछ अन्य; भी, A6कुछ समय के लिए यथोचित रूप से अच्छी तरह से उपयोग किए गए थे, लेकिन अन्य आरआरएस को संदर्भित कर सकते हैं)। उस स्थिति में, आपको अपने ग्राहक को पूर्ण और उपयोगी उत्तर देने के लिए एक और नाम समाधान प्रक्रिया शुरू करनी होगी।

Comments

मुझे लगता है कि यह उत्तर केवल प्रक्रिया के बजाय अवधारणाओं को समझने के लिए ओपी के अनुरोध के साथ काफी इनलाइन है।

— 111 ---

तो मैं जो कर रहा हूं वह है maps.google.com को A में खोदना, फिर मैं उसी तरह खुदाई करूंगा लेकिन ns1.google.com के साथ यदि यह सही है, यदि वह है, तो शिक्षक किस स्तर की बात कर रहे हैं और वे क्यों करेंगे जरूरत हो?

— linux8807

@ linux8807 digns1.google.com नाम के लिए आप एक बार इसे प्राप्त करने के लिए एक रेफरल प्राप्त करेंगे जो प्रदान किए गए गोंद रिकॉर्ड में एक आईपी पता शामिल नहीं है। फिर आप पिछले नाम समाधान प्रक्रिया के साथ जारी रहेंगे।

— एक सीवीएन

@ MichaelKjörling सभी ns1-4.google.com रिकॉर्ड्स में ग्लू रिकॉर्ड्स में एक IP एड्रेस होता है। i.imgur.com/o79aIGB.png

— linux8807

@ linux8807 बहुत बार ऐसा होगा जब ग्लू रिकॉर्ड उसी TLD के अंतर्गत होगा जिस डोमेन के लिए क्वेर किया जा रहा है। हालाँकि आप सामान्य मामले में इस पर भरोसा नहीं कर सकते ।

— एक CVn

Answer 2

एक dnstracerकमांड है (आपको इसे स्थापित करने की आवश्यकता हो सकती है, कम से कम डेबियन पर, यह पैकेज नाम भी है) जो नाम रिज़ॉल्यूशन का पता लगाएगा। आप (एक टिप्पणी में कोवरस बताते हैं) का उपयोग भी कर सकते हैं dig।

यहाँ dnstracer के साथ है। -s .जड़ से शुरू करने का मतलब है; -4IPv4 (v6 यहाँ टूट गया है ...) का उपयोग करने का मतलब है; -oवास्तव में अंत में हल आईपी पते दिखाने के लिए (मैं आउटपुट के उस हिस्से को छोड़ दिया है, उनमें से एक बहुत हैं)।

anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ m.gtld-servers.net [com] (192.55.83.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer 
⋮

यह आउटपुट जारी रहता है, क्योंकि dnstracer सभी रास्तों का पता लगाता है (ताकि आप देख सकें कि क्या, उदाहरण के लिए, कुछ नेमसर्वर के पास एक पुराना क्षेत्र है)।

तो, आप देख सकते हैं कि यह एक क्वेरी को रूट नाम सर्वर पर ले जाता है, फिर एक से gtld- सर्वर (.com ज़ोन के लिए सर्वर), अंत में एक Google नेमसर्वर के लिए ले जाता है।

इसके साथ dig, आउटपुट बहुत अधिक क्रिया है (इसलिए मैं बहुत कटिंग करूंगा):

dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
.                       425379  IN      NS      b.root-servers.net.
⋮
com.                    172800  IN      NS      f.gtld-servers.net.
⋮
google.com.             172800  IN      NS      ns2.google.com.
⋮
maps.google.com.        300     IN      A       74.125.228.70
⋮

digइसके अतिरिक्त पता चलता है कि इसने रूट नेमवेरर्स की वर्तमान सूची प्राप्त करने के लिए एक क्वेरी की। यह एक ऐसी चीज है जिसे डीएनएस सर्वर आमतौर पर बहुत बार करता है। इसलिए मुझे यकीन नहीं है कि आप इसे अपने ठंडे कैश मामले में गिनेंगे।

आप बेशक, उदाहरण के लिए, तार पर वास्तविक प्रश्नों को देख सकते हैं wireshark।

Comments

मैं कुछ भी स्थापित नहीं कर पाऊंगा क्योंकि यह टर्मिनल में सेटअप है, लेकिन एक बार जब मैं काम से घर पहुंचता हूं तो मैं dnstracer की कोशिश करूंगा और देखूंगा कि क्या वह काम करता है, और क्या वह * (216.239.38.10) (216.239.36.10) के लिए पूछ रहा है 216.239.32.10) (216.239.34.10) * यह? यदि हां, तो मैं पहले से ही इस बात का उपयोग करने में सक्षम हूं, लेकिन एक आधिकारिक जवाब के साथ नहीं। इसके अलावा, यह वह है जिसे वह स्तरों से संदर्भित कर रही है?

— linux8807

@ linux8807 digयदि आपके पास नहीं है dnstracer(या यदि आपको digस्वरूपण पसंद है ) तो आप इसका उपयोग कर सकते हैं । IP पते dnstracer आउटपुट कर रहे हैं, नेमसर्वरों के IP पते हैं; उनके नाम बाईं ओर हैं। a.root-servers.net 198.41.0.4 है, आदि वे सर्वर हैं, जो चौकस हैं, और यह आपको बताता है कि किस क्षेत्र के साथ-साथ वर्ग कोष्ठक में भी। मुझे संदेह है कि पहला स्तर है * .root-server.net (के लिए .), दूसरा है * .gtld-server.net (के लिए .com), आदि

— अपमानजनक