👨‍💼 👨🏾‍🤝‍👨🏻 🔈 Whois: एक व्यावहारिक उपयोगकर्ता गाइड 👩🏾‍🤝‍👨🏼 👨🏼‍🏭 🈶

आलेख whois प्रोटोकॉल के काम के बारे में बताता है, मौजूदा ग्राहक समाधानों के बारे में और विभिन्न whois सर्वरों के साथ संचार की सुविधाओं के बारे में (साथ ही सही whois सर्वर चुनने के बारे में)। इसका मुख्य कार्य IP पते और डोमेन के लिए whois जानकारी प्राप्त करने के लिए स्क्रिप्ट लिखने में मदद करना है।

कौन क्या है?

किसके लिए क्या आवश्यक है और क्या पढ़ा जा सकता है, उदाहरण के लिए, यहां देखें: http://en.wikipedia.org/wiki/Whois

कुछ शब्दों में, whois (अंग्रेजी "कौन है" - "कौन है") टीसीपी प्रोटोकॉल पर आधारित एक नेटवर्क प्रोटोकॉल है। इसका मुख्य उद्देश्य आईपी पते और डोमेन नाम (मुख्य रूप से उनकी संपर्क जानकारी) के मालिकों के बारे में पाठ रूप में पंजीकरण डेटा प्राप्त करना है। एक डोमेन रिकॉर्ड में आमतौर पर "रजिस्ट्रेंट" (डोमेन मालिक) और "रजिस्ट्रार" (डोमेन पंजीकृत करने वाला संगठन), डीएनएस सर्वर नाम, पंजीकरण तिथि और समाप्ति तिथि का नाम और संपर्क जानकारी शामिल होती है। IP पतों के रिकॉर्ड्स को श्रेणियों के आधार पर वर्गीकृत किया जाता है (उदाहरण के लिए, 8.8.8.0 - 8.8.8.255) और उस संगठन के बारे में जानकारी जिसमें यह श्रेणी प्रत्यायोजित की जाती है।

अक्सर डोमेन के निशुल्क या पहले से पंजीकृत होने की जांच करने के लिए किसका उपयोग किया जाता है। सैद्धांतिक रूप से, यह केवल एक ब्राउज़र में डोमेन खोलकर किया जा सकता है, हालांकि, व्यवहार में, पंजीकृत नाम हमेशा उपयोग नहीं किया जाता है।

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

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

अन्य विवरणों को लेख के दौरान ही माना जाएगा। वास्तव में, बहुत सारी जानकारी है, इसलिए, विशेष रूप से उन लोगों के लिए जो केवल सामान्य विचार प्राप्त करना चाहते हैं, तकनीकी विवरणों में जाने के बिना, इसका "निचोड़" है: आप तुरंत लेख के अंतिम खंड पर आगे बढ़ सकते हैं, जिसे " संक्षिप्त परिणाम " कहा जाता है।

थोड़ी पृष्ठभूमि

एक सॉफ्टवेयर उत्पाद है, एक इंटरनेट पोर्टल जो आईपी पते और डोमेन के बारे में विभिन्न जानकारी प्रदान करता है, जिसमें व्हाट्सएप जानकारी भी शामिल है। अनादिकाल से, इन उद्देश्यों के लिए एक तृतीय-पक्ष उपयोगिता jwhois का उपयोग किया गया था, कोई भी इसके काम में देरी नहीं करता था। हालांकि, उत्पाद को FreeBSD के नए संस्करण में माइग्रेट करने के बाद, यह अप्रत्याशित रूप से निकला कि jwhois ने काम करना बंद कर दिया: अधिकांश डोमेन के लिए, बिल्कुल अतार्किक त्रुटि "दूरस्थ होस्ट से कनेक्ट करने में असमर्थ" दिखाई देने लगी। Google ने मदद नहीं की, और मैं सी-कोड डीबग करना शुरू करने के लिए तैयार था, जब अचानक यह पता चला कि jwhois अपने लाइसेंस (GPL v3) के कारण हमारे लिए बिल्कुल भी उपयुक्त नहीं था। सामान्य तौर पर, कार्य कुछ वैकल्पिक समाधान खोजने के लिए हुआ।

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

अभी भी मानक यूनिक्स उपयोगिता थी, तथाकथित "हूइस", हालांकि, इसका काम वांछित होना बाकी था।

सामान्य तौर पर, प्रोटोकॉल पर विशिष्टताओं को पढ़ने और समाधान स्वयं लिखने के लिए बैठने का एकमात्र विकल्प था।

परिणाम कोड के 1000 लाइनों के साथ एक पायथन मॉड्यूल था, लिखने की प्रक्रिया में मैंने उत्तराधिकार में सभी साथ चलने वाली रेक पर कदम रखा, और, आखिरकार, यह लेख इन सभी "रेक" के बारे में बात करता है (हाँ, यदि कुछ भी हो, तो कोड मालिकाना)।

आगे देखते हुए, मैं ध्यान देता हूं कि प्राप्त अनुभव की ऊँचाई से, दोनों jwhois और Ruby Whois ( http://www.ruby-whois.org ) अब भी "वांछित होने के लिए बहुत कुछ छोड़ रहे हैं।"

वास्तव में, समस्या क्या है?

सभी कार्य जो RFC 3912 ( http://tools.ietf.org/html/rfc3912 ) में वर्णित हैं और उनमें से 4 पृष्ठ हैं। कुछ शब्दों में, यह निम्नलिखित के लिए उबलता है: वांछित व्हाट्स सर्वर पर पोर्ट 43 पर एक टीसीपी कनेक्शन खोलें, एक विशिष्ट प्रारूप में एक अनुरोध भेजें (जो एक विशिष्ट हूइस सर्वर कुछ भी हो सकता है), इसे "\ r \ n" के साथ समाप्त करें और परिणाम प्राप्त करें, प्रारूप जो एक विशिष्ट whois सर्वर के लिए भी कुछ भी हो सकता है। सर्वर कनेक्शन बंद करने का अर्थ है परिणाम का अंत। वह सब है! दूसरे शब्दों में, प्रत्येक whois सर्वर अपने विवेक पर संचार प्रारूप को निर्धारित करता है। यह उल्लेख नहीं है कि यह बिल्कुल स्पष्ट नहीं है कि किसी विशिष्ट डोमेन या आईपी पते के लिए आवश्यक व्हाट्सएप सर्वर कहां से प्राप्त किया जाए।

बेशक, मैंने भोलेपन से उम्मीद की थी कि मैं इंटरनेट पर व्यावहारिक लेखों का एक समुद्र ढूंढूंगा जिसमें यह सब विस्तार से वर्णित किया जाएगा, लेकिन परिणामस्वरूप मुझे एक भी नहीं मिला। मूल रूप से, यह सब RFC से दुर्लभ जानकारी और कुछ सबसे प्रसिद्धis सर्वर के नामों को चबाने के लिए नीचे आया था। हालांकि कुछ बिखरी हुई जानकारी अभी भी पाई गई।

सामान्य तौर पर, मुझे हूइस के यूनिक्स कोड को देखना होगा, साथ ही jwhois और रूबी व्हिस - ऑपरेशन के उनके सिद्धांत पर बाद में चर्चा की जाएगी।

यूनिक्स WHOIS

तो, यूनिक्स के whois का क्या काम है?

यदि हम एक डोमेन की तलाश में हैं, तो हम इसके लिए एक शीर्ष-स्तरीय डोमेन परिभाषित करते हैं (उदाहरण के लिए, "ru") और whois सर्वर जैसे ru.whois-servers.net पर एक अनुरोध भेजें। यदि परिणाम में "Whois सर्वर: <सर्वर का नाम>" स्ट्रिंग शामिल है, तो हम इस नए सर्वर को एक अनुरोध भी भेजते हैं और परिणामों को संयोजित करते हैं।
यदि हम एक आईपी पते की तलाश कर रहे हैं, तो हम whois.arin.net (उत्तरी अमेरिका के लिए जिम्मेदार सर्वर) के लिए एक अनुरोध भेजते हैं। यदि प्राप्त परिणाम में हमारे (लैटिन अमेरिकी, यूरोपीय, प्रशांत और अफ्रीकी) ज्ञात क्षेत्रीय सर्वरों में से एक का उल्लेख है, तो हम इस नए सर्वर के लिए एक अनुरोध भी भेजते हैं और परिणामों को जोड़ते हैं।
अधिकांश व्हिस सर्वरों के लिए, अनुरोध "<डोमेन या आईपी पते> \ r \ n" प्रारूप में भेजा जाता है। दो whois सर्वर (whois.denic.de और whois.dk-hostmaster.dk) के लिए अनुरोध अपने विशेष विशेष प्रारूप में भेजा जाता है।
उपयोगकर्ता के पास सर्वर को निर्दिष्ट करने की क्षमता है कि किस तक पहुंच है।

नोट: अतिरिक्त कार्यक्षमता जिसने मुझे रुचि नहीं दी (डोमेन और आईपी पते से संबंधित नहीं) उसके बाद छोड़ दिया गया है।

जैसा कि आप देख सकते हैं, सब कुछ बेहद सरल है। और, वास्तव में, कई मामलों में यह काम करता है। कई डोमेन के लिए, <top-level domain> .whois-server.net वास्तविक whois सर्वर का एक अन्य नाम है (लेकिन कई के लिए यह नहीं है, और अनुरोध स्वाभाविक रूप से टूट जाता है)। इसके अलावा, कई आईपी पते के लिए whois.arin.net जिसके लिए वह स्वयं जिम्मेदार नहीं है, हालांकि, सही क्षेत्रीय सर्वर को जानता है और सही ढंग से उसे भेजता है (हालांकि, कुछ मामलों में, वह अभी भी नहीं जानता है या एक मनमाना प्रारूप में इसे भेजता है, वह नहीं करता है खुद को व्हिस सर्वर के नाम का उल्लेख करना सुनिश्चित करें, जो कार्यक्रम की उम्मीद है)। अधिकांश व्हाट्स सर्वर वास्तव में "<डोमेन या आईपी पते> \ r \ n" जैसे प्रारूप को समझते हैं, लेकिन अपवाद दो सर्वरों तक सीमित नहीं हैं। और, निश्चित रूप से, एक अन्य व्हिस सर्वर का लिंक आवश्यक रूप से "हू सर्वर: <सर्वर नाम>" प्रारूप में कड़ाई से नहीं होगा।

इसके अतिरिक्त, अक्सर परिणाम वैसा नहीं होता जैसा कि हम उम्मीद करते हैं। उदाहरण के लिए:

$ whois google.com GOOGLE.COM.ZZZZZZZZZZZZZZZZZZZZZZZZZZZ.LOVE.AND.TOLERANCE.THE-WONDERBOLTS.COM GOOGLE.COM.ZZZZZZZZZZZZZZZZZZZZZZZZZZ.HAVENDATA.COM GOOGLE.COM.ZZZZZZZZZZZZZ.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM GOOGLE.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM GOOGLE.COM.ZOMBIED.AND.HACKED.BY.WWW.WEB-HACK.COM ... GOOGLE.COM.AU GOOGLE.COM.AR GOOGLE.COM.ALL.THE.PEOPLE.WHO.SPAM.THE.WHOIS.ARE.SERIOUSLY.ANNOYING.SOMEPONY.COM GOOGLE.COM.AFRICANBATS.ORG GOOGLE.COM.9.THE-WONDERBOLTS.COM GOOGLE.COM.1.THE-WONDERBOLTS.COM GOOGLE.COM To single out one record, look it up with "xxx", where xxx is one of the of the records displayed above. If the records are the same, look them up with "=xxx" to receive a full display for each record.

यह पता चला है कि हूइस सर्वर "google.com" के समान कई डोमेन के बारे में जानता है और यह नहीं जानता कि किसे चुनना है।

या दूसरा उदाहरण:

 $ whois 8.8.8.8 Level 3 Communications, Inc. LVLT-ORG-8-8 (NET-8-0-0-0-1) 8.0.0.0 - 8.255.255.255 Google Incorporated LVLT-GOOGL-1-8-8-8 (NET-8-8-8-0-1) 8.8.8.0 - 8.8.8.255

जैसा कि आप देख सकते हैं, पहले आईपी पते को एक निश्चित सीमा के भीतर एक संगठन में भेजा गया था, और बाद में पहले से ही छोटे सबबैंड के भीतर किसी अन्य संगठन को फिर से सौंप दिया गया था। और जो फिर से सर्वर पता नहीं है कि किस तरह की जानकारी हमारे हितों।

दूसरे शब्दों में, यह कार्यक्रम व्हिस प्रोटोकॉल के संचालन के सबसे सामान्य सिद्धांत पर निर्भर करता है और किसी भी अपवाद के लिए बिल्कुल तैयार नहीं है। Whois-servers.net का उपयोग Whois डोमेन सर्वरों को "खोजने" के लिए किया जाता है, जो कि किसी भी तरह से सबसे कुशल तरीका नहीं है।

jwhois

अब देखते हैं कि सबसे लोकप्रिय whois उपयोगिता कैसे काम करती है। यूनिक्स हूइस के विपरीत, यह कोई भी "खोज" नहीं करता है, और पूरी तरह से एक किलोमीटर लंबी कॉन्फ़िगरेशन फ़ाइल (लगभग एक हजार लाइनें!) पर निर्भर करता है, जिसमें सभी विशिष्ट शीर्ष-स्तरीय डोमेन के लिए व्हिसिस सर्वर हार्डकोड किए जाते हैं, कई विशिष्ट द्वितीय-स्तरीय डोमेन के लिए (जो हैं) खुद के सर्वर) और यहां तक कि आईपी पते की विशिष्ट श्रेणियों के लिए। कहने की जरूरत नहीं है कि आज की तेजी से भागती दुनिया में, इस कॉन्फ़िगरेशन फ़ाइल को दैनिक अपडेट की आवश्यकता होगी और अभी भी 100% प्रासंगिक होने की संभावना नहीं है? फ़ाइल के हेडर में रिपॉजिटरी का एक लिंक होता है जिससे आप नवीनतम संस्करण डाउनलोड कर सकते हैं, और यह पता चला कि यह अप्रैल 2011 की तारीख है! इस समय के दौरान, बहुत से नए व्हिस सर्वर दिखाई दिए, और कुछ पुराने अब काम नहीं कर रहे हैं। मुझे यकीन है कि कई नई आईपी रेंजें प्रत्यायोजित की गई हैं - विशेष रूप से आईपीवी 6 के लिए।

WHOIS सर्वर के वास्तविक नामों के अलावा, एक विशेष प्रारूप में फ़ाइल अनुरोध स्वरूपों के लिए सभी ज्ञात अपवादों के साथ-साथ अन्य whois सर्वर के लिंक के प्रारूप का वर्णन करती है (Unix whois की तुलना में बहुत अधिक)।

एक और दिलचस्प कार्यक्षमता की भी खोज की। कई शीर्ष-स्तरीय डोमेन के लिए, वास्तव में कोई व्हिस सर्वर नहीं हैं, या उन तक पहुंच सीमित है, हालांकि जो अपनी वेबसाइट पर वेब के माध्यम से जानकारी उपलब्ध हैं। तो, jwhois GET या POST के साथ आवश्यक अनुरोध भेज सकते हैं, परिणाम प्राप्त कर सकते हैं और फिर HTML से आवश्यक जानकारी काट सकते हैं। पृष्ठ पते, प्रपत्र पैरामीटर के नाम और प्रत्येक विशेष मामले के लिए परिणाम का प्रारूप भी कॉन्फ़िगरेशन फ़ाइल में हार्डकोड किया गया है। स्वाभाविक रूप से, कई मामलों में यह डेटा पहले से ही पुराना है, और "स्क्रैपिंग" काम नहीं करता है। कुछ साइटों ने बस अपने रूपों में कैप्चा जोड़ा - शायद इसी तरह के कार्यक्रमों के खिलाफ।

उपरोक्त उदाहरणों पर लौटते हुए, jwhois "google.com" के लिए सही परिणाम देता है, लेकिन "8.8.8.8" के साथ यह Unix whois से बेहतर नहीं है।

सामान्य तौर पर, जैसा कि यह निकला, जोहिस इतना अच्छा कार्यक्रम नहीं है जैसा कि सोचा गया था। केवल हार्ड-कोडेड सर्वर सूची (भले ही इसे नियमित रूप से अपडेट किया गया हो) पर निर्भर करना स्पष्ट रूप से एक अच्छा विचार नहीं है।

रूबी whois

वास्तव में, रूबी Whois jwhois के समान ही काम करती है, एकमात्र अंतर यह है कि कॉन्फ़िगरेशन अपडेट लगभग हर हफ्ते सामने आते हैं। उनका चैंज अपडेट "अपडेट whois.nic.ms से नए रिस्पॉन्स फॉर्मेट", "whois.coza.net.za" whois.registry.net.za "या" जोड़ा गया .AX परिभाषा और पार्सर "जैसे अपडेट से भरा है। इसके अलावा, कॉन्फ़िगरेशन एक एकल फ़ाइल नहीं है, लेकिन फ़ाइलों का एक पूरा पेड़ है, जहां प्रत्येक WHIS सर्वर के लिए अनुरोध प्रारूप और परिणाम स्वरूप सावधानीपूर्वक निर्धारित किए गए हैं, साथ ही मौजूदा और गैर-मौजूदा डोमेन (शायद इकाई परीक्षणों के लिए) के लिए एक नमूना सर्वर प्रतिक्रिया।

यदि यह कार्यक्रम प्राचीन मिस्र के पेपिरस का विश्लेषण करता है, तो निश्चित रूप से, यह फिरौन के प्रत्येक राजवंशों के सभी ज्ञात प्रकारों के दस्तावेजों के प्रारूप का विस्तार से वर्णन करने के लिए समझ में आता है। लेकिन लगभग हर दिन बदलने वाले WHOIS सर्वर के लिए ऐसा करना शायद सबसे फायदेमंद व्यवसाय नहीं है। किसी तरह, यह सीधे परियोजना के लेखकों के लिए एक दया है - इसका समर्थन करना स्पष्ट रूप से एक आसान काम नहीं है।

उस समय, मेरे पास पहले से ही कई "मुश्किल" व्हाट्स सर्वर के नाम थे (और उन्हें कहां से प्राप्त करना है) की समझ - रूबी व्हिस कॉन्फ़िगरेशन में उनके बारे में कोई जानकारी नहीं थी।

मुझे रूबी हूइस को चलाने का अवसर (और बहुत इच्छा) नहीं था, इसलिए मुझे नहीं पता कि वह "8.8.8.8" के साथ प्रबंधित होती या नहीं।

pwhois

एक और कार्यक्रम जिसे मुझे लेख पर टिप्पणियों में सलाह दी गई थी। यह पर्ल में लिखा गया है और नेट :: व्हिस :: रॉ मॉड्यूल के लिए एक आवरण है। दोनों को यहां डाउनलोड किया जा सकता है: http://search.cpan.org/~despair/Net-Whois-Raw-2.43/ । नवीनतम अद्यतन अगस्त 2012 को दिनांकित है।

प्रोग्राम एक ही हार्डकोड विधि का उपयोग करता है: एक विशाल कॉन्फ़िगरेशन फ़ाइल (इस बार, दो हजार लाइनें) है जिसमें व्हाट्स सर्वर और बाकी सब के नाम संरक्षित हैं।

मुख्य दोष समान है: बस हार्डकोड न करें। कई व्हिस सर्वर, कॉन्फ़िगरेशन में नहीं हैं; तदनुसार, कई डोमेन के बारे में जानकारी प्राप्त करना असंभव है। खैर, कार्यक्रम भी "8.8.8.8" के साथ सामना नहीं कर सका।

आगे क्या है?

इस समय तक, मेरे पास पहले से ही कुछ विचार थे कि "सही" किसके लिए काम करना चाहिए, और मैंने शुरुआती संस्करण को विकसित करने के बारे में निर्धारित किया है। सभी आगे "ज्ञान" कई विविध whois प्रश्नों और उनके परिणामों के विश्लेषण के परिणामस्वरूप प्रयोगात्मक रूप से प्राप्त किया गया था। सौभाग्य से, यह बहुत स्वचालित हो सकता है।

मैं http://whois.domaintools.com साइट का भी उल्लेख करना चाहता हूं - सबसे अच्छी व्हिस वेब सेवा जिसे मैं खोजने में कामयाब रहा। स्वाभाविक रूप से, मैं इसके स्रोत कोड को देखने में सक्षम नहीं था, लेकिन कई मामलों में मेरे परिणामों की तुलना एक अच्छी टिप के रूप में की गई थी। मैं इस बारे में कोई धारणा नहीं बनाता कि यह कैसे काम करता है, लेकिन वास्तव में इसने उपरोक्त कार्यक्रमों की तुलना में बहुत बेहतर परिणाम दिखाए (जैसा कि मैंने उल्लेख किया है, मैं केवल कोड द्वारा रूबी व्हिस की क्षमताओं का न्याय करता हूं)।

मैं तीन मौलिक कार्यों के समाधान के लिए किसके साथ काम कम करूंगा:

सही whois सर्वर का निर्धारण;
सर्वर के लिए सही अनुरोध भेजना;
परिणाम का विश्लेषण।

तो चलिए शुरू करते हैं।

डोमेन के लिए सही whois सर्वर का निर्धारण कैसे करें?

सबसे पहले, कुछ टिप्पणी।

सभी शीर्ष स्तरीय डोमेन के लिए Whois जानकारी उपलब्ध नहीं हो सकती है। कुछ देश जो अपने डोमेन के लिए जानकारी प्रदान करते हैं, वे सिद्धांत रूप में प्रदान नहीं करते हैं (उदाहरण के लिए, डीपीआरके)। इसके अलावा, कुछ अफ्रीकी देशों के पास अपना व्हिस सर्वर नहीं है (शायद उनके पास केवल पैसा नहीं है या सभी प्रोग्रामर खा गए हैं)।

कुछ व्हिस टॉप टॉप-डोमेन के लिए, जानकारी केवल रजिस्ट्रार की वेबसाइट पर प्राप्त की जा सकती है। कुछ मामलों में, इसके लिए आपको कैप्चा दर्ज करना होगा, बाकी में इसे प्रोग्रामेटिक रूप से लागू किया जा सकता है। हालांकि, मैंने स्क्रैपिंग के विचार को पूरी तरह से छोड़ दिया। इसके सही संचालन के लिए बहुत सी जानकारी (पृष्ठ पता, प्रपत्र फ़ील्ड नाम, प्राप्त HTML पृष्ठ का प्रारूप, आदि) की हार्डकोड की आवश्यकता होती है, जिससे मैं वास्तव में बचना चाहता था। इसके अलावा, इस जानकारी को लगातार अपडेट करने की आवश्यकता होती है, क्योंकि यह व्हिस सर्वर के नामों की तुलना में अधिक बार बदल सकता है।

खैर, और सबसे महत्वपूर्ण बात यह है कि यदि साइट आगंतुकों को कोई जानकारी प्रदर्शित नहीं होती है, तो आप बस रजिस्ट्रार की साइट पर एक लिंक प्रदान कर सकते हैं और उपयोगकर्ता को स्वयं फॉर्म भरने की अनुमति दे सकते हैं। ज्यादातर मामलों में, हूइस फॉर्म या तो मुख्य पृष्ठ पर प्रस्तुत किया जाता है, या इसके साथ पृष्ठ पर आप एक क्लिक में जा सकते हैं। यह "स्क्रैपिंग" पर भरोसा करने की तुलना में बहुत अधिक विश्वसनीय तरीका है, जो किसी भी मामले में कैप्चा का सामना करने में सक्षम नहीं होगा। जहां रजिस्ट्रार की वेबसाइट पर एक लिंक प्राप्त करने के लिए नीचे वर्णित किया जाएगा।

इसके अलावा, कुछ व्हिस सर्वर उन उपयोगकर्ताओं के आईपी पते पर प्रतिबंध लगा सकते हैं जो बहुत अधिक अनुरोध भेजते हैं।

तो सही WHOIS सर्वर का नाम कहां से लाएं?

आप इसे कई स्रोतों से ले सकते हैं:

1. IAB ( http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority ) के स्वामित्व में इस तरह का एक अद्भुत WHOIS सर्वर है, जो whois.iana.org है। इसमें सभी शीर्ष-स्तरीय डोमेन पर नवीनतम जानकारी शामिल है। उदाहरण के लिए (बाद में यूनिक्स के whois का उपयोग करके सभी उदाहरण):

 $ whois -h whois.iana.org ru domain: RU organisation: Coordination Center for TLD RU address: 8, Zoologicheskaya str. address: Moscow 123242 address: Russian Federation contact: administrative name: .RU domain Administrative group organisation: Coordination Center for TLD RU address: 8, Zoologicheskaya str. address: Moscow 123242 address: Russian Federation phone: +7 499 254 88 94 fax-no: +7 499 254 89 63 e-mail: ru-adm@cctld.ru contact: technical name: Technical Center of Internet organisation: Technical Center of Internet address: 8, Zoologicheskaya str. address: Moscow 123242 address: Russian Federation phone: +7 495 737 92 95 fax-no: +7 495 737 06 84 e-mail: ru-tech@tcinet.ru nserver: A.DNS.RIPN.NET 193.232.128.6 2001:678:17:0:193:232:128:6 nserver: B.DNS.RIPN.NET 194.85.252.62 2001:678:16:0:194:85:252:62 nserver: D.DNS.RIPN.NET 194.190.124.17 2001:678:18:0:194:190:124:17 nserver: E.DNS.RIPN.NET 193.232.142.17 2001:678:15:0:193:232:142:17 nserver: F.DNS.RIPN.NET 193.232.156.17 2001:678:14:0:193:232:156:17 ds-rdata: 14072 8 2 DFFBFE59FBBD3289D0C3819F05F94610A1E03B556D64540A2CC5F8C4158A00E7 whois: whois.tcinet.ru status: ACTIVE remarks: Registration information: <span>http</span>://www.cctld.ru/en created: 1994-04-07 changed: 2012-12-21 source: IANA

निम्नलिखित पंक्तियों पर ध्यान दें:

 whois: whois.tcinet.ru remarks: Registration information: <span>http</span>://www.cctld.ru/en

यह वास्तव में whois सर्वर और रजिस्ट्रार साइट है! अधिकांश शीर्ष-स्तरीय डोमेन के लिए, IANA WHIS सर्वर का बहुत वर्तमान नाम लौटाता है। मैंने पिछले कुछ महीनों में रूबी व्हिस के परिवर्तनों का विशेष रूप से परीक्षण किया, और वे सभी whois.iana.org से लिए गए थे।

मेरे मॉड्यूल में, मैं 24 घंटे के लिए IANA से परिणाम को कैश करता हूं (लंबी अवधि के लिए, बहुत समझदारी नहीं है, और डेटा बदल सकता है)।

उपरोक्त सभी के बावजूद, किसी कारण से IANA शीर्ष-स्तरीय डोमेन whois सर्वर के बारे में जानकारी प्रदान नहीं करते हैं। शायद कुछ देशों के रजिस्ट्रार विशेष रूप से उनका विज्ञापन नहीं करते हैं। लेकिन डरावना नहीं, हमारे पास अन्य तरीके हैं।

2. यदि आप बहुत अधिक शीर्ष-स्तरीय डोमेन देखते हैं, तो उनके whois सर्वर के नाम या तो whois.nic के रूप में दिखते हैं। <शीर्ष-स्तरीय डोमेन> (अधिक सामान्य), या whois के रूप में। <शीर्ष-स्तरीय डोमेन> (कम आम)। उदाहरण के लिए:

whois.nic.fr
whois.nic.it
whois.biz

इसके अलावा, यहां तक कि अगर IANA कुछ अन्य व्हिस सर्वर (उदाहरण के लिए, whois.registro.br) को इंगित करता है, तो कई मामलों में इस योजना का उपयोग करके बनाया गया एक उपनाम (हमारे उदाहरण के लिए, whois.nic.br) अभी भी काम करेगा।

इस प्रकार, यदि IANA ने हमें कुछ भी वापस नहीं किया है, तो किसी भी शीर्ष-स्तरीय डोमेन के लिए हम आसानी से दो संभावित whois सर्वर के नाम प्राप्त कर सकते हैं:

whois.nic। <शीर्ष स्तर डोमेन>
whois। <शीर्ष स्तर डोमेन>

अभ्यास से पता चला है कि यह विधि एक दर्जन शीर्ष-स्तरीय डोमेन के लिए WHOIS सर्वरों की पहचान करती है जिनके बारे में IANA जानकारी नहीं देता है।

अक्सर, अगर हम तीसरे स्तर के डोमेन (उदाहरण के लिए, russia.edu.ru) की तलाश कर रहे हैं, तो शीर्ष स्तर के डोमेन के लिए जिम्मेदार whois सर्वर में आवश्यक जानकारी नहीं होती है। उदाहरण के लिए:

 $ whois -h whois.tcinet.ru russia.edu.ru No entries found for the selected source(s). Last updated on 2013.01.04 01:41:36 MSK

यह इस तथ्य के कारण है कि कई दूसरे-स्तरीय डोमेन (हमारे उदाहरण में, edu.ru) के लिए एक पूरी तरह से अलग संगठन जिम्मेदार है, जिसका अपना स्वयं का सर्वर है।

ऐसे मामलों में, jwhois और Ruby Whois प्रत्येक सेकंड-लेवल डोमेन के लिए whois सर्वर का नाम अपने स्वयं के सर्वर से जानते हैं। स्वाभाविक रूप से, सभी दूसरे-स्तरीय डोमेन का ट्रैक रखना बिल्कुल अवास्तविक है, खासकर क्योंकि ऐसी जानकारी का कोई केंद्रीकृत स्रोत नहीं है।

लेकिन फिर से, यदि आप बारीकी से देखते हैं, तो इनमें से अधिकांश व्हिस सर्वरों की तरह दिखते हैं। <दूसरा स्तर डोमेन> (अधिक सामान्य) या whois.nic। <दूसरा स्तर डोमेन> (कम आम)। उदाहरण के लिए:

whois.za.net
whois.eu.org
whois.nic.priv.at

उन whois सर्वरों के बारे में क्या कहा जाता है जो अलग-अलग हैं? उदाहरण के लिए, रूबी हूइस कॉन्फ़िगरेशन में, आप देख सकते हैं:

".ae.org", "whois.centralnic.com"
".edu.ru", "whois.informika.ru"

शुरू से ही, मैं अपने कोड में कई हूइस सर्वरों को हार्डकोड करने की आवश्यकता के लिए मानसिक रूप से तैयार था, हालाँकि, jwhois और Ruby Whois कॉन्फ़िगरेशन में उल्लिखित ऐसे सभी सर्वरों के माध्यम से छांटा गया था, यह पता चला कि ये सभी वास्तव में whois उपनामों के लिए भी उपलब्ध हैं। <दूसरा स्तर डोमेन> या whois.nic। <दूसरा स्तर डोमेन>! हमारे उदाहरण के लिए:

whois.ae.org
whois.edu.ru

अंत में, मुझे एक सिंगल व्हिस सर्वर को हार्डकोड नहीं करना पड़ा (स्वाभाविक रूप से, whois.iana.org को छोड़कर)।

3. उपरोक्त के अलावा, whois सर्वर का नाम भी whois की तरह लग सकता है। <रजिस्ट्रार साइट सर्वर>। उदाहरण के लिए:

 $ whois -h whois.iana.org br whois: whois.registro.br remarks: Registration information: <span>http</span>://registro.br/

कुछ मामलों में, जब आईएएनए केवल रजिस्ट्रार साइट को बिना सर्वर के लौटाता है, तो इस योजना के अनुसार निर्मित नाम सही है।

4. जैसा कि पहले ही उल्लेख किया गया है, whois-servers.net में केवल उच्च-स्तरीय डोमेन की सीमित संख्या के लिए whois सर्वर पर उपनाम शामिल हैं, लेकिन कुछ मामलों में, जब उपरोक्त सभी मदद नहीं करते हैं, तो प्रपत्र <शीर्ष-स्तरीय डोमेन> .whois-server.net का एक उपनाम दिखाई देता है। काफी कार्यात्मक (उदाहरण के लिए, "पीएस")।

इस प्रकार, प्रत्येक डोमेन के लिए जिसे हम ढूंढना चाहते हैं, हमारे पास संभावित व्हाईस सर्वरों की एक पूरी सूची होगी जो परिचालन की अधिक या कम संभावना के साथ होगी। उदाहरण के लिए, हमारे पास russia.edu.ru होगा:

whois.tcinet.ru ("ru" के लिए IANA परिणाम)
whois.edu.ru << whois सर्वर हमें चाहिए
whois.nic.edu.ru
whois.nic.ru
whois.ru
whois.cctld.ru (रजिस्ट्रार की वेबसाइट के पते के आधार पर एक "काल्पनिक" सर्वर)
ru.whois-servers.net (वास्तव में, whois.tcinet.ru के लिए काम करने वाला उपनाम)

किसको चुनना है? वास्तव में, आपको कुछ भी चुनने की आवश्यकता नहीं है, क्योंकि प्राथमिकता क्रम में पाए गए सभी व्हिस सर्वरों को सर्वेक्षण करना मुश्किल नहीं है। स्वाभाविक रूप से, यदि परिणाम पाया जाता है, तो निम्नलिखित सर्वरों को मतदान करना अब आवश्यक नहीं है। इसके अलावा, अगर इनमें से कोई भी व्हिस सर्वर वास्तव में मौजूद नहीं है (और अधिकांश "काल्पनिक" जो स्वाभाविक रूप से होंगे), तो यह जानकारी आसानी से कैश की जा सकती है।

मैं कैश के बारे में अलग से बात करना चाहूंगा।

आईएएनए से व्हिस सर्वर और लिंक के माध्यम से पाया जाने वाला व्हिस सर्वर (इसके बारे में अधिक) डिफ़ॉल्ट रूप से "सक्रिय" माना जाता है। जब सक्रिय सर्वर प्रतिक्रिया नहीं देता है (मतलब, सर्वर सिद्धांत रूप में सुलभ नहीं है, और न केवल एक विशिष्ट डोमेन के लिए आवश्यक जानकारी नहीं मिली है और एक त्रुटि लौटा दी गई है), इसकी स्थिति "अस्थायी रूप से अनुपलब्ध" में बदल जाती है। जब एक अस्थायी रूप से अनुपलब्ध सर्वर प्रतिक्रिया नहीं करता है, तो इसे पहले एक मिनट के लिए, फिर दो के लिए, चार के लिए, आठ के लिए, आदि के लिए अवरुद्ध किया जाता है, जब तक कि यह अवधि दो सप्ताह से अधिक लंबी नहीं हो जाती। इस स्थिति में, सर्वर स्थिति "निष्क्रिय" में बदल जाती है, और यह ठीक दो सप्ताह के लिए अवरुद्ध है। यदि निष्क्रिय सर्वर दो सप्ताह के बाद भी प्रतिक्रिया नहीं देता है, तो वह निष्क्रिय रहता है और दो सप्ताह के लिए फिर से अवरुद्ध हो जाता है। यदि अस्थायी रूप से अनुपलब्ध या निष्क्रिय सर्वर अचानक प्रतिक्रिया देता है, तो इसकी स्थिति सक्रिय में बदल जाती है। सभी "whois" whois सर्वर और फॉर्म के सर्वर <शीर्ष-स्तरीय डोमेन> .wis-server.net को डिफ़ॉल्ट रूप से निष्क्रिय माना जाता है। यही है, अगर वे जवाब नहीं देते हैं, तो उन्हें तुरंत दो सप्ताह के लिए अवरुद्ध कर दिया जाता है।

इस तरह की स्कीम आपको सभी गैर-प्रासंगिक व्हिस सर्वरों को फ़िल्टर करने की अनुमति देती है और एक ही समय में सर्वरों को अवरुद्ध करने की लंबे समय तक अनुमति नहीं देती है, जो एक कारण या किसी अन्य के लिए अस्थायी रूप से अनुपलब्ध हो गया है।

यह ध्यान देने योग्य है कि अगली बार जब हम edu.ru ज़ोन में एक डोमेन की तलाश करते हैं, तो दो whois सर्वर सक्रिय माने जाएंगे:

whois.tcinet.ru
whois.edu.ru

हालाँकि, यह तथ्य कि whois.edu.ru सक्रिय है, यह इंगित करता है कि पहले Whois सर्वर में सबसे अधिक संभावना है कि हमारे पास आवश्यक जानकारी नहीं है (अन्यथा कतार whois.edu.ru तक नहीं पहुंचेगी और यह सक्रिय नहीं होगी)। इसलिए, इसे पहले प्राथमिकता में रखना और इस क्रम में WHOIS सर्वर को प्रदूषित करना उचित होगा:

whois.edu.ru << whois सर्वर हमें चाहिए
whois.tcinet.ru
whois.nic.edu.ru
whois.nic.ru
whois.ru
whois.cctld.ru
ru.whois-servers.net

यदि हम, उदाहरण के लिए, daily.lviv.ua (एक तृतीय-स्तरीय डोमेन भी देखें), तो इसके लिए परिणाम सबसे अधिक संभावना वाले पहले सर्वर को लौटाएगा जो IANA (whois.ua) हमारे पास लौटा। इसलिए, whois.lviv.ua सर्वर कभी भी सक्रिय नहीं होगा (शायद यह मौजूद नहीं है - मैंने इसकी जांच नहीं की है), और अगली बार हम फिर से whois.ua पर lviv.ua ज़ोन में डोमेन खोजेंगे।

दूसरे शब्दों में, कुछ समय के बाद, कोई भी या गलत व्हिस सर्वर के अनुरोधों को कम से कम किया जाएगा।

अतिरिक्त whois सर्वर के लिए लिंक

अक्सर whois सर्वर द्वारा प्रदान किया गया परिणाम अधूरा होता है, लेकिन इसमें एक अन्य WHOIS सर्वर का लिंक होता है जिसमें अधिक संपूर्ण जानकारी होती है। उदाहरण के लिए:

 $ whois -h whois.verisign-grs.com 'domain google.com' Domain Name: GOOGLE.COM Registrar: MARKMONITOR INC. Whois Server: whois.markmonitor.com Referral URL: <span>http</span>://www.markmonitor.com Name Server: NS1.GOOGLE.COM Name Server: NS2.GOOGLE.COM Name Server: NS3.GOOGLE.COM Name Server: NS4.GOOGLE.COM Status: clientDeleteProhibited Status: clientTransferProhibited Status: clientUpdateProhibited Status: serverDeleteProhibited Status: serverTransferProhibited Status: serverUpdateProhibited Updated Date: 20-jul-2011 Creation Date: 15-sep-1997 Expiration Date: 14-sep-2020

जैसा कि आप देख सकते हैं, इतनी जानकारी नहीं है, लेकिन एक अन्य व्हिस सर्वर का लिंक है:

 Whois Server: whois.markmonitor.com

यदि हम अब इसे चालू करते हैं, तो हमें यह मिलता है:

 $ whois -h whois.markmonitor.com google.com Registrant: Dns Admin Google Inc. Please contact contact-admin@google.com 1600 Amphitheatre Parkway Mountain View CA 94043 US dns-admin@google.com +1.6502530000 Fax: +1.6506188571 Domain Name: google.com Registrar Name: Markmonitor.com Registrar Whois: whois.markmonitor.com Registrar Homepage: <span>http</span>://www.markmonitor.com Administrative Contact: DNS Admin Google Inc. 1600 Amphitheatre Parkway Mountain View CA 94043 US dns-admin@google.com +1.6506234000 Fax: +1.6506188571 Technical Contact, Zone Contact: DNS Admin Google Inc. 2400 E. Bayshore Pkwy Mountain View CA 94043 US dns-admin@google.com +1.6503300100 Fax: +1.6506181499 Created on..............: 1997-09-15. Expires on..............: 2020-09-13. Record last updated on..: 2012-01-29. Domain servers in listed order: ns2.google.com ns4.google.com ns3.google.com ns1.google.com

इस प्रकार, सबसे पूर्ण जानकारी प्राप्त करने के लिए, हमें परिणामस्वरूप अन्य व्हिस सर्वरों के लिंक की तलाश करनी चाहिए। अक्सर वे "हूइस सर्वर: <नाम>" की तरह दिखते हैं, लेकिन अक्सर लिंक पूरी तरह से अप्रत्याशित जगह में भी दिखाई देता है (उदाहरण के लिए, पाठ के बीच में)।

मेरा मॉड्यूल काफी आक्रामक रूप से लिंक की तलाश कर रहा है, जो किसी भी सर्वर के लिए किसी भी स्ट्रिंग को लेता है जो एक होस्टनाम की तरह दिखता है और इसमें "हूइस" शब्द होता है (जैसा कि हम पहले ही पता लगा चुके हैं, "अतिरिक्त" जो कि एक समस्या नहीं है)। यदि हमें "whois server: <name>" प्रारूप में एक लिंक मिला है, तो सर्वर नाम में "whois" शब्द शामिल नहीं है (व्यवहार में, यह होस्टनाम भी नहीं हो सकता है, लेकिन केवल एक आईपी पता है)। जो भी सर्वर पाया जाता है उन्हें डिफ़ॉल्ट रूप से सक्रिय माना जाता है।

सच है, वहाँ एक नुकसान है। परिणाम में आपके स्वयं के व्हिस सर्वर का नाम शामिल हो सकता है, और यदि ऐसा होता है कि हमने इसे कुछ अन्य उपनामों के लिए बदल दिया, तो यह दूसरे व्हिस सर्वर के लिंक की तरह दिखेगा। उदाहरण के लिए:

 $ whois -h whois.jp newsmap.jp [ JPRS database provides information on network administration. Its use is ] [ restricted to network administration purposes. For further information, ] [ use 'whois -h whois.jprs.jp help'. To suppress Japanese output, add'/e' ] [ at the end of command, eg 'whois -h whois.jprs.jp xxx/e'. ] ...

यह whois.jprs.jp को संदर्भित करता है, जिसका उपनाम वास्तव में whois.jp है। यही है, यदि हम अब whois.jprs.jp पर अनुरोध भेजते हैं, तो हमें वही परिणाम मिलेगा।इसके अलावा, कुछ व्हिस सर्वर प्रॉक्सी के रूप में कार्य कर सकते हैं और कुछ अन्य व्हिस सर्वर से परिणाम लौटा सकते हैं - स्वाभाविक रूप से, परिणाम के रूप में इसका नाम।

दूसरे शब्दों में, हमें किसी तरह की ऐसी स्थितियों की पहचान करने की आवश्यकता है: सबसे पहले, ताकि उपयोगकर्ता को दो समान परिणाम न दें, और दूसरी बात, ताकि अनावश्यक प्रश्नों पर समय बर्बाद न करें।

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

इसलिए, तुलना करने से पहले, मैं अंकों के सभी अनुक्रमों को "X" से बदल देता हूं, सभी खाली लाइनों और लाइनों को हटा देता हूं जो "#" या "%" (टिप्पणियों) के साथ शुरू होती हैं, और, बस, एक के साथ कई रिक्त स्थान बदलें और "ट्रिम" करें सभी लाइनें। उसके बाद, मैं दो सेट स्ट्रिंग्स (पायथन में सेट प्रकार का उपयोग करके) की तुलना करता हूं, और यदि दूसरा पहले का सबसेट है, तो यह एक डुप्लिकेट है।

सौभाग्य से, IDN डोमेन के साथ कोई समस्या नहीं है (जैसे कि "सरकार.आरएफ")। हम "xn - 80aealotwbjpid2k.xn - p1ai" में "Government.rf" का अनुवाद करते हैं और शीर्ष-स्तरीय डोमेन "xn - p1ai" के लिए whois.iana.org को देखते हैं:

 whois: whois.tcinet.ru

IP पते के लिए सही whois सर्वर का निर्धारण कैसे करें?

आईपी पते के साथ, स्थिति कुछ अलग है। पाँच मुख्य क्षेत्रीय whois सर्वर हैं:

whois.arin.net (ARIN, उत्तरी अमेरिका)
whois.apnic.net (APNIC, एशिया और प्रशांत)
whois.ripe.net (RIPE, यूरोप और मध्य पूर्व)
whois.afrinic.net (अफरीनिक, अफ्रीका)
whois.lacnic.net (LACNIC, लैटिन अमेरिका)

सैद्धांतिक रूप से, किसी भी IP पते (IPv4 और IPv6 दोनों) के बारे में जानकारी उनमें से किसी एक पर होनी चाहिए। यदि आईपी पतों की कोई भी सीमा आरक्षित है या अभी तक किसी भी क्षेत्रीय सर्वर को आवंटित नहीं किया गया है (यह विशेष रूप से IPv6 के लिए सच है), तो IANA को इसके बारे में पता होना चाहिए। उदाहरण के लिए:

 $ whois -h whois.iana.org 12af:: inet6num: 1000:0:0:0:0:0:0:0/4 descr: Reserved by IETF remarks: <span>http</span>://tools.ietf.org/html/rfc4291 source: IANA

यदि आप आईपी पते के बारे में किसी भी क्षेत्रीय सर्वर से पूछते हैं जिसके लिए वह जिम्मेदार नहीं है, तो एक निश्चित संभावना के साथ वह वांछित सर्वर को इंगित करने में सक्षम होगा, लेकिन हमेशा नहीं। इसलिए, मैं सभी पांच क्षेत्रीय whois सर्वरों के साथ-साथ whois.iana.org पर भी मतदान करवाता हूं, जब तक कि उनमें से कोई एक परिणाम या वांछित व्हाट्स सर्वर पर वापस नहीं आ जाता।

पहला अनुरोध मैं हमेशा एआरआईएन को भेजता हूं, क्योंकि यह आईपी पते की सबसे बड़ी संख्या के लिए जिम्मेदार है (और हमारे उत्पाद के उपयोगकर्ता सबसे अधिक बार उत्तरी अमेरिका से आईपी पते में दिलचस्पी लेंगे)। इसके अलावा, अन्य आईपी पतों के लिए, ARIN लगभग हमेशा वांछित क्षेत्रीय whois सर्वर को इंगित कर सकता है। ज्यादातर मामलों में, आईएएनए सही सर्वर को भी इंगित कर सकता है, लेकिन इस मामले में, आपको हर बार कम से कम दो अनुरोध करने होंगे।

यह ध्यान देने योग्य है कि AfriNIC एक अपेक्षाकृत नया व्हिस सर्वर है। इससे पहले, सभी अफ्रीकी आईपी पते ARIN, RIPE और APNIC के बीच वितरित किए गए थे। इसलिए, अन्य क्षेत्रीय whois सर्वर अक्सर सोचते हैं कि ये आईपी पते अभी भी उन्हें सौंपे गए हैं। उदाहरण के लिए:

 $ whois -h whois.iana.org 213.154.64.0 refer: whois.ripe.net inetnum: 213.0.0.0 - 213.255.255.255 organisation: RIPE NCC status: ALLOCATED whois: whois.ripe.net changed: 1993-10 source: IANA

ARIN यह भी कहेगा कि RIPE 213.154.64.0 के लिए जिम्मेदार है। अगर हम RIPE की ओर मुड़ते हैं, तो वह जवाब देगा कि 213.154.64.0 - 213.154.95.255 रेंज के लिए AfriNIC पहले से ही जिम्मेदार है।

दो बातें भी याद रखनी हैं। whois.lacnic.net एक प्रॉक्सी के रूप में काम करता है, और अगर इसमें किसी भी आईपी पते के बारे में जानकारी नहीं है, तो यह अन्य चार सर्वरों को एक अनुरोध भेजता है और अंततः, वांछित परिणाम देता है। ऐसा लग सकता है कि इस मामले में सभी अनुरोधों को केवल LACNIC को भेजा जाना चाहिए। वास्तव में, यह पूरी तरह से इसके लायक नहीं है: पांच क्षेत्रीय whois सर्वर (RIPE और AfriNIC) में से दो उन उपयोगकर्ताओं के आईपी पते पर आक्रामक रूप से प्रतिबंध लगाते हैं जो बहुत अधिक अनुरोध भेजते हैं। सटीक संख्याओं के बारे में निश्चित नहीं है, लेकिन प्रति दिन 10,000 अनुरोध, मुझे लगता है कि AfriNIC द्वारा अवरुद्ध होने के लिए पर्याप्त होगा। जब LACNIC अन्य क्षेत्रीय सर्वरों को अनुरोध भेजता है, तो यह स्वाभाविक रूप से उस उपयोगकर्ता के आईपी को इंगित करता है जिसकी ओर से अनुरोध किया गया है। दूसरे शब्दों में, भले ही कुछ IP पता AfriNIC से संबंधित न हो, एक उच्च संभावना हैकि LACNIC इसके लिए अनुरोध भेजेगा, जिससे काउंटर बढ़ेगा। इसलिए, LACNIC पर, मैं पिछले अनुरोध भेजता हूं।

अन्य व्हिस सर्वर के लिंक उसी तरह से खोजे जाते हैं जैसे डोमेन के लिए। सच है, कई बारीकियां हैं। ARIN हमेशा "रेफरल सर्वर: <नाम>" के रूप में अतिरिक्त whois सर्वर के लिंक दिखाता है। यदि वह आईपी पते के लिए जवाब नहीं देता है, लेकिन जानता है कि किस क्षेत्रीय सर्वर को इसके लिए देखना है, तो वह सबसे अधिक संभावना है कि Whois सर्वर का पूरा नाम नहीं दिखाया जाएगा, लेकिन केवल खुद को एक संक्षिप्त नाम जैसे LACNIC या RIPE तक सीमित कर देगा।

रिक्वेस्ट कैसे भेजें?

तो, आधे में दु: ख, हम अंत में सही whois सर्वर मिला। अब इसमें अनुरोध कैसे भेजें?

अधिकांश मामलों में, आपको केवल पोर्ट 43 पर एक कनेक्शन खोलने की आवश्यकता है, फॉर्म की एक पंक्ति "<डोमेन या आईपी पते> \ r \ n" भेजें और उस डेटा को पढ़ें जिससे सर्वर वापस आ जाएगा। हालाँकि, हमेशा की तरह, अपवाद हैं (यहाँ, दुर्भाग्य से, आप हार्डकोड के बिना नहीं कर सकते हैं)।

इस तथ्य के बावजूद कि RFC 3912 स्पष्ट रूप से "\ r \ n" भेज रहा है, कम से कम एक whois सर्वर है जिसे "\ n" की आवश्यकता है और "\ r \ n" के साथ काम करने से मना करता है! यह माल्टा का whois सर्वर whois.nic.org.mt है।

इसके अलावा, निम्नलिखित WHOIS सर्वर को विशेष सिंटैक्स की आवश्यकता होती है:

whois.arin.org: "n + <IP पता> \ r \ n"
whois.denic.de: "-C UTF-8 -T dn, इक्का <डोमेन> \ r \ n"
whois.dk-hostmaster.dk: "--show-handle <domain> \ r \ n"
whois.nic.name: "डोमेन = <डोमेन> \ r \ n"
WHOIS के स्वामित्व वाले सर्वर: "डोमेन <डोमेन> \ r \ n"

मुख्य VeriSign सर्वर whois.verisign-grs.com है। बाकी का निर्धारण कैसे करें? यदि क्वेरी "<domain> \ r \ n" के जवाब में परिणाम में `एक रिकॉर्ड आउट करने के लिए 'लाइनें हैं, तो इसे" xxx "के साथ देखें और` उन्हें पूर्ण प्रदर्शन प्राप्त करने के लिए "= xxx" के साथ देखें, फिर हमसे पहले VeriSign सर्वर है। इस स्थिति में, अनुरोध को "डोमेन <डोमेन> \ r \ n" के रूप में दोहराया जाना चाहिए, और जो स्वयं सर्वर VeriSign सर्वर में सूचीबद्ध है।

आप सामान्य प्रकार "<IP पते> \ r \ n" में whois.arin.org को भी अनुरोध भेज सकते हैं, लेकिन तब पूर्ण परिणाम के बजाय इसे प्राप्त करने का जोखिम होता है:

 Level 3 Communications, Inc. LVLT-ORG-8-8 (NET-8-0-0-0-1) 8.0.0.0 - 8.255.255.255 Google Incorporated LVLT-GOOGL-1-8-8-8 (NET-8-8-8-0-1) 8.8.8.0 - 8.8.8.255

Whois.nic.name के साथ, स्थिति आम तौर पर दिलचस्प है। उदाहरण के लिए:

 $ whois -h whois.nic.name 'domain = dns.name' Domain Name ID: 1102376DOMAIN-NAME Domain Name: DNS.NAME Sponsoring Registrar ID: 44REGISTRAR-NAME Sponsoring Registrar: GoDaddy.com, LLC Domain Status: clientDeleteProhibited Domain Status: clientRenewProhibited Domain Status: clientTransferProhibited Domain Status: clientUpdateProhibited Registrant ID: 1337930CONTACT-NAME Admin ID: 1337932CONTACT-NAME Tech ID: 1337931CONTACT-NAME Billing ID: 1337933CONTACT-NAME Name Server ID: 1017197HOST-NAME Name Server: NS3.AFRAID.ORG Name Server ID: 1017198HOST-NAME Name Server: NS4.AFRAID.ORG Name Server ID: 2249HOST-NAME Name Server: NS1.AFRAID.ORG Name Server ID: 2250HOST-NAME Name Server: NS2.AFRAID.ORG Created On: 2004-09-04T19:14:53Z Expires On: 2013-09-04T19:14:53Z Updated On: 2012-09-03T09:10:57Z

इतनी जानकारी नहीं है (हालांकि कुछ नहीं से बेहतर)। हालांकि, लाइन पर ध्यान दें:

 Sponsoring Registrar ID: 44REGISTRAR-NAME

आप निम्नलिखित अनुरोध भेज सकते हैं:

 $ whois -h whois.nic.name 'registrar = 44REGISTRAR-NAME' Registrar ID: 44REGISTRAR-NAME Registrar Name: GoDaddy.com, LLC Registrar URL: <span>www</span>.godaddy.com Registrar Status: ok Registrar Address: 14455 North Hayden Rd, Suite 226 Registrar City: Scottsdale Registrar State/Province: Arizona Registrar Country: UNITED STATES Registrar Postal Code: 85260 Registrar Phone Number: +1.4805058800 Registrar Fax Number: +1.4805058865 Registrar E-mail: registrar_routine@godaddy.com Admin ID: 1269602CONTACT-NAME Admin Organization: Go Daddy Software, Inc. Admin Name: Tim Ruiz Admin Address: 14455 N Hayden Suite 226, , Admin City: Scottsdale Admin State/Province: AZ Admin Country: UNITED STATES Admin Postal Code: 85260 Admin Phone Number: +1.4805058800 Admin Fax Number: +1.4805058865 Admin Email: registrar_routine@godaddy.com ...

उन्होंने स्वयं रजिस्ट्रार सर्वर का दिखावा नहीं किया, लेकिन साइट का पता दिखाया:

 Registrar URL: <span>www</span>.godaddy.com

जैसा कि हम पहले से ही जानते हैं, ज्यादातर मामलों में, व्हिस सर्वर कहीं न कहीं पास होता है। हम कोशिश करते हैं:

 $ whois -h whois.godaddy.com dns.name Registered through: GoDaddy.com, LLC (<span>http</span>://www.godaddy.com) Domain Name: DNS.NAME Created on: 04-Sep-04 Expires on: 04-Sep-13 Last Updated on: 03-Sep-12 Registrant: Mike Taylor 9 Ludford Grove Sale, M33 4DP United Kingdom Administrative Contact: Taylor, Mike admin@crazyemail.net 9 Ludford Grove Sale, M33 4DP United Kingdom +7.745095404 Technical Contact: Taylor, Mike admin@crazyemail.net 9 Ludford Grove Sale, M33 4DP United Kingdom +7.745095404 ...

यह, ज़ाहिर है, "नाम" क्षेत्र में सभी डोमेन के लिए काम नहीं करता है, लेकिन कई के लिए।

मैं क्षेत्रीय whois सर्वर के अतिरिक्त वाक्यविन्यास (उनकी वेबसाइटों पर विस्तार से वर्णित) के बारे में पढ़ने की सलाह देता हूं। मैं अपने मॉड्यूल में इसका उपयोग नहीं करता, लेकिन यह किसी के काम आ सकता है। उदाहरण के लिए, -B विकल्प, whois.ripe.net को सूचित, परिवर्तित और ई-मेल फ़ील्ड प्रदर्शित करने की अनुमति देता है, जो डिफ़ॉल्ट रूप से नहीं दिखाए जाते हैं:

 $ telnet whois.ripe.net 43 Trying 193.0.6.135... Connected to whois.ripe.net. Escape character is '^]'. % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf -B 213.180.204.0 <<<<<    "-B" % Information related to '213.180.204.0 - 213.180.204.255' inetnum: 213.180.204.0 - 213.180.204.255 netname: YANDEX-213-180-204 descr: Yandex enterprise network country: RU admin-c: YNDX1-RIPE tech-c: YNDX1-RIPE remarks: INFRA-AW status: ASSIGNED PA mnt-by: YANDEX-MNT changed: artem@yandex-team.ru 20091116 <<<<<   source: RIPE ...

इस उदाहरण में, मैं टेलनेट का उपयोग करता हूं, क्योंकि मैं यूनिक्स हूइस या किसी अन्य उपयोगिता के माध्यम से विशेष मापदंडों को स्थानांतरित नहीं कर सकता।

एक और बारीकियों जो WHIS सर्वर से परिणाम पढ़ने के साथ जुड़ा हुआ है। प्रारंभ में, मेरे पास लगभग निम्नलिखित कोड थे:

 obj = socket.socket(socket.AF_INET, socket.SOCK_STREAM) try: ... res = '' while True: buf = obj.recv(4096) if buf: res += buf else: break return res except Exception: return ''

दूसरे शब्दों में, हम डेटा को पढ़ते हैं। यदि कोई त्रुटि होती है, तो एक खाली परिणाम लौटाएं।

यह पता चला कि यह हमेशा काम नहीं करता है (हालांकि, शायद, 99% मामलों में)। व्हिसिस सर्वर हैं, जो डेटा भेजने के बाद, कनेक्शन को इस तरह से बंद कर देते हैं कि क्लाइंट पर हमेशा एक त्रुटि होती है (हालांकि सभी डेटा को सफलतापूर्वक पहले पढ़ा गया है)।

इसलिए, कोड को बदल दिया गया है:

 obj = socket.socket(socket.AF_INET, socket.SOCK_STREAM) ... res = '' while True: try: buf = obj.recv(4096) except socket.error: break if buf: res += buf else: break return res

अंत में, यह पता चला कि व्हिस प्रोटोकॉल के अलावा, एक अन्य है जिसे रवोहिस कहा जाता है। हम नीचे इसकी चर्चा करेंगे।

रेफरल whois

Rwhois ("रेफरल व्हिस") यहाँ क्या पढ़ा जा सकता है: http://en.wikipedia.org/wiki/Whois#Referral_Whois । कुछ शब्दों में, यह एक प्रोटोकॉल है जो मानक whois के सभी दोषों को ठीक करना चाहिए और अंत में, इसे पूरी तरह से बदल देगा। डिफ़ॉल्ट रूप से, प्रोटोकॉल पोर्ट 4321 का उपयोग करता है। इस तथ्य के बावजूद कि rwhois को 1994 में वापस विकसित किया गया था, फिर भी इसे व्यापक वितरण नहीं मिला है।

पहली बार, मैंने परिणाम में rwhois सर्वर के लिंक देखे, जो ARIN मेरे पास लौटे (हालांकि लिंक के विशाल बहुमत ने अभी भी साधारण whois सर्वर का नेतृत्व किया)। आमतौर पर, उनके बहुत नाम में "रूविस" शब्द होता था। इसके अलावा, ज्यादातर मामलों में, ARIN ने स्पष्ट रूप से संकेत दिया कि किस प्रोटोकॉल का उपयोग करना है: "whois: //" या "rwhois: //"। पहला rwhois सर्वर, जिसमें मैंने एक अनुरोध भेजने की कोशिश की, दिखाया कि एक सरल "<IP पता> \ r \ n" पर्याप्त नहीं है। मुझे स्पेसिफिकेशन खोलना था।

रेफरल Whois को RFC 2167 ( http://tools.ietf.org/html/rfc2167) में वर्णित किया गया है)। यह एक बहुत बड़ा अपठनीय 170KB दस्तावेज़ है। इसे तिरछे तरीके से देखते हुए, मैंने तुरंत जोएल स्पॉल्स्की के शब्दों को याद किया: "अगर किसी ने आपको कुछ नई तकनीक के लिए एक विनिर्देश दिया है, और आप इसे समझ नहीं सकते हैं, तो बहुत परेशान न हों। कोई भी उसे नहीं समझेगा, इसलिए यह मुश्किल है। ”

दस्तावेज़ में कोई उदाहरण नहीं थे, Google भी मेरी मदद करने में असमर्थ था। इसलिए, टेलनेट के साथ छेड़छाड़ करने और अंत में एक मृत अंत तक पहुंचने के बाद, मैंने फैसला किया कि जब पहिया को सुदृढ़ करने की आवश्यकता हो तो यह मामला नहीं है। पर http://projects.arin.net/rwhois/मेरे पास उपयुक्त GPL v2 लाइसेंस के साथ C में लिखा गया ग्राहक था। 100KB से अधिक कोड और rwhois संस्करण 1.0 और 1.5 के लिए समर्थन - आपने इसे स्वयं नहीं लिखा है। उन rwhois सर्वर के साथ, जिन्हें मैं एक ठहराव के लिए आया था, उन्होंने शानदार ढंग से निपटाया। ऊपर उल्लिखित jwhois में भी बिल्ट-इन rwhois सपोर्ट था, लेकिन यह एकदम सही नहीं था (कम से कम, सर्वर के विभिन्न संस्करणों के लिए समर्थन नहीं था)।

सामान्य तौर पर, अगर मेरे मॉड्यूल में एक rwhois सर्वर पाया जाता है, तो यह बस सब-स्पेस के माध्यम से एक थर्ड-पार्टी rwhois क्लाइंट कहलाता है, जिसने सर्वर के साथ सभी संचार को संभाल लिया और तैयार परिणाम को वापस कर दिया।

आनंद लंबे समय तक नहीं रहा: यह पता चला कि क्लाइंट अधिकांश वास्तविक rwhois सर्वर के साथ काम नहीं करता है। इसके लिए कोई स्पष्ट कारण नहीं था, लेकिन क्लाइंट ने "rwhois सर्वर को क्वेरी करते हुए त्रुटि" वापस कर दी। गूगल, निश्चित रूप से, मदद नहीं कर सका। सबसे कष्टप्रद बात यह है कि jwhois ने इन सर्वरों के साथ बहुत अच्छा काम किया।

कुछ समय के लिए लड़खड़ाते हुए, मैंने आखिरकार एक अद्भुत चीज की खोज की: ये सभी "rwhois" सर्वर वास्तव में सामान्य whois प्रोटोकॉल का उपयोग करके काम करते हैं! दूसरे शब्दों में, मेरा परिष्कृत क्लाइंट सर्वर से जुड़ता है और सोचता है कि "मुझे आश्चर्य है कि क्या यह rwhois संस्करण 1.0 या rwhois संस्करण 1.5 की तरह काम करता है?" और सर्वर वास्तव में गूंगा "<IP पता> \ r \ n" के अलावा कुछ नहीं समझता है! बेशक, ग्राहक ऐसी अशुद्धता की उम्मीद नहीं करता है और एक त्रुटि देता है।

मुझे संदेह है कि इन सभी सर्वरों में बस rwhois प्रोटोकॉल का सही कार्यान्वयन "मास्टर नहीं किया गया" और अंत में, सामान्य रूप से वापस लौटे, जबकि औपचारिक रूप से खुद को rwhois सर्वर के रूप में पहचानते रहे। तो जोएल स्पोल्स्की बिल्कुल सही था।

वास्तव में, इन सर्वरों के लिए अभी भी कुछ बचा हुआ है: लौटे डेटा के लिए एक सख्ती से संरचित प्रारूप। सब कुछ वर्गों में विभाजित है, कोई अतिरिक्त स्थान नहीं, नाम / मान को एक कोलोन द्वारा अलग किया जाता है। Rwhois क्लाइंट ने तब इसे एक खूबसूरत टेबुल टेबल में बदल दिया। मेरे मॉड्यूल में इसे लागू करने के लिए कोड की कुछ ही पंक्तियां लगीं।

अब, यदि कुछ rwhois सर्वर के लिए rwhois क्लाइंट कोई त्रुटि देता है, तो मॉड्यूल इसे सामान्यis सर्वर के रूप में फिर से एक्सेस करने का प्रयास करता है। यदि वह सफल हो जाता है, तो सर्वर को नियमित रूप से whois सर्वर की सूची में दर्ज किया जाता है।

परिणाम कैसे संसाधित करें?

सबसे कठिन हिस्सा एक त्रुटि संदेश से मान्य परिणाम को अलग करना है। कार्य बिल्कुल गैर-तुच्छ है: एक विशिष्ट whois सर्वर के लिए त्रुटि संदेश प्रारूप कुछ भी हो सकता है। एल्गोरिथ्म का आविष्कार किया गया था और प्रयोगात्मक रूप से सुधार हुआ था। मेरे पास पहले से ही विभिन्न व्हिस सर्वरों से वैध परिणाम का एक बड़ा सेट था, त्रुटि संदेश प्राप्त करना भी आसान था: यह प्रत्येक ज्ञात सर्वर के लिए एक बिना किसी या गलत डोमेन या आईपी पते के लिए अनुरोध भेजने के लिए पर्याप्त था (यह आसानी से स्वचालित था)।

अंत में, मैं निम्नलिखित पर आया:

यदि परिणाम पांच क्षेत्रीय whois सर्वरों में से एक से IP पते के लिए प्राप्त किया गया था, तो निम्न पंक्तियाँ सटीक रूप से एक त्रुटि दर्शाती हैं:

"0.0.0.0 - 255.255.255.255" या "0 :: / 0" (सभी के लिए)
"नेटवर्क रेंज एपनिक को आवंटित नहीं है" (APNIC के लिए)
"पके द्वारा प्रबंधित पता ब्लॉक" या "RIPE के लिए" का उपयोग करके कोई नेटवर्क संचालित नहीं करता है
"Afrinic whois सर्वर" या "परिपक्व डेटाबेस क्वेरी सेवा" (LACNIC के लिए)
"Whois.arin.net" या "arin को आवंटित", बशर्ते कि एक अलग क्षेत्रीय सर्वर से अनुरोध करने के लिए संदर्भित किया जाता है

यदि परीक्षण सफल रहा, तो मानक परीक्षण पर जाएं (सभी परिणामों के लिए):

हम वह सब कुछ हटा देते हैं जो "http (s): //" या समय के रूप में दिखता है (उदाहरण के लिए, "12:45:51")। दूसरे शब्दों में, हम ऐसे किसी भी कॉलोन को हटा देते हैं, जो स्पष्ट रूप से हमारे हित में नहीं है।
"#" या "%" (टिप्पणियों) से शुरू होने वाली सभी पंक्तियों को हटा दें।
यदि हम जिस डोमेन या आईपी पते की तलाश कर रहे हैं, उसका परिणाम नहीं है, तो परिणाम अमान्य है। अपवाद: whois.eu सर्वर से परिणाम।
हम "उपयोगी" लाइनों की संख्या गिनते हैं। यदि रेखा में एक बृहदान्त्र होता है या पंक्ति के बीच में एक टैब होता है या पंक्ति की शुरुआत में एक इंडेंट होता है और 5 शब्दों से कम होता है, तो इसे "उपयोगी" माना जाता है।
यदि हमारे पास 3 से अधिक "उपयोगी" लाइनें हैं, तो परिणाम वैध माना जाता है।
यदि आपकी ज़रूरत से कम "उपयोगी" लाइनें हैं, लेकिन सभी लाइनों में से दस से अधिक हैं (उन लोगों की गिनती नहीं जिन्हें हमने शुरुआत में हटा दिया था), और परिणाम में स्वतंत्र शब्द "नाम" और "पता" शामिल हैं, तो परिणाम भी मान्य माना जाता है।
अन्यथा, परिणाम अमान्य है।

सामान्य तौर पर, एक नखरे के साथ नृत्य। मुझे यकीन है कि ऐसी परिस्थितियां हैं जो इस चेक को कवर नहीं करती हैं, लेकिन अधिकांश मामलों में इसे काम करना चाहिए।

यदि ARIN ने हमें कई परिणाम लौटाए (उदाहरण के लिए, 8.8.8.8 के लिए), तो आपको उनमें से एक का चयन करने की आवश्यकता है:

 $ whois -h whois.arin.net 'n + 8.8.8.8' # start NetRange: 8.0.0.0 - 8.255.255.255 CIDR: 8.0.0.0/8 OriginAS: NetName: LVLT-ORG-8-8 NetHandle: NET-8-0-0-0-1 Parent: NetType: Direct Allocation RegDate: 1992-12-01 Updated: 2012-02-24 Ref: <span>http</span>://whois.arin.net/rest/net/NET-8-0-0-0-1 ... # end # start NetRange: 8.8.8.0 - 8.8.8.255 CIDR: 8.8.8.0/24 OriginAS: NetName: LVLT-GOOGL-1-8-8-8 NetHandle: NET-8-8-8-0-1 Parent: NET-8-0-0-0-1 NetType: Reassigned RegDate: 2009-09-21 Updated: 2009-09-21 Ref: <span>http</span>://whois.arin.net/rest/net/NET-8-8-8-0-1 ... # end

हम #end और #start द्वारा परिणाम को तोड़ते हैं और उस हिस्से का चयन करते हैं जो सबसे छोटी श्रेणी (हमारे मामले में, 8.8.8.0 - 8.8.8.255) से मेल खाता है।

खैर, कुछ अंतिम स्पर्श:

1. हम परिणाम को उन सभी रेखाओं से हटाते हैं जिनमें हमारा अपना आईपी पता होता है (कई व्हिसिस सर्वर इसे परिणाम में शामिल करते हैं)।

2. हम सभी HTML टैग्स को हटा देते हैं (कुछ व्हिस सर्वर उन्हें एम्बेड करना चाहते हैं जहां यह आवश्यक नहीं है)।

3. हम जापानी और कोरियाई whois सर्वर के लिए एन्कोडिंग को ठीक करते हैं:

यदि सर्वर का नाम ".jp" के साथ समाप्त होता है, तो हम परिणाम को "iso-2022-jp" के रूप में व्याख्या करने का प्रयास करते हैं (यदि कोई त्रुटि होती है, तो यह ठीक है)।
यदि सर्वर का नाम ".kr" या "krnic.net" के साथ समाप्त होता है, तो हम परिणाम को "euc-kr" के रूप में व्याख्या करने का प्रयास करते हैं (यदि कोई त्रुटि होती है, तो यह ठीक है)।
हम परिणाम को "utf8" के रूप में व्याख्या करने का प्रयास करते हैं। यदि कोई त्रुटि होती है, तो इसे "iso-8859-1" के रूप में व्याख्या करें।

नोट: जापानी और कोरियाई व्हिस सर्वर एक विशेष सिंटैक्स का समर्थन करते हैं जो आपको केवल अंग्रेजी पाठ (चित्रलिपि के बिना) प्रदर्शित करने की अनुमति देता है, लेकिन मैं इसे उद्देश्य से नहीं करता (jwhois और http://whois.domaintools.com के विपरीत )। यदि कोई व्यक्ति जापानी (कोरियाई) डोमेन के बारे में जानकारी ढूंढ रहा है, तो उच्च संभावना के साथ वह जापानी (कोरियाई) भाषा जानता है, और यह अतिरिक्त जानकारी उसके लिए उपयोगी होगी। चित्रलिपि भी हर किसी को कोई नुकसान नहीं पहुंचाता है।

बस इतना ही। यदि आप पूरा लेख पढ़ते हैं, तो आप अगले अनुभाग को सुरक्षित रूप से छोड़ सकते हैं।

संक्षिप्त सारांश

Whois प्रोटोकॉल का काम RFC 3912 ( http://tools.ietf.org/html/rfc3912 ) में वर्णित है , जिसमें न्यूनतम जानकारी होती है और जो “सेल्फ-सर्विस” के लिए एक विस्तृत क्षेत्र में सर्वर छोड़ देता है। वास्तव में, यह निम्नलिखित के लिए उबलता है: वांछित 43 सर्वर पर पोर्ट 43 पर एक टीसीपी कनेक्शन खोलें, एक विशिष्ट प्रारूप में एक अनुरोध भेजें, इसे "\ r \ n" के साथ समाप्त करें और एक विशिष्ट प्रारूप में भी परिणाम प्राप्त करें। प्रत्येक whois सर्वर अपने विवेक पर विशिष्ट विवरण निर्धारित करता है। यह भी हमेशा स्पष्ट नहीं होता है कि किसी विशिष्ट डोमेन या आईपी पते के लिए आवश्यक Whois सर्वर कहां से प्राप्त करें।

Whois जानकारी प्राप्त करने के लिए, एक मानक यूनिक्स उपयोगिता "whois" है, हालांकि यह एक बहुत ही सरल और काफी पुराना एल्गोरिथ्म का उपयोग करता है, जो कई स्थितियों में काम नहीं करता है। विकल्पों में से, jwhois और Ruby Whois को प्रतिष्ठित किया जा सकता है - दोनों प्रोग्राम हार्डकोड के सिद्धांत का उपयोग करते हैं, किलोमीटर कॉन्फ़िगरेशन फ़ाइलों के आधार पर काम करते हैं जिनमें सभी whois सर्वर ज्ञात होते हैं और उनमें से प्रत्येक के साथ काम करने की विशेषताओं का वर्णन होता है। यह दृष्टिकोण भी हमेशा काम नहीं करता है, इसके अलावा, इसे कॉन्फ़िगरेशन के निरंतर अद्यतन की आवश्यकता होती है (यह ध्यान देने योग्य है कि 2011 के बाद से jwhois कॉन्फ़िगरेशन अपडेट नहीं किया गया है)।

जैसा कि अभ्यास से पता चला है, अपने स्वयं के व्हाट्स लाइब्रेरी को लिखना काफी संभव है, जिसमें कम से कम हार्डकोड होगा, लेकिन साथ ही यह आवश्यक व्हाट्स सर्वर को कुशलतापूर्वक निर्धारित करने और उनके साथ संवाद करने में सक्षम होगा।

सामान्य तौर पर, जो तीन मूलभूत कार्यों के लिए उबालता है, उसके साथ काम करना:

सही whois सर्वर का निर्धारण;
सर्वर के लिए सही अनुरोध भेजना;
परिणाम का विश्लेषण।

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

Whois.iana.org अधिकांश WHOIS सर्वर के बारे में जानता है। बस " whois -h whois.iana.org <top level domain> " जैसी रिक्वेस्ट भेजें और प्राप्त करें, अन्य जानकारी के अलावा, आपको जो WHIS सर्वर की जरूरत है उसका नाम। यदि IANA केवल साइट पते को लौटाता है, तो एक निश्चित संभाव्यता वाले WHIS सर्वर को Whois के रूप में "अनुमान लगाया" जा सकता है। <साइट का पता बिना www>।
एक उच्च संभावना के साथ, नाम WHOIS सर्वर के रूप में हो सकता है whois.nic। <शीर्ष-स्तरीय डोमेन या Whois। <शीर्ष-स्तरीय डोमेन>।
कई दूसरे स्तर के डोमेन के अपने स्वयं के सर्वर हैं। अधिकांश मामलों में, उनके नाम फॉर्म whois के हैं। <दूसरा-स्तरीय डोमेन> या whois.nic। <दूसरा-स्तरीय डोमेन>।
व्यक्तिगत शीर्ष-स्तरीय डोमेन के लिए, उपनाम <शीर्ष-स्तरीय डोमेन> .whois-server.net काम करता है।

इस प्रकार, प्रत्येक डोमेन के लिए हमारे पास संभावित व्हाईस सर्वरों की एक पूरी सूची होगी जो परिचालन की अधिक या कम संभावना है। उन्हें प्राथमिकता के क्रम में पूछताछ की जा सकती है, जो उन सर्वरों को याद करते हैं जो काम नहीं करते हैं (या जो मौजूद नहीं हैं) ताकि निम्नलिखित अनुरोधों पर उन्हें एक्सेस न किया जा सके।

पहले whois सर्वर से प्राप्त परिणाम में अतिरिक्त जानकारी के साथ किसी अन्य whois सर्वर का लिंक हो सकता है। सबसे अधिक बार, यह "whois सर्वर: <name>" जैसा दिखेगा, लेकिन कुछ मामलों में यह अलग दिख सकता है। यहां हमें यह नहीं भूलना चाहिए कि कई एलिस सर्वर कई उपनामों के तहत उपलब्ध हैं, और पाया जाने वाला नाम एक अतिरिक्त व्हिस सर्वर नहीं हो सकता है, लेकिन बस पहले सर्वर का एक और उपनाम (व्यवहार में, जो व्हिस सर्वर अक्सर परिणाम में अपना नाम शामिल करते हैं)।

आईपी पते के साथ, स्थिति अलग है। पाँच मुख्य क्षेत्रीय whois सर्वर हैं:

whois.arin.net (ARIN, उत्तरी अमेरिका)
whois.apnic.net (APNIC, एशिया और प्रशांत)
whois.ripe.net (RIPE, यूरोप और मध्य पूर्व)
whois.afrinic.net (अफरीनिक, अफ्रीका)
whois.lacnic.net (LACNIC, लैटिन अमेरिका)

किसी भी IP पते (IPv4 और IPv6 दोनों) के बारे में जानकारी उनमें से किसी एक पर होनी चाहिए। यदि किसी भी क्षेत्रीय सर्वर पर अभी तक आईपी पते का एक समूह आवंटित नहीं किया गया है, तो इस पर जानकारी whois.iana.org पर होनी चाहिए। सभी क्षेत्रीय whois सर्वरों को क्रम में चुना जा सकता है, हालांकि कई मामलों में "गलत" whois सर्वर में तुरंत "सही" लिंक होगा। पहला अनुरोध एआरआईएन को भेजा जा सकता है, क्योंकि यह आईपी पते की सबसे बड़ी संख्या के लिए जिम्मेदार है। क्षेत्रीय whois सर्वरों में से एक के परिणाम में अतिरिक्त whois सर्वर के लिंक भी हो सकते हैं।

यह याद रखने योग्य है कि whois.ripe.net और whois.afrinic.net आसानी से आईपी पते पर प्रतिबंध लगा सकते हैं जिसमें से बहुत सारे अनुरोध आते हैं। इसके अलावा, whois.lacnic.net एक प्रॉक्सी के रूप में काम करता है और, यदि आवश्यक हो, तो अन्य सभी क्षेत्रीय whois सर्वरों को अनुरोध भेजता है (ज़ाहिर है, whois.ripe.net और whois.afrinic.net द्वारा "काउंटर" बढ़ाते हैं)।

अधिकांश मामलों में, Whois सर्वर के लिए सही अनुरोध "<डोमेन या IP पते> \ r \ n" की तरह दिखना चाहिए, हालांकि, कुछ whois सर्वर को एक अलग अनुरोध प्रारूप की आवश्यकता होती है (विवरण के लिए, अनुभाग " अनुरोध को सही तरीके से कैसे भेजें? ") देखें।

कुछ whois सर्वर rwhois ("रेफ़रल व्हिस") नामक एक वैकल्पिक प्रोटोकॉल पर काम करते हैं और पोर्ट 4321 ( http: //en.wikipedia देखें) का उपयोग करते हैं ।org / wiki / Whois # रेफरल_वॉइसऔर http://tools.ietf.org/html/rfc2167 )। इसका कार्यान्वयन काफी जटिल है, इसलिए rwhois सर्वर के साथ काम करने के लिए मौजूदा समाधान (उदाहरण के लिए, http://projects.arin.net/rwhois/ ) का उपयोग करने की अनुशंसा की जाती है । यह याद रखने योग्य है कि कई सर्वर जो खुद को rwhois के रूप में पहचानते हैं, वास्तव में सामान्य whois प्रोटोकॉल का उपयोग करके काम करते हैं! Rwhois के ऊपर उल्लिखित क्लाइंट को इस पर संदेह नहीं है और एक त्रुटि देता है।

जब whois सर्वर से परिणाम अंततः प्राप्त होता है, तो कार्य त्रुटि संदेश से मान्य परिणाम को अलग करना है। व्यवहार में, यह करना आसान नहीं है, क्योंकि विभिन्न व्हिस सर्वरों के लिए त्रुटि संदेश कुछ भी दिख सकता है। मेरे मॉड्यूल में उपयोग किए गए एल्गोरिथ्म को "परिणाम कैसे संसाधित करें?" अनुभाग में विस्तार से वर्णित किया गया है।"

यह याद रखना चाहिए कि कई व्हिस सर्वरों में आईपी पता शामिल होता है जिसमें से अनुरोध किया गया था। इसके अलावा, कुछ व्हाट्स सर्वर अपने परिणामों में एचटीएमएल टैग का उपयोग करते हैं। अधिकांश हूइस सर्वर utf8 एन्कोडिंग में परिणाम लौटाते हैं, हालांकि जापानी और कोरियाई व्हिस सर्वर ।o- का उपयोग करते हैं। क्रमशः 2022-जेपी और यूक-क्र।

एक निष्कर्ष के बजाय

संभवतः whois सबसे लोकप्रिय तकनीक नहीं है, अन्यथा इंटरनेट पर बहुत अधिक उपयोगी जानकारी होगी। फिर भी, मुझे यकीन है कि ऐसे लोग होंगे जिनके लिए यह लेख एक महत्वपूर्ण मात्रा में समय और तंत्रिकाओं को बचाने में मदद करेगा।

Whois: एक व्यावहारिक उपयोगकर्ता गाइड