क्या DNS क्वेश्चन हमेशा UDP से अधिक यात्रा करते हैं?


33

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

अनिवार्य रूप से, DNS क्वेश्चन कभी टीसीपी का उपयोग करते हैं (यदि हां, तो यह किस परिदृश्य में हो सकता है)? फिर से, मैं केवल प्रश्नों के बारे में बात कर रहा हूँ। क्या उनके लिए टीसीपी पर यात्रा करना संभव है? यदि डोमेन लंबाई में केवल अधिकतम 253 बाइट्स हो सकते हैं, और यूडीपी पैकेट 512 बाइट्स के रूप में बड़े हो सकते हैं, तो क्या हमेशा यूडीपी के रूप में प्रश्न नहीं निकलेंगे? मुझे नहीं लगता था कि टीसीपी के उपयोग की आवश्यकता के लिए एक resolvable क्वेरी काफी बड़ी हो सकती है। यदि किसी DNS सर्वर को कभी भी 253 बाइट्स से बड़े डोमेन के लिए अनुरोध मिला है, तो क्या सर्वर इसे छोड़ देगा / कोशिश नहीं करेगा और इसे हल करेगा? मुझे यकीन है कि मैंने यहाँ कुछ गलत धारणाएँ बनाई हैं।

कुछ संदर्भों के लिए, मैं सुरक्षा समूहों के साथ उनके सुरक्षा निगरानी उपकरण में DNS प्रश्नों को ऑनबोर्ड करने के लिए काम कर रहा हूं, और विभिन्न कारणों से हमने तय किया है कि हम DNS सर्वर और डोमेन नियंत्रकों पर मानक पैकेट कैप्चर के माध्यम से इस ट्रैफ़िक को कैप्चर करेंगे। मुख्य आवश्यकता सभी DNS प्रश्नों को कैप्चर करना है ताकि वे किसी भी डोमेन को हल करने के लिए क्लाइंट द्वारा किए गए प्रयास की पहचान कर सकें। इस आवश्यकता के आधार पर, हम DNS प्रतिक्रियाओं या ज़ोन स्थानांतरण जैसे अन्य ट्रैफ़िक को कैप्चर करने से चिंतित नहीं हैं, जो इस तथ्य से भी प्रेरित है कि हमें लॉग वॉल्यूम को यथासंभव सीमित करने की आवश्यकता है। जैसे, हम केवल DNS सर्वरों के लिए नियत DNS प्रश्नों को कैप्चर करने और UDP पर भेजे जाने की योजना बना रहे हैं। अधिक सन्दर्भ के लिए (यहाँ प्रश्न की तरह रेंगना), अब यह लाया गया है कि हमें सुरक्षा का विस्तार करने की आवश्यकता हो सकती है ' दृश्यता इसलिए वे DNS पर चलने वाले गुप्त चैनलों जैसी गतिविधि के लिए निगरानी कर सकते हैं (जो DNS प्रतिक्रियाओं को भी पकड़ने की आवश्यकता होगी, और बाद में टीसीपी ट्रैफ़िक)। लेकिन उस प्रकार के परिदृश्य में भी, मुझे लगा कि कोई भी आउटबाउंड DNS ट्रैफ़िक लुकअप / क्वेरीज़ के रूप में होगा, और ये हमेशा UDP से अधिक होगा, भले ही एक दुर्भावनापूर्ण स्रोत से (पहले पैराग्राफ में मेरे तर्क के कारण)। तो इससे कुछ अतिरिक्त प्रश्न सामने आते हैं:

  • क्या हम कम से कम मेरे द्वारा बताए गए दृष्टिकोण के साथ बातचीत के आधे हिस्से पर कब्जा कर लेंगे? या कभी कोई क्लाइंट DNS ट्रैफ़िक को भेजेगा जो क्वेरी के रूप में नहीं है? (शायद DNS सर्वर की प्रतिक्रिया के लिए किसी प्रकार का उत्तर, और शायद टीसीपी से बाहर जाना समाप्त हो सकता है)

  • क्या टीसीपी का उपयोग करने के लिए DNS प्रश्नों को संशोधित किया जा सकता है? क्या एक DNS सर्वर टीसीपी पर आने वाली DNS क्वेरी को स्वीकार और जवाब देगा?

यह सुनिश्चित नहीं है कि यह प्रासंगिक है, लेकिन हम DNS अनुरोधों को अधिकृत DNS सर्वरों तक सीमित करते हैं और पोर्ट 53 पर अन्य सभी ट्रैफ़िक को बाहर जाने से रोकते हैं। मैं निश्चित रूप से एक धोखेबाज़ हूं, इसलिए मुझे खेद है कि अगर मेरा प्रश्न आज्ञाकारी नहीं है, और मुझे बताएं मुझे कैसे संशोधित करना चाहिए।


2
पेजिंग @Alnitak, हम आपके बच्चे के बारे में चर्चा कर रहे हैं। :)
एंड्रयू बी

मैं TCP मोड में काम करने के लिए डिफ़ॉल्ट DNS क्वेरी को कैसे बाध्य कर सकता हूं? । हालाँकि कुछ मोड्स के साथ OS X / macOS q / यह लिनक्स / विंडोज के लिए भी काम करता है।
कालोनोमथ

बेशक आजकल HTTPS पर DNS और TLS पर DNS के साथ और जल्द ही DNS पर QUIC ...
पैट्रिक मेवज़ेक

अपनी पसंद के सभी DNS प्रश्नों (क) डीएनएस सर्वर (नों) को पुनर्निर्देशित क्यों नहीं किया जाता?
क्रेग हिक्स

जवाबों:


38

सामान्य DNS क्वेरीज़ UDP पोर्ट 53 का उपयोग करती हैं, लेकिन अब क्वेरीज़ (> 512 ओकटेट्स) को 'छोटा' उत्तर मिलेगा, जिसके परिणामस्वरूप संपूर्ण क्वेरी भेजने / प्राप्त करने की सुविधा के लिए TCP 53 वार्तालाप में परिणाम होगा। साथ ही, DNS सर्वर 53 पोर्ट को बांधता है, लेकिन क्वेरी स्वयं एक उच्च-क्रमांकित पोर्ट (49152 या इसके बाद के संस्करण) को पोर्ट 53 पर भेजी जाती है। प्रतिक्रिया पोर्ट 53 से इसी पोर्ट पर वापस आ जाएगी।

DNS द्वारा उपयोग किए जाने वाले नेटवर्क पोर्ट | Microsoft डॉक्स

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

गैर-लुकअप ट्रैफ़िक के लिए, इस बात पर विचार करें कि नए रिकॉर्ड्स के साथ अन्य DNS सर्वरों को अपडेट करने के लिए DNS ज़ोन ट्रांसफ़र (क्वेरी टाइप AXFR) का भी उपयोग करता है। मध्य हमले में एक आदमी इस तरह के हस्तांतरण के साथ शुरू कर सकता है, एक प्राथमिक नाम सर्वर को डीडीओएस कर रहा है ताकि यह अद्यतन रिकॉर्ड के लिए माध्यमिक से जवाब देने में बहुत व्यस्त हो। हैकर तब माध्यमिक को 'जहर' रिकॉर्ड खिलाने के लिए उसी प्राथमिक को खराब कर देता है, जो कि लोकप्रिय DNS डोमेन से छेड़छाड़ करने वाले मेजबानों को पुनर्निर्देशित करता है।

इसलिए आपके सुरक्षा ऑडिट को क्वेरी प्रकार AXFR पर पूरा ध्यान देना चाहिए, और आपके DNS सिस्टम को केवल विशिष्ट IP पतों से AXFR एक्सचेंजों को स्वीकार करना चाहिए।

SANS Institute InfoSec रीडिंग रूम | sans.org


1
धन्यवाद जॉर्ज, वास्तव में उपयोगी सामान! तो अपने पहले वाक्य पर जल्दी से स्पष्ट करने के लिए - एक यूडीपी पैकेट केवल 512 बाइट्स फिट हो सकता है, है ना? इसलिए यदि DNS क्वेरी 512 से बड़ी थी, तो क्या यह गेट के ठीक बाहर टीसीपी पर शुरू नहीं होगी? मैंने खुद को वायरशर्क चलाने और बड़े डोमेन को हल करने के लिए nslookup का उपयोग करके यह परीक्षण करने की कोशिश की, लेकिन यह मुझे 200 वर्णों से बड़े डोमेन की कोशिश करने से रोकता है (सटीक संख्या नहीं है, लेकिन बिंदु यह है कि मैं इस परिदृश्य का पूरी तरह से परीक्षण नहीं कर सकता) ।
कैडरेड

3
यह "क्वेरी" नहीं है, लेकिन "प्रतिक्रिया" जो 512Bytes से अधिक होगी और क्लाइंट को पता नहीं होगा कि "प्रतिक्रिया" क्या होगी।
AbraCadaver

7
@ कैडरेड हां, आप सही हैं कि वे टीसीपी या यूडीपी हो सकते हैं, हालांकि केवल जोन ट्रांसफर टीसीपी के रूप में शुरू होंगे। क्लाइंट क्वेरीज़ यूडीपी होगी जब तक कि उन्हें उस सर्वर से प्रतिक्रिया नहीं मिलती है जिसमें ट्रंकट बिट सेट है। फिर टीसीपी का उपयोग कर सकते हैं।
AbraCadaver

1
क्या ग्राहक वैसे भी छोटी प्रतिक्रियाओं के लिए टीसीपी का उपयोग कर सकते हैं?
मेहरदाद

2
"एक यूडीपी पैकेट केवल 512 बाइट्स फिट कर सकता है" नहीं, यह धारणा है कि क्लाइंट का बफर केवल 512 बाइट्स फिट कर सकता है जो सर्वर को इस तरह से व्यवहार करने का कारण बनता है। EDNS का उपयोग करके सर्वर को एक लंबे बफर के बारे में सूचित किया जा सकता है।
ब्रायन

28

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

  • RFC 1035 मूल रूप से UDP विखंडन से बचने के लिए 512 बाइट्स की सीमा के लिए कहा जाता है। डीएनएस लेनदेन के ओवरहेड को कम करने के लिए खंडित यूडीपी डेटाग्राम और टीसीपी को अंतिम उपाय के विकल्प के रूप में चुना गया था। ज़ोन ट्रांसफ़र हमेशा TCP का उपयोग करते हैं, ज़ोन ट्रांसफ़र के कारण> 512 बाइट्स उनके स्वभाव से। (यह यूडीपी के साथ शुरू करने के लिए बैंडविड्थ की बर्बादी होगी)

  • ट्रंकेशन पर टीसीपी पुनर्प्रयास व्यापक रूप से समर्थित है क्योंकि यह 1989 से आरएफसी 1123 में निर्दिष्ट किया गया है ।

  • EDNS (0) को RFC 6891 (2013) द्वारा परिभाषित किया गया है , और इससे पहले 1999 तक एक प्रस्तावित मानक डेटिंग के रूप में अस्तित्व में था । यह एक ऐसे तंत्र को परिभाषित करता है जहां क्लाइंट और सर्वर 512 से अधिक यूडीपी आकार पर बातचीत कर सकते हैं। EDNS (0) के नएपन के कारण, कई हार्डवेयर उपकरण DNS पैकेटों की संरचना के बारे में धारणा बनाते हैं, जो आज्ञाकारी पैकेट को त्यागने का कारण बनते हैं। सबसे अक्सर कारण एक धारणा है कि 512 बाइट्स के डीएनएस संदेश अमान्य हैं, लेकिन यह कई में से एक है।

यदि हम देखे गए व्यवहार को तोड़ते हैं:

  1. DNS प्रश्न आमतौर पर यूडीपी के रूप में शुरू होते हैं, जब तक कि यह समय से पहले नहीं जाना जाता है कि उत्तर को शुरू करने के लिए बहुत बड़ा होगा। (जोन स्थानांतरण)
  2. जबाब सकता है अगर एक छोटा कर दिया जबाब देखा जाता है क्लाइंट में एक टीसीपी पुन: प्रयास करें ट्रिगर। यह काफी अच्छी तरह से समर्थित है।
  3. 512 बाइट्स से अधिक का यूडीपी उत्तर देखा जा सकता है यदि क्लाइंट ने बड़े पेलोड को विज्ञापित करने के लिए EDNS (0) का उपयोग किया है, और प्राप्त सर्वर इसका समर्थन करता है। यह केवल तभी होगा जब दोनों के बीच बैठा हार्डवेयर हस्तक्षेप न करे और परिणामस्वरूप गिरा या गिरा हुआ पैकेट प्राप्त करे।
  4. यदि कोई उत्तर नहीं देखा जाता है, तो ग्राहक एक छोटे विज्ञापित पेलोड के साथ EDNS (0) क्वेरी को पुनः प्राप्त करने का चुनाव कर सकता है, लेकिन कार्यान्वयन के बीच विवरण अलग-अलग होंगे।
    • यह नोट करना महत्वपूर्ण है कि जो उत्तर आखिरकार बनाता है वह अनुरोधित आकार में फिट होने के लिए बहुत बड़ा हो सकता है, जिसके परिणामस्वरूप व्यवहार # 2 ऊपर होता है। (तु ओल्ड टीसीपी रिट्री)
    • क्लाइंट पक्ष उस आकार को याद रखने का विकल्प चुन सकता है जिसके परिणामस्वरूप आखिरकार सफलता मिली। यह इसे फिर से बाहर निकालने के लिए अनावश्यक प्रश्नों को बर्बाद करने से बचने की अनुमति देता है। अन्यथा करने के लिए काफी बेकार होगा, खासकर अगर अंतिम परिणाम के लिए टीसीपी की वापसी आवश्यक हो।

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


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

कनेक्शन का पुन: उपयोग: इसलिए अपने रिज़ॉल्वर को पहले google.com के लिए पूछें, इससे पहले कि वह scantycladladies.com से पूछें, तो dnscap नोटिस नहीं करता है। ;-)
लीन

6

वहाँ है आरएफसी 7766, टीसीपी से अधिक DNS परिवहन - कार्यान्वयन आवश्यकताओं

  1. परिचय

अधिकांश DNS [ RFC1034 ] लेनदेन UDP [ RFC768 ] से अधिक होते हैं। TCP [ RFC793 ] का उपयोग हमेशा पूर्ण क्षेत्र स्थानांतरण (AXFR का उपयोग करके) के लिए किया जाता है और अक्सर उन संदेशों के लिए उपयोग किया जाता है, जिनका आकार DNS प्रोटोकॉल की मूल 512-बाइट सीमा से अधिक होता है। डीएनएस सिक्योरिटी (डीएनएसएसईसी) और आईपीवी 6 की बढ़ती तैनाती ने प्रतिक्रिया के आकार में वृद्धि की है और इसलिए टीसीपी का उपयोग होता है। बढ़ी हुई टीसीपी उपयोग की आवश्यकता को भी सुरक्षा द्वारा संचालित किया गया है, जो पता बिगाड़ने और अतः प्रतिबिंब / प्रवर्धन हमलों में DNS के शोषण के खिलाफ प्रदान करता है। अब इसका व्यापक रूप से रिस्पॉन्स रेट लिमिटिंग [ RRL1 ] [ RRL2 ] में उपयोग किया जाता है । इसके अतिरिक्त, हाल ही में DNS गोपनीयता समाधानों पर काम करते हैं जैसे कि [ DNS-over-TLS] डीएनएस-ओवर-टीसीपी आवश्यकताओं को फिर से शुरू करने के लिए एक और प्रेरणा है।

[RFC1123] राज्यों की धारा 6.1.3.2 :

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

हालांकि, कुछ कार्यान्वयनकर्ताओं ने ऊपर उद्धृत पाठ का मतलब यह निकाला है कि टीसीपी समर्थन डीएनएस प्रोटोकॉल की एक वैकल्पिक विशेषता है।

डीएनएस सर्वर ऑपरेटरों के बहुमत पहले से ही टीसीपी का समर्थन करते हैं, और अधिकांश सॉफ्टवेयर कार्यान्वयन के लिए डिफ़ॉल्ट कॉन्फ़िगरेशन टीसीपी का समर्थन करना है। इस दस्तावेज़ के लिए प्राथमिक दर्शक वे कार्यान्वयनकर्ता हैं जिनकी टीसीपी के लिए सीमित समर्थन अंतर को सीमित करता है और नई DNS सुविधाओं की तैनाती में बाधा उत्पन्न करता है।

इसलिए यह दस्तावेज़ कोर DNS प्रोटोकॉल विशिष्टताओं को अद्यतन करता है, जैसे कि टीसीपी के लिए समर्थन इसलिए पूर्ण DNS प्रोटोकॉल कार्यान्वयन का आवश्यक हिस्सा है।

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

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


2
हे रॉन - मैंने वास्तव में पोस्ट करने से पहले RFC पढ़ा था, लेकिन उदाहरण के लिए, यदि आप पहले पैराग्राफ में देखते हैं, तो यह जोर देता है कि टीसीपी को बड़ी प्रतिक्रियाओं का समर्थन करने की आवश्यकता है - "DNS सुरक्षा (DNSSEC) और IPv6 की बढ़ती तैनाती प्रतिक्रिया आकार में वृद्धि हुई है और इसलिए टीसीपी का उपयोग "। फिर से, मेरा सवाल प्रश्नों के बारे में था, लेकिन धन्यवाद वैसे भी।
कैडरेड

4
RFC यह बिलकुल स्पष्ट करता है कि DNS के लिए TCP का समर्थन किया जाना आवश्यक है, और यह ग्राहकों द्वारा TCP के उपयोग पर चर्चा करता है। उदाहरण के लिए, " DNS के लिए टीसीपी का उपयोग करने वाले ग्राहकों को कनेक्शनों को फिर से स्थापित करने या अन्यथा बकाया प्रश्नों को वापस लेने के लिए हमेशा तैयार रहने की जरूरत है। "
रॉन मूपिन

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

1
INTERNET STANDARDआरएफसी है tools.ietf.org/html/rfc1034 । आप PROPOSED STANDARDटीसीपी की आवश्यकता के लिए उद्धृत कर रहे हैं ।
AbraCadaver

3
यह एक मानक ट्रैक RFC है जिसने पिछले मानक ट्रैक RFC को उसी चीज़ के बारे में अद्यतन किया है। सर्वर फाल्ट पर यहां यह जवाब ऐसी बातें बताता है। यहां तक ​​कि आपके द्वारा संदर्भित दस्तावेज़ में भी, यह कहा गया है, " इंटरनेट में, यूडीपी डेटाग्राम या टीसीपी कनेक्शन पर प्रश्न किए जाते हैं। " आरएफसी 7766 यह स्पष्ट करना है कि टीसीपी, डीएनएस के भाग के बजाय वैकल्पिक है।
रॉन मौपिन

3

आपको किसी भी दिशा में टीसीपी / 53 को फ़िल्टर नहीं करना चाहिए। उदाहरण के लिए, nsupdateजैसे ही अनुरोध बहुत बड़ा हो (जो तेजी से हो सकता है) क्वेरीज़ टीसीपी का उपयोग कर सकती है। तो आपको UDP और TCP को पोर्ट 53 (IPv4 & V6!) में सभी दिशाओं में प्रवाहित करने देना चाहिए।

इसके अलावा टीएलएस पर डीएनएस की ओर अधिक से अधिक काम है, इसलिए टीसीपी को दोनों दिशाओं में आवश्यक होगा। RFC7858 देखें।


प्रश्न का फ़िल्टर करने से कोई लेना-देना नहीं है, और आपका उत्तर अन्य उत्तरों पर कुछ नहीं जोड़ता है
ब्रायन

@Bryan आपकी बहुत उपयोगी और उपयोगी टिप्पणी के लिए धन्यवाद!
पैट्रिक मेव्ज़ेक

@PatrickMevzek अंडरस्टूड - जो मैं कहने की कोशिश कर रहा था वह है कि हम केवल पोर्ट 53 से अधिक की परिधि से परे विशिष्ट आईपी पते पर ट्रैफिक की अनुमति दें (टीसीपी और यूडीपी को अनुमति दी जाती है)।
कैडरेड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.