RFC जिसे अज्ञात डोमेन अनुरोधों का जवाब देने के लिए DNS सर्वरों की आवश्यकता होती है

मेरा डोमेन रजिस्ट्रार और डीएनएस वर्तमान में अज्ञात डोमेन के लिए DNS अनुरोधों की अनदेखी करता है। नजरअंदाज करने से मेरा मतलब ब्लैक-होल है और कभी भी प्रतिक्रिया नहीं देता है जो मेरे DNS क्लाइंट और रिसॉल्वर पुस्तकालयों को पीछे हटने, पीछे हटने और अंत में टालने का कारण बनता है।

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

अन्य लोकप्रिय डोमेन नाम सेवाओं का सर्वेक्षण करने में, मैं देखता हूं कि यह व्यवहार बहुत अनूठा है क्योंकि अन्य प्रदाता 5 का RCODE लौटाते हैं (REFUSE):

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

सभी कुछ निम्नलिखित की तरह लौटें:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

या

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

सर्वर रूम के फर्श पर केवल अनुरोध छोड़ने के विपरीत, वापसी REFUSEDया NXDOMAINतुरंत आईएमएचओ उपयुक्त है।

जब मैं अपने प्रदाता से उनके सर्वर के बारे में कोई प्रतिक्रिया नहीं देता, तो वे मुझसे RFC को उद्धृत करने के लिए कहते हैं कि उनके सर्वर उल्लंघन कर रहे हैं। मुझे पता है कि यह अजीब है कि वे मुझे यह साबित करने के लिए कह रहे हैं कि उनके सर्वर को सभी अनुरोधों का जवाब देना चाहिए लेकिन ऐसा हो।

प्रश्न :

यह मेरी शर्त है कि जब तक डुप्लिकेट रिक्वेस्ट आईडी या किसी प्रकार की डॉस प्रतिक्रिया नहीं होती है, सर्वर को हमेशा रिक्वेस्ट का जवाब देना चाहिए। क्या ये सही है?
अपने वजीफा का समर्थन करने के लिए मुझे RFC और विशिष्ट खंड का क्या कहना चाहिए?

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

में आरएफसी 1536 और 2308 मैं प्रदर्शन कारणों से और एक ही प्रश्न के बंद पुनर्संचरण करने के लिए नकारात्मक कैशिंग के बारे में जानकारी का एक बहुत देखते हैं। में 4074 मैं तो ग्राहक जानता है वहाँ IPv6 जानकारी जो ग्राहक एक आरआरएस जो एक खाली प्रतिक्रिया का एक और उदाहरण है के बारे में पूछने के लिए प्रेरित करना चाहिए नहीं है 0 के एक RCODE के साथ एक खाली जवाब लौटने के बारे में जानकारी देखें।

लेकिन मुझे एक RFC नहीं मिल रहा है जो कहती है कि DNS सर्वर को अनुरोध का जवाब देना चाहिए, शायद इसलिए कि यह निहित है।

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

सहायता के लिए धन्यवाद।

संपादित करें:

इसे पोस्ट करने और मेरे प्रदाता के साथ अनुसरण करने के कुछ महीनों के भीतर, उन्होंने NXDOMAINअज्ञात डोमेन पर लौटने के लिए अपने सर्वर बदल दिए ।

domain-name-system rfc protocol

— ग्रे - एसओ बुराई होना बंद करो
स्रोत

— ग्रे - SO रोक बुराई जा रहा है

जवाबों:

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

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

DNS सर्वरों की मूल कार्यक्षमता RFC 1034 और RFC 1035 दस्तावेजों द्वारा कवर की जाती है , जो सामूहिक रूप से STD 13 बनाते हैं । इसका उत्तर या तो इन दो RFC से आना चाहिए, या बाद में RFC द्वारा स्पष्ट किया जाना चाहिए जो इसे अद्यतन करता है।

इससे पहले कि हम जारी रखें, DNS के दायरे के बाहर यहां एक बड़ा नुकसान है जिसे बाहर करने की आवश्यकता है: ये दोनों RFC बीसीपी 14 (1997) से पहले हैं, जिस दस्तावेज ने MAY, MUST, SHOULD, आदि की भाषा को स्पष्ट किया।

इस भाषा के औपचारिक होने से पहले जो मानक लिखे गए थे, उन्होंने स्पष्ट भाषा का उपयोग किया है, लेकिन कई मामलों में ऐसा नहीं किया गया। इसके कारण सॉफ्टवेयर, जन भ्रम, इत्यादि के अलग-अलग क्रियान्वयन हुए।
एसटीडी 13 दुर्भाग्य से कई क्षेत्रों में व्याख्यात्मक होने का दोषी है। यदि भाषा ऑपरेशन के क्षेत्र में दृढ़ नहीं है, तो एक स्पष्ट आरएफसी खोजना अक्सर आवश्यक होता है।

उस रास्ते से बाहर, चलो आरएफसी 1034 .14.3.1 के साथ क्या कहना है:

सर्वर के लिए सबसे सरल मोड गैर-पुनरावर्ती है, क्योंकि यह केवल स्थानीय जानकारी का उपयोग करके प्रश्नों का उत्तर दे सकता है: प्रतिक्रिया में एक त्रुटि, उत्तर या किसी अन्य सर्वर के उत्तर के करीब "संदर्भ" होता है। सभी नाम सर्वरों को गैर-पुनरावर्ती प्रश्नों को लागू करना चाहिए।

...

यदि पुनरावर्ती सेवा का अनुरोध नहीं किया गया है या उपलब्ध नहीं है, तो गैर-पुनरावर्ती प्रतिक्रिया निम्नलिखित में से एक होगी:

एक आधिकारिक नाम त्रुटि यह दर्शाता है कि नाम मौजूद नहीं है।

एक अस्थायी त्रुटि संकेत।

कुछ संयोजन:

आरआरएस जो सवाल का जवाब देते हैं, एक संकेत के साथ कि क्या डेटा एक ज़ोन से आता है या कैश किया गया है।

उन नाम सर्वरों का एक रेफरल जिसमें ज़ोन होते हैं जो उत्तर भेजने वाले सर्वर की तुलना में नाम के करीब पूर्वजों के होते हैं।

आरआर कि नाम सर्वर को लगता है कि आवश्यककर्ता के लिए उपयोगी साबित होगा।

यहाँ की भाषा यथोचित दृढ़ है। कोई "होना चाहिए" नहीं है, लेकिन एक "होगा"। इसका मतलब यह है कि अंतिम परिणाम या तो 1 होना चाहिए) ऊपर की सूची में परिभाषित किया गया है, या 2) मानक ट्रैक पर एक बाद के दस्तावेज़ के लिए अनुमत है जो कार्यक्षमता का संशोधन करता है। मुझे अनुरोध की अनदेखी करने के लिए मौजूदा किसी भी ऐसी क्रिया के बारे में पता नहीं है और मैं कहूंगा कि शोध को खोजने के लिए भाषा को खोजने के लिए डेवलपर पर है।

नेटवर्क दुरुपयोग परिदृश्यों में DNS की लगातार भूमिका को देखते हुए, यह नहीं कहा जाना चाहिए कि DNS सर्वर सॉफ़्टवेयर फ़्लोर पर चुनिंदा ट्रैफ़िक छोड़ने के लिए नॉब्स प्रदान नहीं करता है , जो तकनीकी रूप से इसका उल्लंघन होगा। उस ने कहा, ये या तो डिफ़ॉल्ट व्यवहार नहीं हैं या बहुत रूढ़िवादी चूक के साथ हैं; दोनों के उदाहरण उपयोगकर्ता को एक विशिष्ट नाम ( rpz-drop.) को गिराने के लिए सॉफ़्टवेयर की आवश्यकता होगी , या कुछ संख्यात्मक सीमाएं पार की जा रही हैं (BIND max-clients-per-query)। सॉफ्टवेयर के लिए मेरे अनुभव में यह लगभग अनसुना है कि सभी पैकेटों के लिए डिफ़ॉल्ट व्यवहार को पूरी तरह से बदल दिया जाए जो मानक का उल्लंघन करता है, जब तक कि विकल्प एक है जो पुराने उत्पादों के लिए सहिष्णुता बढ़ाता है एक मानक का उल्लंघन करता है। यहां पर यह मामला नहीं है।

संक्षेप में, यह आरएफसी ऑपरेटरों के विवेक पर उल्लंघन कर सकता है और कर सकता है, लेकिन आमतौर पर यह किसी तरह की सटीकता के साथ किया जाता है। यह पूरी तरह से मानक के खंडों की उपेक्षा करने के लिए बेहद असामान्य है , खासकर जब पेशेवर आम सहमति (उदाहरण: BCP 16 CP3.3 ) के पक्ष में यह गलत है कि यह पूरी तरह से DNS सिस्टम पर अनावश्यक भार उत्पन्न करने के लिए अवांछनीय है। सभी अनुरोधों को छोड़ने से अनावश्यक पुनर्प्रयास जिसके लिए कोई आधिकारिक डेटा मौजूद नहीं है, यह ध्यान में रखते हुए वांछनीय से कम है।

अपडेट करें:

विषय के रूप में फर्श पर प्रश्नों को छोड़ने के लिए अवांछनीय होने के संबंध में, @Alnitak ने हमारे साथ साझा किया कि वर्तमान में इस विषय को विस्तार से कवर करने वाला एक ड्राफ्ट BCP है। इसे एक उद्धरण के रूप में उपयोग करने के लिए थोड़ा समय से पहले है, लेकिन यह उस समुदाय की आम सहमति को मजबूत करने में मदद करता है जो यहां व्यक्त की जा रही है। विशेष रूप से:

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

जब इस दस्तावेज़ की स्थिति बदल जाती है तो यह उत्तर अपडेट किया जाएगा।

— एंड्रयू बी
स्रोत

वह एक अच्छा कैच था। मैं आमतौर पर एक है कि shouldबनाम बाहर फोन कर रहा हूँ must। मैं will beउस अर्थ में सही स्किम कर रहा हूं ।

— एरोन

धन्यवाद एंड्रयू अच्छा सामान। "हो जाएगा" के बारे में के रूप में मुझे मिल सकता है के रूप में करीब लगता है।

— ग्रे - SO रुक जाना बुराई

यह भी देखें tools.ietf.org/html/draft-ietf-dnsop-no-response-issue

— एल्निटैक

@Alnitak बहुत अच्छा लगता है, मैं इसे जोड़ दूँगा।

— एंड्रयू बी

@AndrewB मुश्किल से एक "खोज", क्योंकि यह मेरे एक सहयोगी ने लिखा है: p

— Alnitak

जब आप किसी नए प्रदाता के लिए डोमेन के लिए आधिकारिक DNS ले जा रहे हैं, तो आपको अपने डोमेन पंजीकरण (WHOIS) की जानकारी को बदलने से पहले हमेशा नए प्रदाता के खिलाफ (और सुनिश्चित करें कि वे सटीक, कॉन्फ़िगर रिकॉर्ड भेज रहे हैं) परीक्षण हमेशा (हमेशा) करना चाहिए। नए आधिकारिक DNS सर्वर को इंगित करने के लिए।

मोटे तौर पर, आप जो कदम उठाएंगे:

नए DNS प्रदाता पर सब कुछ सेट करें। आपको सभी जोनों को बनाना और आबाद करना चाहिए।
सुनिश्चित करें कि नए आधिकारिक सर्वर सही तरीके से काम कर रहे हैं। उन्हें स्पष्ट रूप से क्वेरी करें:
```
dig @new-ns.example.com mydomain.com
```
आपके प्रश्न से यह कैसा लगता है, क्या वे इन प्रश्नों का उत्तर नहीं दे रहे हैं? लेकिन, आपने "अज्ञात डोमेन" कहा, जो इस बिंदु पर नहीं होना चाहिए, यह पूरी तरह से उनके सिस्टम में कॉन्फ़िगर किया जाना चाहिए (और कॉन्फ़िगर किए गए रिकॉर्ड के साथ जवाब देना)।

लेकिन, यदि आपने पहले ही डोमेन को अपने सिस्टम में कॉन्फ़िगर कर लिया है, तो इस बिंदु पर सही रिकॉर्ड के साथ जवाब देना होगा। यदि ऐसा नहीं है तो वे ज़ोन को ठीक से होस्ट नहीं कर रहे हैं, और आपको उन पर चिल्लाना चाहिए; चाहे या नहीं यह एक डोमेन के लिए प्रतिक्रिया करता है जो इसे कॉन्फ़िगर नहीं किया गया है वह असंगत होना चाहिए। (यदि मैं अभी भी किसी तरह से याद कर रहा हूँ कि आप क्या कह रहे हैं, तो कृपया मुझे बताएं)
अपने डोमेन रजिस्ट्रार (whois) के साथ आधिकारिक नाम सर्वर को स्विच करें, पुराने DNS प्रदाता को छोड़ दें और तब तक चलाएं जब तक कि ट्रैफ़िक इसे हिट न कर दे (इसे कम से कम 24 घंटे दें)।

यदि नया प्रदाता पूरी तरह से स्विच करने से पहले आपके रिकॉर्ड को पॉप्युलेट नहीं कर सकता है, तो वे कैसे प्रतिक्रिया देते हैं, यह वास्तव में कोई मायने नहीं रखता है - उपयोगकर्ताओं को एक आधिकारिक की ओर इशारा करते हुए, जो क्वेरी को पूरी तरह से मना कर देता है, आपके डोमेन के लिए डाउनटाइम को उसी तरह से बाधित करेगा जैसे आप थे कोई प्रतिक्रिया नहीं मिल रही है।

— शेन मैडेन
स्रोत

मुझे खेद है, यह सब अच्छी सलाह है लेकिन यह मेरे किसी भी सवाल का जवाब कैसे देता है?

— ग्रे - एसओ बुराई को

@Gray आपको यह बताकर कि आपका माइग्रेशन पथ टूट गया है यदि आप नए DNS होस्ट को हाथ से पहले रिकॉर्ड करने की योजना नहीं बना रहे हैं। काम नहीं कर रहे हैं कि नए आधिकारिक सर्वर को इंगित करने के लिए अपने पंजीकरण को बदलना एक गलती है , भले ही वे एक REFUSEDया कोई प्रतिक्रिया नहीं भेज रहे हैं ; दोनों समान रूप से टूट गए हैं। लेकिन अगर आप मेरे जवाब को पढ़ने के लिए परेशान नहीं हो सकते हैं, तो मैं आपकी मदद करने की कोशिश कर रहा हूं।

— शेन मैडेन

बस यहां कुछ संदर्भ प्रदान करने के लिए, यह आलोचना उस जानकारी से उभर रही है जिसे हटाए गए उत्तर से संबंधित टिप्पणियों में साझा किया गया था। "विशिष्ट समस्या तब होती है जब मैं अपने DNS नाम सेवा को उनके सर्वर पर ले जाता हूं। रूट WHOIS रिकॉर्ड बदलने के समय के बीच एक अंतराल होता है और उनके सर्वर को मेरा DNS रिकॉर्ड मिलता है। इसलिए एक समय ऐसा आता है जब DNS क्लाइंट को लगता है कि उनके सर्वर आधिकारिक हैं। लेकिन वे कभी अनुरोध का जवाब नहीं देते हैं। ”

— एंड्रयू बी

तक स्विच whois रिकॉर्ड मैं तुम्हें नहीं बल्कि मतलब मान NS(दोनों पर आधिकारिक और प्रतिनिधिमंडल की ओर) रिकॉर्ड?

— होनक लिंडक्विस्ट

WHOIS का आधिकारिक DNS में कोई संलिप्तता है, चाहे वह विषय का ज्ञान प्रदर्शित करता हो या नहीं, इंटरनेट पर मस्तिष्क का विष है। : पी

— एंड्रयू बी '