सुरक्षा के फ़ायदे

डीएनएस सुरक्षा से जुड़े खतरों और खतरों से निपटने के बारे में जानकारी

डोमेन नेम सिस्टम के खुले, डिस्ट्रिब्यूटेड डिज़ाइन और उपयोगकर्ता डेटाग्राम प्रोटोकॉल (यूडीपी) के इस्तेमाल की वजह से, डीएनएस पर कई तरह से हमला होने का खतरा होता है. सार्वजनिक या कोट;बार-बार होने वाले डीएनएस रिज़ॉल्वर जोखिम में होते हैं. ऐसा इसलिए होता है, क्योंकि इनसे आने वाले पैकेट को अनुमति वाले सोर्स आईपी पतों के सेट पर पाबंदी नहीं लगती. हम ज़्यादातर दो तरह के हमलों से परेशान हैं:

  • ऐसे झूठे हमले जो DNS कैश पॉइज़निंग की ओर ले जाते हैं. डीएनएस स्पूफ़िंग और जालसाज़ी का कई तरह से फ़ायदा होता है. इसका मकसद उपयोगकर्ताओं को सही साइटों से नुकसान पहुंचाने वाली वेबसाइटों पर रीडायरेक्ट करना है. इनमें तथाकथित Kaminsky के हमले शामिल हैं, जिनमें हमलावर पूरे डीएनएस ज़ोन का आधिकारिक कंट्रोल लेते हैं.
  • सेवा में रुकावट (डीओएस) से जुड़े हमले. हमलावर, रिज़ॉल्वर के ख़िलाफ़ डीडीओएस अटैक लॉन्च कर सकते हैं या अन्य सिस्टम पर DoS अटैक लॉन्च करने के लिए, हाइजैक करने वालों को हाइजैक कर सकते हैं. ऐसे हमले जो बड़े डीएनएस रिकॉर्ड/रिस्पॉन्स साइज़ का पता लगाकर, दूसरे सिस्टम पर DoS हमले शुरू करने के लिए डीएनएस सर्वर का इस्तेमाल करते हैं, उन्हें माइलिफ़िकेशन अटैक कहा जाता है.

हमले की हर श्रेणी के बारे में नीचे चर्चा की गई है.

कैश पॉइज़निंग हमले

डीएनएस स्पूफ़िंग हमलों के कई वैरिएंट हैं, जिनकी वजह से कैश मेमोरी पॉइज़िंग हो सकती है. हालांकि, आम तौर पर ये समस्याएं होती हैं:

  1. हमलावर एक डोमेन नाम के लिए टारगेट डीएनएस रिज़ॉल्वर कई क्वेरी भेजता है, जिसके लिए उसे पता होता है कि सर्वर भरोसेमंद नहीं है. हो सकता है कि सर्वर और कैश मेमोरी में ऐसा होने की संभावना न हो.
  2. रिज़ॉल्वर अन्य नाम सर्वर को अनुरोध भेजता है जिनके आईपी पतों का अनुमान भी लगाया जा सकता है.
  3. इस बीच, हमलावर पीड़ित सर्वर को फ़र्जी जवाब से भर देता है, जो ज़बर्दस्त नाम सर्वर की ओर से दिखाई देते हैं. रिस्पॉन्स में ऐसे रिकॉर्ड शामिल होते हैं जो अनुरोध किए गए डोमेन को, हमलावर के कंट्रोल वाले आईपी पतों से हल करते हैं. हो सकता है कि उनके पास हल किए गए नाम के जवाब वाले रिकॉर्ड हों या इससे भी बुरा यह हो सकता है कि वे हमलावर के पास किसी नाम सर्वर को अपनी अनुमति दें, ताकि वे पूरे ज़ोन को कंट्रोल कर सकें.
  4. अगर फ़र्ज़ी जवाबों में से कोई एक, रिज़ॉल्वर के अनुरोध (उदाहरण के लिए, क्वेरी के नाम, टाइप, आईडी, और रिज़ॉल्वर सोर्स पोर्ट से) से मेल खाता है, तो आपको रिज़ॉल्वर के असली सर्वर से रिस्पॉन्स मिलने से पहले ही उसे स्वीकार कर लिया जाता है. साथ ही, यह असली रिस्पॉन्स को खारिज कर देता है.
  5. हैक किए गए डोमेन या ज़ोन के लिए, आने वाले समय की क्वेरी का जवाब, कैश मेमोरी के नकली डीएनएस रिज़ॉल्यूशन से दिया जाता है. अगर हमलावर ने फ़र्जी जवाब पर बहुत लंबा समय दिया है, तो फ़र्जी रिकॉर्ड रीफ़्रेश किए बिना ही कैश मेमोरी में सेव रहते हैं.

Kaminsky के हमलों की बेहतरीन जानकारी के लिए, Kaminsky डीएनएस के जोखिम की संभावना का गाइड.

डॉस और एम्प्लफ़िकेशन हमले

डीएनएस रिज़ॉल्वर, सेवा की शर्तों वाले ऐसे सामान्य खतरों पर निर्भर होते हैं जिनकी वजह से किसी भी नेटवर्क सिस्टम को खतरा होता है. हालांकि, एम्प्लफ़िकेशन हमले की चिंता और ज़्यादा होती है, क्योंकि डीएनएस रिज़ॉल्वर उन हमलावरों के लिए आकर्षक होते हैं जो रिज़ॉल्वर&#39 का फ़ायदा उठाते हैं. साथ ही, ज़्यादा मुफ़्त बैंडविड्थ पाने के लिए, अनुरोध का जवाब देने के लिए बड़े पैमाने पर अनुपात भी अपनाया जाता है. रिज़ॉल्वर, जो डीएनएस के लिए EDNS0 (एक्सटेंशन मैकेनिज़्म) की सुविधा देते हैं, उनके लिए खास तौर पर जोखिम की संभावना होती है, क्योंकि वे बड़े साइज़ के पैकेट पर लौट सकते हैं.

प्रचार करने की स्थिति में, हमला इस तरह होता है:

  1. हमलावर, नकली सोर्स आईपी पते का इस्तेमाल करके, पीड़ित डीएनएस सर्वर क्वेरी भेजता है. क्वेरी एक ही नकली आईपी पते का इस्तेमाल करके, किसी एक सिस्टम या सिस्टम के नेटवर्क से भेजी जा सकती है. क्वेरी के रिकॉर्ड ऐसे होते हैं जिनके बारे में हमलावर को पता होता है कि इसकी वजह से कई बड़े पैमाने पर जवाब मिलेंगे, कई बार दर्जनों क्वेरी के जवाब मिल सकते हैं1 मूल क्वेरी का साइज़ इस तरह होता है (इसलिए, नाम और कोटेशन के हमले और कोटेशन का हमला).
  2. पीड़ित सर्वर, फ़र्जी अनुरोधों में भेजे गए स्रोत आईपी पते को बड़े जवाब भेजता है, जिससे सिस्टम पर असर पड़ता है और सेवा की शर्तें खत्म हो जाती हैं.

गड़बड़ी की गंभीरता को कम करना

डीएनएस जोखिम की संभावना का स्टैंडर्ड सिस्टम में समाधान डीएनएसएसईसी है. हालांकि, जब तक सभी प्लैटफ़ॉर्म को लागू नहीं किया जाता, तब तक ओपन डीएनएस रिज़ॉल्वर को स्वतंत्र रूप से कुछ तरीके अपनाने होंगे, ताकि जाने-पहचाने खतरों से बचा जा सके. कई तकनीकों का सुझाव दिया गया है; IETF RFC 5452: देखें कि फ़र्जी जवाबों के ख़िलाफ़ डीएनएस की समस्याओं को कैसे रोका जा सकता है. Google की सार्वजनिक डीएनएस सेवा में, हमने ये तरीके लागू किए हैं:

  • बफ़र ओवरफ़्लो से अपने कोड को सुरक्षित करना, खास तौर पर डीएनएस मैसेज को पार्स करने और क्रम से लगाने के लिए ज़िम्मेदार कोड.
  • रिज़ॉल्वर पर सीधे तौर पर किए जाने वाले हमलों के ख़िलाफ़ सुरक्षा के लिए, मशीन संसाधनों का ज़्यादा इस्तेमाल. जैसा कि हमलावरों के लिए आईपी पते बहुत छोटे हैं, आईपी पते या सबनेट के आधार पर क्वेरी को ब्लॉक करना नामुमकिन है, ऐसे हमलों को रोकने का सिर्फ़ यही असरदार तरीका है कि हम इस लोड को कम कर दें.
  • रिस्पॉन्स पैकेट और नाम सर्वर की विश्वसनीयता के बारे में मान्यता की बुनियादी जांच करना. इससे, कैश मेमोरी में मौजूद कम पॉइज़निंग से बचा जा सकता है. ये स्टैंडर्ड मैकेनिज़्म और सैनिटिटी चेक होते हैं. जांच करके यह पता लगाया जाता है कि सभी शर्तों का पालन करने वाले कैशिंग रिज़ॉल्वर को काम करना चाहिए या नहीं.
  • मैसेज का अनुरोध करने के लिए एंट्रॉपी जोड़ना. इससे, कमिंग्सकी हमलों जैसे, झूठे नाम से भेजे जाने वाले और ज़हरीले ज़हरीले हमलों की संभावना कम हो जाएगी. एंट्रॉपी जोड़ने के कई तरीके हैं. नीचे हमने इन सुविधाओं के फ़ायदों, सीमाओं, और चुनौतियों के बारे में खास जानकारी दी है. साथ ही, हमने इस पर चर्चा भी की है कि हमने Google की सार्वजनिक डीएनएस सेवा में इन्हें कैसे लागू किया है.
  • डुप्लीकेट क्वेरी हटाना, ताकि & "जन्मदिन हमलों" की संभावना पर रोक लगाई जा सके.
  • दर-सीमित अनुरोध, DoS और एम्प्लिकेशन को रोकने के लिए.
  • सबसे ज़्यादा बैंडविड्थ का इस्तेमाल करके, क्लाइंट आईपी के लिए सेवा पर नज़र रखना और अनुरोध के लिए सबसे ज़्यादा साइज़ अनुपात का अनुभव करना.

डीएनएसएसईसी

डोमेन नेम सुरक्षा एक्सटेंशन (डीएनएसएसईसी), कई आईईटीएफ़ आरएफ़सी में बताए गए हैं: 4033, 4034, 4035, और 5155.

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

जनवरी 2013 से, Google की सार्वजनिक डीएनएस सेवा, डीएनएसएसईसी को पूरी तरह से इस्तेमाल करती है. हम डीएनएसएसईसी के फ़ॉर्मैट वाले मैसेज स्वीकार करते हैं और उन्हें फ़ॉरवर्ड करते हैं. इसके बाद, हम पुष्टि करने के लिए मिले जवाबों की पुष्टि करते हैं. हम अन्य समीक्षकों को भी यही करने की सलाह देते हैं.

हम NSEC के जवाबों को कैश मेमोरी में सेव करते हैं, जैसा कि IETF RFC 8198: DNSSEC की पुष्टि वाली कैश मेमोरी का इस्तेमाल के लिए किया गया है. इसकी मदद से, डीएनएसएसईसी को लागू करने वाले नाम सर्वर पर, NXDOMAIN क्वेरी कम की जा सकती हैं. साथ ही, नेगेटिव जवाबों के लिए NSEC का इस्तेमाल किया जा सकता है.

क्लाइंट-साइड से एन्क्रिप्ट (सुरक्षित) की गई सेवाएं

Google की सार्वजनिक डीएनएस सेवा, एन्क्रिप्ट (सुरक्षित) किए गए ट्रांसपोर्ट प्रोटोकॉल एचटीटीपीएस पर डीएनएस और TLS पर डीएनएस के साथ काम करती है. ये प्रोटोकॉल, क्लाइंट और Google की सार्वजनिक डीएनएस सेवा के साथ छेड़छाड़ और झूठे नाम से मेल भेजने, और निजता और सुरक्षा को बेहतर बनाते हुए छिपे और झूठे नाम से जाने को रोकते हैं. ये, पूरी तरह पुष्टि किए गए डीएनएस लुकअप उपलब्ध कराने के लिए, डीएनएसएसईसी को पूरक बनाते हैं.

वैधता की बुनियादी जांच लागू करना

कुछ डीएनएस कैश खराबी की वजह अनजाने में हो सकती है, ज़रूरी नहीं है कि यह नुकसान पहुंचाने और अनुरोधों और जवाबों के बीच मैच न हो (उदाहरण के लिए, गलत तरीके से कॉन्फ़िगर किए गए नाम सर्वर, डीएनएस सॉफ़्टवेयर में गड़बड़ी वगैरह) डीएनएस रिज़ॉल्वर को कम से कम जांच करनी चाहिए कि नाम सर्वर की विश्वसनीयता और कितने काम के रिस्पॉन्स हैं. हम नीचे दिए गए सभी बचावों का सुझाव देते हैं (और लागू करते हैं):

  • आउटगोइंग अनुरोधों में बार-बार होने वाला बिट सेट न करें. साथ ही, हमेशा डेलिगेशन चेन का साफ़ तौर पर पालन करें. बार-बार होने वाले बिट को बंद करने से, यह पक्का हो जाता है कि आपका रिज़ॉल्वर कोटेशन और कोट मोड में काम करे. इससे आप, डेलिगेट चेन में हर नेम सर्वर को क्वेरी कर पाएंगे. बजाय, किसी दूसरे नेम सर्वर को आपकी ओर से ये क्वेरी करने की अनुमति न दें.
  • संदिग्ध जवाब के मैसेज को अस्वीकार करना. नीचे दी गई जानकारी के लिए, जिसे हम देखते हैं कि हम क्या कर सकते हैं, कोट, और संदिग्ध.
  • पिछले अनुरोधों से कैश किए गए ग्लू रिकॉर्ड के आधार पर क्लाइंट को A रिकॉर्ड न दिखाएं. उदाहरण के लिए, अगर आपको ns1.example.com के लिए क्लाइंट क्वेरी मिलती है, तो आपको .com टीएलडी नेम सर्वर से लौटाए गए कैश ग्लू रिकॉर्ड के आधार पर A रिकॉर्ड भेजने के बजाय, पते का समाधान करना होगा.

ज़रूरी शर्तों को पूरा न करने वाले जवाबों को अस्वीकार करना

Google की सार्वजनिक डीएनएस सेवा उन सभी को अस्वीकार करती है:

  • पार्स नहीं किए जा सकने वाले या गलत जवाब.
  • ऐसे जवाब जो मुख्य फ़ील्ड के लिए, अनुरोध में दिए गए फ़ील्ड से मेल नहीं खाते. इसमें क्वेरी आईडी, सोर्स आईपी, सोर्स पोर्ट, डेस्टिनेशन आईपी या क्वेरी का नाम शामिल है. डीएनएस स्पूफ़ के व्यवहार के बारे में पूरी जानकारी पाने के लिए, आरएफ़सी 5452. सेक्शन 3 देखें.
  • ऐसे रिकॉर्ड जो अनुरोध के मुताबिक नहीं हैं.
  • जवाब वाले ऐसे रिकॉर्ड जिनके लिए हम CNAME चेन को फिर से नहीं बना सकते.
  • (जवाब, अधिकार या दूसरे सेक्शन में मौजूद) रिकॉर्ड, जिनके लिए जवाब देने वाला नाम सर्वर भरोसेमंद नहीं है. हम किसी डोमेन के लिए, नाम सर्वर की डेलिगेशन चेन में उस नाम को शामिल करना और उसको भरोसेमंद बनाना चाहते हैं. Google की सार्वजनिक डीएनएस सेवा, डेलिगेशन चेन की जानकारी को कैश मेमोरी में सेव करती है. हम कैश मेमोरी में सेव की गई हर जानकारी की पुष्टि, जवाब देने वाले नाम सर्वर और किसी अनुरोध के जवाब के लिए भरोसेमंद होने का पता लगाते हैं.

अनुरोधों में एंट्रॉपी जोड़ना

जब रिज़ॉल्वर बुनियादी बुनियादी जांच करता है, तो हमलावर को रिज़ॉल्व करने वाले व्यक्ति को क्वेरी आईडी, यूडीपी पोर्ट (अनुरोध का जवाब), आईपी पते, और मूल नाम सर्वर की क्वेरी से पहले उसके नाम के साथ मिलान करने की कोशिश करनी होती है.

माफ़ करें, इसे हासिल करना मुश्किल नहीं है, क्योंकि इस फ़ील्ड में क्वेरी की पहचान करने वाला खास फ़ील्ड सिर्फ़ 16 बिट लंबा होता है (यानी कि 1/65,536 की जगह पर इसे दिखाने का मौका सही होता है). दूसरे फ़ील्ड की सीमा भी सीमित है. इस वजह से, यूनीक कॉम्बिनेशन की कुल संख्या सामान्य से कम है. इसमें शामिल मिलेमिनिक्स के हिसाब के लिए आरएफ़सी 5452, सेक्शन 7 देखें.

इसलिए, चुनौती यह है कि अनुरोध के पैकेट को जितना हो सके उतना इस्तेमाल करें. इसका इस्तेमाल डीएनएस मैसेज के स्टैंडर्ड फ़ॉर्मैट में किया जा सकता है. इससे हमलावरों के लिए, फ़ील्ड में डाली गई मान्य वैल्यू का सही तरीके से मिलान करना मुश्किल हो जाता है. हम इन सेक्शन में बताई गई सभी तकनीकों का सुझाव देते हैं और लागू करते हैं.

हमने जुलाई 2022 में, डीएनएस ओएआरसी 38 कॉन्फ़्रेंस में जिन तकनीकों के बारे में बताया था उन्हें अपडेट किया गया है बताया गया है. प्रज़ेंटेशन में नाम सर्वर ऑपरेटर के लिए भी सुझाव शामिल होते हैं.

सोर्स पोर्ट को किसी भी क्रम में लगाना

बेसिक तरीके के तौर पर, आउटगोइंग अनुरोध पैकेट को डिफ़ॉल्ट यूडीपी पोर्ट 53 का इस्तेमाल करने की अनुमति न दें. साथ ही, कई पोर्ट असाइन करने के लिए, अनुमान लगाने वाले एल्गोरिदम का इस्तेमाल न करें (जैसे कि आसान तरीके से बढ़ाना). अपने सिस्टम के लिए 1024 से 65535 तक की अलग-अलग पोर्ट का इस्तेमाल करें. साथ ही, पोर्ट असाइन करने के लिए किसी भरोसेमंद रैंडम जनरेटर का इस्तेमाल करें. उदाहरण के लिए, Google की सार्वजनिक डीएनएस सेवा करीब 32, 000 अलग-अलग पोर्ट नंबर की अनुमति देने के लिए,~15 बिट का इस्तेमाल करती है.

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

नेम सर्वर को किसी भी क्रम में लगाना

कुछ रिज़ॉल्वर, रूट, टीएलडी या अन्य नाम सर्वर को अनुरोध भेजते समय, कम से कम दूरी (इंतज़ार के समय) के आधार पर नाम सर्वर का आईपी पता चुनें. हमारा सुझाव है कि आप डेस्टिनेशन अनुरोधों में एंट्रॉपी जोड़ने के लिए, डेस्टिनेशन आईपी पतों को किसी भी क्रम में लगाएं. Google सार्वजनिक डीएनएस में, हम हर ज़ोन के लिए कॉन्फ़िगर किए गए नाम सर्वरों में से, किसी भी नाम वाले सर्वर को बिना किसी क्रम के चुनते हैं. ऐसा करते समय, हम तेज़ और भरोसेमंद नाम सर्वर का इस्तेमाल करते हैं.

अगर आप इंतज़ार के समय के बारे में चिंता करना चाहते हैं, तो आप दोतरफ़ा यात्रा का समय (आरटीटी) बैंडिंग का इस्तेमाल कर सकते हैं. इसमें पते की रेंज में किसी भी क्रम में लगने वाली जगह (जैसे कि 30 मि॰से॰, 300 मि॰से॰ वगैरह) शामिल हो सकती है.

डीएनएस कुकी

आरएफ़सी 7873, डीएनएस मैसेज में 64-बिट कुकी जोड़ने के लिए EDNS0 विकल्प के बारे में बताता है. डीएनएस कुकी के साथ काम करने वाली क्लाइंट कुकी में, किसी अनुरोध में बिना किसी क्रम के, 64-बिट की कुकी और वैकल्पिक तौर पर एक सर्वर कुकी शामिल होती है. अगर काम करने वाला सर्वर किसी अनुरोध में मान्य कुकी विकल्प ढूंढता है, तो वह रिस्पॉन्स में क्लाइंट कुकी और सही सर्वर कुकी दिखाता है. इसके बाद, काम करने वाला क्लाइंट रिस्पॉन्स में क्लाइंट कुकी की पुष्टि करके सर्वर से आने वाले रिस्पॉन्स की पुष्टि कर सकता है.

अगर कोई नाम सर्वर डीएनएस कुकी के साथ काम नहीं करता है, तो एंट्रॉपी जोड़ने के लिए इन दो विकल्पों का इस्तेमाल किया जा सकता है.

क्वेरी के नामों में रैंडम केस

डीएनएस मानकों के लिए यह ज़रूरी है कि नाम सर्वर, केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) से नाम रखें. उदाहरण के लिए, example.com और EXAMPLE.COM के नाम एक ही आईपी पते से हल होने चाहिए2. इसके अलावा, नाम सर्वर की मामूली संख्या को छोड़कर बाकी सभी नाम, जवाब में नाम को इको करते हैं, जैसा कि अनुरोध में दिखाया गया था. यह मूल केस को बनाए रखता है.

इसलिए, अनुरोधों में एंट्रॉपी जोड़ने का एक और तरीका है, डोमेन नेम के बारे में क्वेरी किए जाने पर, अक्षरों के केस को अलग-अलग तरीके से बदलना. इस तकनीक को 'कोट्स;0020&quot' भी कहा जाता है, क्योंकि अमेरिका के ASCII अक्षरों को सेट करने के लिए, 0x20 बिट का इस्तेमाल किया जाता है. सबसे पहले, आईईटीएफ़ इंटरनेट ड्राफ़्ट में इस बात का सुझाव दिया गया था. लेन-देन की पहचान को बेहतर बनाने के लिए डीएनएस लेबल में बिट 0x20 का इस्तेमाल करें. इस तकनीक से, नाम सर्वर का जवाब न सिर्फ़ क्वेरी के नाम से मेल खाना चाहिए, बल्कि नाम स्ट्रिंग के हर अक्षर के मामले से भी मेल खाना चाहिए; उदाहरण के लिए, wWw.eXaMpLe.CoM या WwW.ExamPLe.COm. इससे टॉप लेवल और रूट डोमेन के लिए, क्वेरी में बहुत कम या कोई एंट्री नहीं आ सकती. हालांकि, यह ज़्यादातर होस्टनेम के लिए असरदार होता है.

इस तकनीक को लागू करते समय एक बड़ी चुनौती यह है कि कुछ नाम सर्वर, उम्मीद के मुताबिक काम नहीं करते हैं:

  • कुछ नाम सर्वर, केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) के साथ जवाब देते हैं: वे अनुरोध की स्थिति पर ध्यान दिए बिना, एक जैसे नतीजे दिखाते हैं, लेकिन अनुरोध में दिए गए नाम से पूरी तरह मेल नहीं खाता.
  • अन्य नाम सर्वर, केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) का जवाब देते हैं (डीएनएस मानकों का उल्लंघन करते हुए): ये अनुरोध के मामले में, एक जैसे नामों को अलग-अलग तरीके से हैंडल करते हैं, सभी पर जवाब नहीं देते हैं या गलत NXDOMAIN रिस्पॉन्स देते हैं जो अनुरोध में दिए गए नाम से पूरी तरह मेल खाते हैं.
  • arpa ज़ोन में, PTR क्वेरी के अलावा कुछ नाम सर्वर ठीक से काम करते हैं.

इन दोनों तरह के नेम सर्वर के लिए, क्वेरी के नाम को बदलने से अनचाहे नतीजे मिलेंगे: पहले ग्रुप के लिए, रिस्पॉन्स को फ़र्जी जवाब से अलग नहीं किया जा सकेगा; दूसरे ग्रुप के लिए, रिस्पॉन्स (अगर कोई हो) पूरी तरह से गलत हो सकता है.

इस समस्या को हल करने के लिए, हम सिर्फ़ नाम सर्वर के लिए, अलग-अलग केस का इस्तेमाल करना चाहते हैं. ये ऐसे नाम सर्वर हैं जो हमारे हिसाब से स्टैंडर्ड को लागू करते हैं. हम अपने लॉग का विश्लेषण करने के आधार पर, इनमें से हर एक के लिए सही अपवाद सबडोमेन की सूची भी बनाते हैं. अगर उन सर्वर से आने वाले जवाब में सही केस नहीं होता है, तो हम रिस्पॉन्स को अस्वीकार कर देते हैं. चालू किए गए नाम सर्वर, हमारे आउटबाउंड ट्रैफ़िक के 70% से ज़्यादा को हैंडल करते हैं.

क्वेरी के नामों के लिए गैर-ज़रूरी लेबल पहले से

अगर कोई रिज़ॉल्वर सीधे कैश मेमोरी से किसी नाम का समाधान नहीं कर पाता या सीधे किसी आधिकारिक नेम सर्वर से क्वेरी नहीं कर सकता, तो किसी रूट या टीएलडी नेम सर्वर से मिले रेफ़रल को फ़ॉलो करना ज़रूरी है. ज़्यादातर मामलों में, रूट या टीएलडी नेम सर्वर के अनुरोधों की वजह से, किसी दूसरे नेम सर्वर को रेफ़रल भेजा जाता है. इसके बजाय, आईपी पते पर नाम का समाधान करने की कोशिश नहीं की जाती. इसलिए, ऐसे अनुरोधों के लिए की गई नाम की क्वेरी को बढ़ाने के लिए, क्वेरी के नाम में रैंडम लेबल अटैच करना सुरक्षित होना चाहिए. साथ ही, इससे ऐसे नामों के समाधान में गड़बड़ी नहीं हो सकती जो मौजूद नहीं हैं. इसलिए, entriih-f10r3.www.google.com जैसे किसी बिना लेबल वाले नाम के रेफ़रिंग नाम सर्वर को अनुरोध भेजने पर, www.google.com के लिए वही नतीजा मिलेगा जो अनुरोध करने पर मिलता है.

हालांकि, व्यावहारिक तौर पर इस तरह के अनुरोधों में 3% से भी कम आउटगोइंग अनुरोध शामिल होते हैं. ऐसा मानते हुए कि ज़्यादातर क्वेरी का जवाब सीधे कैश मेमोरी से या किसी एक क्वेरी के ज़रिए दिया जा सकता है, फिर भी इस तरह के अनुरोध ही हमलावर होते हैं जो रिज़ॉल्वर को अपनी समस्या हल करने के लिए कहते हैं. इसलिए, कामिंस्की शैली में होने वाले विस्फोटों से बचने के लिए यह तकनीक बहुत असरदार साबित हो सकती है.

इस तकनीक को लागू करने के लिए, बिना लेबल वाले लेबल का इस्तेमाल सिर्फ़ उन अनुरोधों के लिए किया जाना चाहिए जिनके लिए रेफ़रल मिलने की गारंटी हो; इसका मतलब है कि वे जवाब जिनमें जवाब वाले सेक्शन में रिकॉर्ड शामिल न हों. हालांकि, ऐसे अनुरोधों का सेट तय करते समय हमें कई चुनौतियां मिली हैं:

  • कुछ देश कोड कोड वाले टीएलडी (ccTLD) नाम सर्वर, असल में दूसरे लेवल के टीएलडी (2LD) के लिए आधिकारिक होते हैं. हालांकि, इनके दो लेबल होते हैं, 2LD भी टीएलडी की तरह काम करते हैं. इसलिए, अक्सर ccTLD नाम सर्वर के ज़रिए इन्हें मैनेज किया जाता है. उदाहरण के लिए, .uk नाम सर्वर, mod.uk और nic.uk ज़ोन के लिए भी आधिकारिक होते हैं. इसलिए, उन ज़ोन में शामिल होस्टनेम, जैसे कि www.nic.uk और www.mod.uk के लिए भी अनुमति दी जाती है. दूसरे शब्दों में, इस तरह के होस्टनेम के समाधान के लिए, ccTLD के नाम सर्वर के अनुरोधों के लिए रेफ़रल नहीं दिए जाएंगे. हालांकि, इन अनुरोधों के जवाब आधिकारिक तौर पर दिए जाएंगे. ऐसे होस्टनेम पर गैर-ज़रूरी लेबल जोड़ने से, नामों को ठीक नहीं किया जा सकेगा.
  • कभी-कभी सामान्य टीएलडी (gTLD) नाम सर्वर, नाम सर्वर के लिए गैर-आधिकारिक तरीके से दिए गए जवाब दिखाते हैं. इसका मतलब है कि कुछ नेम सर्वर होस्टनेम अपने डोमेन के ज़ोन के बजाय, gTLD ज़ोन में रहते हैं. जीएटीएलडी इन होस्टनेम के लिए, गैर-आधिकारिक जवाब उपलब्ध कराएगा. हालांकि, यह बताने के लिए रेफ़रल का इस्तेमाल करने के बजाय इसके डेटाबेस में मौजूद ग्लू रिकॉर्ड का इस्तेमाल किया जाएगा. उदाहरण के लिए, ns3.indexonlineserver.com नाम का इस्तेमाल indexonlineserver.com ज़ोन के बजाय, .COM gTLD ज़ोन में किया जाता था. जब हमने n3.indexonlineserver.com के लिए gTLD सर्वर का अनुरोध किया था, तब हमें रेफ़रल के बजाय उस डोमेन का आईपी पता मिला था. हालांकि, अगर हमने बिना लेबल वाले लेबल को पहले जोड़ा है, तो हमें indexonlineserver.com का रेफ़रल मिलेगा. यह रेफ़रल उस होस्टनेम को ठीक नहीं कर सका. इसलिए, हम ऐसे नाम सर्वर के लिए नॉन-लेबल नहीं जोड़ सकते जिनके लिए किसी gTLD सर्वर से रिज़ॉल्यूशन की ज़रूरत होती है.
  • ज़ोन और होस्टनेम के अधिकार, समय के साथ बदलते रहते हैं. इस वजह से, ऐसा होस्टनेम पहले से नहीं जोड़ा जा सकता जिसे एक बार, डेलिगेशन चेन में बदलाव होने पर ठीक नहीं किया जा सकता.

इन चुनौतियों का सामना करने के लिए, हमने उन होस्टनेम के लिए अपवाद कॉन्फ़िगर किए हैं जिनके लिए हम नॉन-लेबल नहीं जोड़ सकते. ये होस्टनेम हैं, जिनके लिए टीएलडी नेम सर्वर बिना रिस्पॉन्स वाले रिस्पॉन्स दिखाते हैं. हम अपवादों की सूची की लगातार समीक्षा करते रहते हैं, ताकि यह पक्का हो सके कि समय के साथ यह मान्य बनी रहे.

डुप्लीकेट क्वेरी हटाना

डीएनएस रिज़ॉल्वर, "जन्मदिन के हमलों" के लिए जोखिम की संभावना होते हैं. इसलिए, इन्हें गणित और कोटेशन का फ़ायदा उठाने के लिए कहा जाता है, जिसमें जन्मदिन की गड़बड़ी और कोटेशन का इस्तेमाल होता है. ऐसे में, मैच की संभावना के लिए बहुत ज़्यादा इनपुट की ज़रूरत नहीं होती है. जन्मदिन के हमलों में पीड़ित सर्वर पर न सिर्फ़ फ़र्ज़ी तरीके से जवाब दिए जाते हैं, बल्कि शुरुआती क्वेरी के साथ-साथ उस समस्या को सुलझाने के लिए रिज़ॉल्वर की गिनती भी की जाती है, जिसमें एक ही नाम वाले कई अनुरोध शामिल होते हैं. किए गए आउटगोइंग अनुरोधों की संख्या जितनी ज़्यादा होगी, हमलावर के उन अनुरोधों में से किसी एक को नकली जवाब के साथ मिलाने की संभावना उतनी ही ज़्यादा होगी: किसी हमलावर को सिर्फ़ 50% सफल होने के लिए 300 इन-फ़्लाइट अनुरोधों के क्रम की ज़रूरत होगी.

इस हमले की रणनीति से बचने के लिए, आपको आउटबाउंड सूची से सभी डुप्लीकेट क्वेरी हटानी होंगी. उदाहरण के लिए, Google की सार्वजनिक डीएनएस सेवा, एक ही क्वेरी के नाम, क्वेरी के टाइप, और डेस्टिनेशन आईपी पते के लिए, एक से ज़्यादा बकाया अनुरोधों की अनुमति कभी नहीं देती.

रेट को सीमित करने वाली क्वेरी

सेवा में रुकावट के हमलों को रोकने से, बार-बार होने वाले डीएनएस डीएनएस रिज़ॉल्वर के लिए कई खास चुनौतियां सामने आती हैं:

  • बार-बार होने वाले रिज़ॉल्वर का दायरा बढ़ाने के लिए, वे बार-बार ध्यान खींचने की कोशिश करते हैं. ये सर्वर की क्षमता, ज़्यादा भरोसे वाले सर्वर होते हैं और ये किसी सामान्य आधिकारिक सर्वर से ज़्यादा बड़े रिस्पॉन्स दे सकते हैं—खास तौर पर तब, जब हमला करने वाला व्यक्ति अपनी कैश मेमोरी में बड़ा रिस्पॉन्स दे सकता है. यह ओपन डीएनएस सेवा के किसी भी डेवलपर के लिए ज़िम्मेदार है, ताकि वह अपने सर्वर को अन्य सिस्टम पर हमले होने से रोक सके.
  • एम्प्लिकेशन अटैक के होने पर, उनका पता लगाना मुश्किल हो सकता है. हमलावर, हज़ारों रिज़ॉल्वर के ज़रिए किसी तरह का हमला कर सकते हैं, ताकि हर समाधान में क्वेरी का कम ही हिस्सा दिखे. साथ ही, यह भी साफ़ तौर पर पता न चले कि उससे छेड़छाड़ की गई है.
  • नुकसान पहुंचाने वाले ट्रैफ़िक को सामान्य उपयोगकर्ताओं के लिए डीएनएस सेवा में किसी तरह की रुकावट या रुकावट के बिना ब्लॉक नहीं किया जाना चाहिए. डीएनएस एक ज़रूरी नेटवर्क सेवा है. इसलिए, किसी हमले के लिए सर्वर को बंद करना कोई विकल्प नहीं है. साथ ही, बहुत ज़्यादा समय तक किसी क्लाइंट के आईपी को सेवा देने से मना नहीं किया जा सकता है. रिज़ॉल्वर को किसी हमले के शुरू होते ही तुरंत उसे ब्लॉक करने और हमला खत्म होते ही बहाल करने की पूरी सेवा देनी चाहिए.

'डीओएस' से होने वाले हमलों से निपटने का सबसे अच्छा तरीका है, पेजों की संख्या सीमित करना या थ्रेटलिंग &कोटेशन करना. Google की सार्वजनिक डीएनएस सेवा, दो तरह के रेट कंट्रोल लागू करती है:

  • किए जाने वाले अनुरोधों के लिए, दूसरे नेम सर्वर पर कंट्रोल. अन्य 'डीएनएस नाम सर्वर' को DoS हमलों से बचाने के लिए जो हमारे रिज़ॉल्वर सर्वर से लॉन्च किए जा सकते हैं, Google की सार्वजनिक डीएनएस सेवा, हर नाम सर्वर आईपी पते के लिए, सेवा देने वाले हर क्लस्टर के आउटगोइंग अनुरोधों पर क्यूपीएस की सीमा लागू करती है.

  • क्लाइंट को जाने वाले जवाब देने की दर को कंट्रोल करें. एम्प्लफ़िकेशन और पारंपरिक डिस्ट्रिब्यूटेड डीओएस (बॉटनेट) अटैक से किसी भी दूसरे सिस्टम को बचाने के लिए, Google की सार्वजनिक डीएनएस टीम, क्लाइंट की क्वेरी के आधार पर दो तरह के रेट सीमित करती है:

    • पारंपरिक वॉल्यूम-आधारित हमलों से सुरक्षा के लिए, हर सर्वर पर हर क्लाइंट-आईपी क्यूपीएस और औसत बैंडविड्थ सीमाएं लागू होती हैं.
    • एम्प्लफ़िकेशन हमलों से बचने के लिए, जिसमें हर क्वेरी का कम से कम इस्तेमाल किया जाता है, हर सर्वर के लिए अलग-अलग क्लाइंट और आईपी पते का इस्तेमाल किया जा सकता है. औसत एम्प्लफ़िकेशन फ़ैक्टर, रिस्पॉन्स-टू-क्वेरी साइज़ का कॉन्फ़िगर किया जा सकने वाला अनुपात है. इसे हमारे सर्वर लॉग में निगरानी किए जाने वाले पुराने ट्रैफ़िक पैटर्न से तय किया जाता है.

    अगर एक स्रोत आईपी पते से मिलने वाली डीएनएस क्वेरी की संख्या सबसे ज़्यादा क्यूपीएस दर से ज़्यादा होती है, तो ज़्यादा क्वेरी छोड़ दी जाएंगी. अगर एक स्रोत आईपी पते से यूडीपी पर डीएनएस क्वेरी, औसत बैंडविड्थ या एम्प्लफ़िकेशन की सीमा से लगातार बढ़ती हैं (कभी-कभी बड़ा रिस्पॉन्स पास होगा), तो क्वेरी कम की जा सकती हैं या सिर्फ़ एक छोटा जवाब भेजा जा सकता है. छोटे रिस्पॉन्स, किसी गड़बड़ी का जवाब हो सकते हैं या उनमें कोई छोटा सा जवाब हो सकता है. इसमें, काट-छांट करने वाले बिट का सेट शामिल होता है , ताकि टीसीपी की मदद से, सबसे सही क्वेरी बार-बार कोशिश की जा सकें. सभी सिस्टम या प्रोग्राम टीसीपी की मदद से दोबारा कोशिश नहीं करेंगे. साथ ही, टीसीपी पर डीएनएस को क्लाइंट-साइड पर फ़ायरवॉल से ब्लॉक किया जा सकता है. इसलिए, जवाब दिए जाने पर, कुछ ऐप्लिकेशन सही तरीके से काम नहीं कर पाएंगे. फिर भी, काट-छांट करने से, ज़्यादातर मामलों में RFC का पालन करने वाले क्लाइंट को सही तरीके से काम करने की सुविधा मिल जाती है.

  1. उदाहरणों के लिए, डीएनएस ऐम्प्लिकेशन अटैक पेपर और सामान्य तौर पर समस्या के बारे में अच्छी चर्चा करें.↩

  2. आरएफ़सी 1034, सेक्शन 3.5 के मुताबिक: ↩

    ध्यान दें कि डोमेन नेम में अपर और लोअर केस के अक्षर इस्तेमाल करने की अनुमति होती है, लेकिन केस में कोई अहमियत नहीं होती. इसका मतलब यह है कि एक ही वर्तनी वाले दो नामों को अलग-अलग केस माना जाता है.