सभी DNS अनुरोधों को संभालने के लिए रूट नाम सर्वर के लिए यह कैसे संभव है?


18

मैं कुछ दिनों पहले डीएनएस के बारे में पढ़ रहा था और सीखा कि अनुरोध कैसे संसाधित होते हैं। यदि आप www.example.com पर सर्फ करते हैं, तो एक अनुरोध रूट नाम सर्वर पर जाएगा। यह देखने के लिए कि कौन उस .com पते का मालिक है, फिर एक और अनुरोध दूसरे, अधिक स्थानीय, DNS सर्वर पर जाएगा, यह देखने के लिए कि कौन example.com का मालिक है। पता वगैरह।

यह कैसे संभव है कि 13 रूट नाम सर्वर ddos: ed को देखे बिना पृथ्वी के अरबों इंटरनेट उपयोगकर्ताओं द्वारा किए गए सभी अनुरोधों को एक साथ पूरी तरह से संभाल सकते हैं?


11
वैसे, डीएनएस के काम करने के तरीके का आपका सारांश गलत है। रूट नाम सर्वर से पूछा गया प्रश्न "कौन मालिक है .com?" लेकिन "www.example.com का IP पता क्या है?" (रूट नाम सर्वर .com के स्वामी के संदर्भ में उत्तर देता है)। रूट नाम सर्वर संपूर्ण क्वेरी (जो आंकड़े, डेटा खनन, आदि के लिए उपयोगी है) को देखता है।
बोर्त्ज़मेयेर

@bortzmeyer पूरे सर्वर को मूल नाम भेजे जाने का मुख्य कारण यह है कि नाम का प्रत्येक बिंदु आवश्यक रूप से प्राधिकरण की सीमा नहीं है। व्यवहार में, मेरा मानना ​​है कि TLD के ठीक नीचे हमेशा एक सीमा होती है, लेकिन सिद्धांत रूप में इसकी गारंटी नहीं है। इसलिए भविष्य में किसी बिंदु पर एक विशेष TLD शुरू करने का निर्णय लिया जा सकता है जहां दूसरी परत को रूट सर्वर द्वारा नियंत्रित किया जाता है जैसे कि जब आप रूट सर्वर को क्वेरी करते हैं तो आपको a.b.c.exampleबताया जाएगा कि इसके लिए c.exampleकौन जिम्मेदार है example
kasperd

जवाबों:


51

वे सर्वर के 13 अत्यधिक उपलब्ध क्लस्टर हैं, न कि केवल 13 सर्वर।

अन्य चीजों के अलावा, रूट नेमसेवर ऑपरेटरों को अपने सामान्य ट्रैफिक लोड ( RFC 2870 ) को तीन गुना संभालने के लिए पर्याप्त क्षमता की आवश्यकता होती है । यह बल्कि बड़े समूहों की ओर जाता है।

हालांकि, रूट नेम सर्वर केवल यानी उच्च स्तरीय डोमेन के लिए प्रतिक्रियाओं खुद को, की सेवा com., net., uk., ae., आदि, और नेमसर्वर जो क्वेरी जड़ इस जानकारी को कैश कर सकते 48 घंटे तक का है, जो नाटकीय रूप से रूट नेम सर्वर पर लोड कम कर देता है। यह छोटे समूहों की ओर जाता है।

रूट नेमवेरर्स 53 देशों में 130 से अधिक भौतिक स्थानों पर हैं; केवल 13 सर्वर नामों के साथ, यह आईपीवी 4 किसी भी मैजिक के माध्यम से किया जाता है।

रूट नेमवेर्स की अपनी वेब साइट भी है , जो आपको दिलचस्प पढ़ने में मिल सकती है।


48 h रूट पर NS रिकॉर्ड्स का TTL है। लेकिन यह TLD के नाम सर्वर द्वारा ही ओवरराइड किया जा सकता है। उदाहरण के लिए, .jp के लिए, यह केवल 24 घंटे है।
bortzmeyer

खैर, हम यहां रूट नेमवेर्स की बात कर रहे हैं। :)
माइकल हैम्पटन

RFC 2870 आज काफी पुराना है। DDoS हमलों के कारण, एक रूट नाम सर्वर को अपने सामान्य ट्रैफिक के तीन गुना से अधिक जवाब देने के लिए तैयार रहना पड़ता है।
बोर्त्ज़मेयर

8
53 देश? क्या यह एक संयोग है या उन्होंने इसे DNS क्वेरी पोर्ट की तरह चुना है ?? : D
amyassin

10

वे नहीं करते। रूट नेमसर्वर को आपको केवल यह बताना है कि नेमवेर्सर्स क्या संभालते हैं com। तब से, आपको अंदर किसी भी डोमेन को संभालने के लिए उनके पास जाने की आवश्यकता नहीं है com। रूट नेमवेर्स का कोई पता नहीं है कि कौन मालिक है example.com। वे रूट नेमवेर्स हैं, कॉम नेमसर्वर नहीं ।

Slimsuperhero ने जो कहा वह भी सच है। कई उच्च मात्रा नेमसर्वर का उपयोग एनीकास्ट दुनिया भर के सर्वर की एक संख्या से सेवा की एक ही आईपी पते है।


लेकिन अगर 1 बिलियन उपयोगकर्ता एक ही सेकंड में विभिन्न .com adresses के लिए सर्फिंग कर रहे थे, तो क्या रूट नाम सर्वर सभी अनुरोधों को संभाल लेंगे?
रॉक्स

3
नहीं। एक बात के लिए, उपयोगकर्ता केवल पुनरावर्ती नेमसर्वरों से बात करते हैं (वे जो उत्तर पाने के लिए अन्य नेमसर्वरों से जुड़ते हैं) और मूल नेमसर्वर पुनरावर्ती नहीं होते हैं (वे केवल स्थानीय जानकारी की सेवा करते हैं जो वे पहले से जानते हैं)। उपभोक्ता अपनी स्वयं की नेमसर्वर (आम तौर पर उनके आईएसपी द्वारा प्रदान की) जो केवल रूट नेम सर्वर को पूछने की आवश्यकता से बात एक बार है कि संभाल सर्वर के लिए com
डेविड श्वार्ट्ज

1
@DavidSchwartz सही है - इसलिए एक बिलियन उपयोगकर्ताओं से एक बिलियन अनुरोधों के बजाय उन्हें केवल एक मिलियन आईएसपी से लगभग एक मिलियन अनुरोध प्राप्त होंगे, जिनमें से प्रत्येक एक हजार उपयोगकर्ताओं को सेवा प्रदान करता है।
शादुर

@ शशूर: अब, comदूसरी ओर नेमवियर्स के लिए बहुत अधिक भारी पिटाई होनी चाहिए।
डेविड श्वार्ट्ज

1
और मुझे पूरा यकीन है कि वे बड़े पैमाने पर और उचित रूप से क्लस्टर किए गए हैं।
Shadur

6

प्रत्येक रूट सर्वर वास्तव में सर्वर नहीं है, वे सर्वर के विशाल क्लस्टर हैं। इसके अतिरिक्त, DNS उत्तर कैश किए जाते हैं इसलिए हर अनुरोध रूट सर्वर तक नहीं पहुंचता है।


3

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


0

वास्तव में इसका 13 एनीकास्ट आईपी पता है जो दुनिया भर में बहुत सारे सर्वरों को हल करता है। यदि आवश्यक हो तो आप उन सर्वरों को खोजने के लिए लिंक को देख सकते हैं। ये सभी सर्वर संबंधित प्राधिकरण द्वारा प्रबंधित किए जाते हैं।

तथ्य यह है कि हम अभी भी केवल 13 आईपी पते का उपयोग कर रहे हैं (और समान आईपी पते वाले सर्वर का क्लस्टर) यह सुनिश्चित करना है कि पैकेट आकार अभ्यस्त 512 बाइट्स से आगे नहीं जाता है। तब क्यों? हमारे पास टीसीपी है जो इस पैकेट आकार से परे जा सकता है कि हम इसका उपयोग क्यों नहीं कर सकते? बात यह है कि, टीसीपी में बहुत अधिक ओवरहेड शामिल है क्योंकि इसमें टीसीपी कनेक्शन स्थापित करने के लिए कई चरण और प्रक्रियाएं शामिल हैं। इस वजह से, DNS क्वेरी की पूरी प्रक्रिया धीमी हो जाएगी।

DNS जैसी चीजें कभी धीमी नहीं हो सकती हैं और इसीलिए हम अभी भी उसी पुराने सिस्टम का इस्तेमाल करते हैं।


.512 बाइट्स के लिए क्वेरी का उत्तर अब फिट नहीं है। क्योंकि IPv6 अब एक आवश्यकता है, उत्तर 811 बाइट्स तक बढ़ गया है। EDNS के साथ जो एक ही प्रतिक्रिया में वापस किया जा सकता है। हालाँकि प्रश्नों .की इतनी बार जरूरत नहीं होती है कि कुछ राउंड ट्रिप्स शोस्टॉपर हैं। यह मुख्य रूप से पुनरावर्तकों के लिए जड़ों के आईपी पते के नवीनतम परिवर्तनों को जानने के लिए आवश्यक है, जो शायद ही कभी बदलते हैं।
कास्परड

@kasperd मुझे यकीन नहीं है। मैंने सामान्य ए रिकॉर्ड या AAAA रिकॉर्ड के लिए डिग + ट्रेस की जांच की और सभी प्रतिक्रियाएं (रूट स्तर के सर्वर, शीर्ष स्तर के सर्वर या नेमवेर्स से) 508 से 509 बाइट्स के अंतर्गत हैं। क्या आप इसके बारे में थोड़ा और समझा सकते हैं।
२०:०२ पर जैसन

पूर्ण प्रतिक्रिया प्राप्त करने के लिए आपको ईडीएनएस या टीसीपी का उपयोग करने की आवश्यकता है। EDNS के बिना UDP अनुरोधों को 512 बाइट्स की तुलना में कभी भी प्रतिक्रिया नहीं मिल सकती है।
कास्परड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.