अस्वीकरण: कोई अपराध नहीं है, लेकिन यह वास्तव में एक बुरा विचार है। मैं यह अनुशंसा नहीं करता कि कोई भी वास्तविक जीवन में ऐसा करे।
लेकिन अगर आप एक ऊब आईटी आदमी को एक प्रयोगशाला देते हैं, तो अजीब चीजें होंगी!
इस प्रयोग के लिए, मैंने सर्वर 2012 R2 पर चलने वाले Microsoft DNS सर्वर का उपयोग किया। सक्रिय निर्देशिका में DNS ज़ोन की मेजबानी करने की जटिलताओं के कारण, मैंने एक नया प्राथमिक क्षेत्र बनाया जिसका नाम टेस्टिंग डॉट कॉम है, जो AD- एकीकृत नहीं है।
इस स्क्रिप्ट का उपयोग करना:
$Count = 1
for ($x = 1; $x -lt 256; $x++)
{
for ($y = 1; $y -lt 256; $y++)
{
for ($z = 1; $z -lt 256; $z++)
{
Write-Host "1.$x.$y.$z`t( $Count )"
$Count++
dnscmd . /RecordAdd testing.com testing A 1.$x.$y.$z
}
}
}
मैं त्रुटि के बिना, नाम के लिए 65025 मेजबान रिकॉर्ड बनाने के testing.testing.com.लिए आगे बढ़ा, 1.1.1.1 से 1.1.255.255 तक शाब्दिक रूप से प्रत्येक आईपीवी 4 पता।
फिर, मैं यह सुनिश्चित करना चाहता था कि मैं त्रुटि के बिना 65536 (2 ^ 16 बिट) ए रिकॉर्ड की कुल संख्या के माध्यम से तोड़ सकता हूं, और मैं ऐसा कर सकता हूं, इसलिए मुझे लगता है कि मैं संभवतः सभी तरह से 16581375 (1.1.1.1 से 1.255) तक जा सकता था .255.255,) लेकिन मैं यहां बैठना नहीं चाहता था और इस स्क्रिप्ट को पूरी रात चलाता था।
इसलिए मुझे लगता है कि यह कहना सुरक्षित है कि ए रिकॉर्ड की संख्या के लिए कोई व्यावहारिक सीमा नहीं है जिसे आप अपने सर्वर पर अलग-अलग आईपी के साथ एक ही नाम के लिए एक ज़ोन में जोड़ सकते हैं।
लेकिन क्या यह वास्तव में ग्राहक के दृष्टिकोण से काम करेगा ?
यहाँ पर मुझे अपने ग्राहक से जैसा कि तारक द्वारा देखा गया है:
(पूर्ण आकार के लिए एक नए ब्राउज़र टैब में छवि खोलें।)
जैसा कि आप देख सकते हैं, जब मैं अपने क्लाइंट से nslookup या पिंग का उपयोग करता हूं, तो यह स्वचालित रूप से दो क्वेरीज़ जारी करता है - एक यूडीपी और एक टीसीपी। जैसा कि आप पहले से ही जानते हैं, सबसे अधिक मैं एक यूडीपी डेटाग्राम में रटना कर सकता है 512 बाइट्स, इसलिए एक बार जब यह सीमा पार हो जाती है (जैसे 20-30 आईपी पते), तो इसके बजाय टीसीपी का उपयोग करना चाहिए। लेकिन टीसीपी के साथ भी, मुझे केवल परीक्षण के लिए A रिकॉर्ड्स का एक बहुत छोटा सा उप-भाग मिल रहा है। टीसीपी क्वेरी के अनुसार 1000 रिकॉर्ड वापस किए गए। ए रिकॉर्ड्स की सूची प्रत्येक क्रमिक क्वेरी के साथ 1 से ठीक से घूमती है, ठीक उसी तरह जैसे आप राउंड-रॉबिन डीएनएस से कैसे काम करने की उम्मीद करेंगे। इन सभी के माध्यम से राउंड रॉबिन के लिए लाखों प्रश्नों को लिया जाएगा।
मैं यह नहीं देखता कि यह कैसे आपके बड़े पैमाने पर स्केलेबल, लचीला सोशल मीडिया नेटवर्क बनाने में आपकी मदद करने जा रहा है, लेकिन फिर भी आपका जवाब है।
संपादित करें: आपकी अनुवर्ती टिप्पणी में, आप पूछते हैं कि मुझे क्यों लगता है कि यह आमतौर पर एक बुरा विचार है।
मान लीजिए कि मैं एक औसत इंटरनेट उपयोगकर्ता हूं, और मैं आपकी सेवा से जुड़ना चाहूंगा। मैं अपने वेब ब्राउजर में www.bozho.biz टाइप करता हूं। मेरे कंप्यूटर पर DNS क्लाइंट को 1000 रिकॉर्ड वापस मिल जाते हैं। खैर, बुरी किस्मत, सूची में पहले 30 रिकॉर्ड गैर-उत्तरदायी हैं क्योंकि ए रिकॉर्ड की सूची को अद्यतित नहीं रखा गया है, या हो सकता है कि इंटरनेट का एक हिस्सा प्रभावित करने वाले बड़े पैमाने पर आउटेज हो। मान लीजिए कि मेरे वेब ब्राउजर के चालू होने से पहले 5 सेकंड प्रति आईपी का टाइम-आउट है और अगले की कोशिश करता है। इसलिए अब मैं यहां 2 घंटे के लिए एक कताई घंटे पर घूर कर बैठा हूं और आपकी साइट के लोड होने का इंतजार कर रहा हूं। उसके लिए किसी को भी समय नहीं मिला। और मैं केवल यह मान रहा हूं कि आपकी सेवा तक पहुँचने के लिए मेरा वेब ब्राउज़र या जो भी एप्लिकेशन मैं उपयोग करता हूं, वह पहले 4 या 5 आईपी पतों की तुलना में अधिक प्रयास करने वाला है। यह शायद नहीं होगा।
यदि आपने स्वचालित स्केवेंजिंग का उपयोग किया है और ए रिकॉर्ड्स की सूची को ताज़ा रखने की उम्मीद में डीएनएस क्षेत्र में गैर-वैध या अनाम अपडेट की अनुमति देते हैं ... बस कल्पना करें कि यह कितना असुरक्षित होगा! यहां तक कि अगर आपने कुछ सिस्टम को इंजीनियर किया है, जहां क्लाइंट को क्लाइंट टीएलएस प्रमाणपत्र की आवश्यकता होती है, जो कि जोन को अपडेट करने के लिए आपको पहले से मिला है, तो ग्रह पर कहीं भी एक समझौता किया हुआ ग्राहक बॉटनेट शुरू करने और आपकी सेवा को नष्ट करने वाला है। पारंपरिक DNS अनिश्चित रूप से असुरक्षित है क्योंकि यह भीड़-सोर्सिंग के बिना है।
Humongous बैंडविड्थ का उपयोग और अपशिष्ट। यदि प्रत्येक DNS क्वेरी में 32 किलोबाइट या अधिक बैंडविड्थ की आवश्यकता होती है, तो यह बिल्कुल भी अच्छा नहीं होगा।
डीएनएस राउंड-रॉबिन उचित लोड संतुलन के लिए कोई विकल्प नहीं है। यह एक नोड के नीचे जाने या चीजों के बीच में अनुपलब्ध होने से उबरने का कोई रास्ता नहीं प्रदान करता है। क्या आप अपने उपयोगकर्ताओं को एक ipconfig / flushdns करने के लिए निर्देश देने जा रहे हैं यदि नोड वे नीचे जाने के लिए जुड़े थे? इस तरह के मुद्दों को पहले ही जीएसएलबी और एनीकास्ट जैसी चीजों से हल किया जा चुका है।
आदि।