क्या यह सच है कि एक नामवर को टीसीपी पर प्रश्नों का उत्तर देना होगा?


23

मैं कई बड़े वेब होस्टों के DNS सर्वरों की निगरानी स्थापित करने की प्रक्रिया कर रहा हूँ। मेरा लक्ष्य पिंग के प्रति उनकी प्रतिक्रिया को ट्रैक करके उनके डीएनएस सर्वर प्रतिक्रिया समय की तुलना करना है।

इस प्रक्रिया में, मुझे पता चला कि ब्लूहोस्ट नेमसर्वर्स पिंग का जवाब नहीं देते हैं। मैंने Bluehost.com पर PWOOD DNS Check चलाकर अधिक जानकारी प्राप्त करने का प्रयास किया और इसने निम्नलिखित त्रुटि उत्पन्न की:

नाम सर्वर ns1.bluehost.com (74.220.195.31) टीसीपी पर प्रश्नों का उत्तर नहीं देता है।

नाम सर्वर टीसीपी पर भेजे गए प्रश्नों का उत्तर देने में विफल रहा। यह संभवत: नाम सर्वर के ठीक से सेट न होने के कारण या किसी फ़ायरवॉल में गलत फ़िल्टरिंग के कारण होता है। यह एक सामान्य गलत धारणा है कि जब तक वे ज़ोन स्थानांतरण प्रदान नहीं करते हैं, तब तक DNS को टीसीपी की आवश्यकता नहीं होती है - शायद नाम सर्वर व्यवस्थापक को यह पता नहीं है कि टीसीपी आमतौर पर एक आवश्यकता है।

मैं निम्नलिखित जानना चाहूंगा:

  • उपरोक्त कथन किस हद तक सही है?
  • टीसीपी पर प्रश्नों का उत्तर नहीं देने वाले एक नेमवेसर के निहितार्थ क्या हैं?

जवाबों:


47

Phatt से डायग्नोस्टिक टेक्स्ट बिल्कुल सही है। टीसीपी सिर्फ जोन ट्रांसफर के लिए नहीं है

DNS सर्वर कार्यान्वयन कर रहे हैं अब टीसीपी, प्रति समर्थन करने के लिए "आवश्यक" (इतना किसी RFC कुछ भी आवश्यकता है, क्योंकि में) आरएफसी 5966 "- कार्यान्वयन आवश्यकताओं के टीसीपी से अधिक DNS परिवहन"।

ध्यान दें कि यह सर्वर सॉफ़्टवेयर कार्यान्वयन पर एक आवश्यकता है, यह किसी भी सर्वर के संचालन पर सख्ती से लागू नहीं होता है - परिचालन अभ्यास को कवर नहीं किया जाता है।

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

अस्वीकरण: मैंने लिखा है कि RFC।

EDIT RFC 5966 को अब RFC 7766 से बदल दिया गया है


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

3

इसे टीसीपी और यूडीपी का समर्थन करना चाहिए - टीसीपी प्रतिक्रियाओं के आकार के लिए है> 512 बाइट्स (जिसमें ज़ोन ट्रांसफर शामिल होगा) (सामान के अनुसार मैंने पढ़ा है, वैसे भी। मैं आमतौर पर एनएसपी के लिए टीसीपी और यूडीपी को सक्षम करता हूं ...)


-2

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

http://cr.yp.to/djbdns/tcp.html#why (2003-01-16)

टीसीपी प्रश्न कब भेजे जाते हैं?

यदि आप निम्न स्थितियों में से एक हैं, तो आपको टीसीपी प्रश्नों का उत्तर देने के लिए अपने DNS सर्वर को कॉन्फ़िगर करने की आवश्यकता है:

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

यदि आप उन स्थितियों में से किसी में नहीं हैं, तो आपको टीसीपी सेवा प्रदान करने की कोई आवश्यकता नहीं है, और आपको इसे सेट नहीं करना चाहिए। DNS-over-TCP, DNS-over-UDP की तुलना में बहुत धीमी है और स्वाभाविक रूप से इनकार करने वाली सेवा के हमलों के लिए अधिक कमजोर है। (यह BIND पर भी लागू होता है।)

ध्यान दें कि वह DNSSEC का स्पष्ट उल्लेख छोड़ देता है; कारण यह है कि, डीजेबी के अनुसार, DNSSEC "हमेशा एक गलती" श्रेणी में आता है। अधिक जानकारी के लिए https://cr.yp.to/djbdns/forgery.html देखें । डीजेबी का एक वैकल्पिक मानक है, जिसे DNSCurve कहा जाता है - http://dnscurve.org/ - जो पहले से ही कुछ प्रदाताओं (जैसे OpenDNS) द्वारा स्वतंत्र रूप से अपनाया गया है। ब्याज की: /security/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption

ध्यान दें कि यदि DJBDNS सेटअप पर उपरोक्त प्रलेखन इसकी विशेषताओं का कोई संकेत है, तो ऐसा प्रतीत होता है कि यह केवल TCP के लिए AXFR का समर्थन करता है। चूंकि कई प्रदाता अभी भी डीजेबीडीएनएस का उपयोग करते हैं, इसलिए वे अतिरिक्त प्रयासों के बिना टीसीपी पर डीएनएस का समर्थन करने की संभावना नहीं रखते हैं।

पीएस ध्यान दें कि डीजेबी वास्तव में, जो वह प्रचार करता है उसका अभ्यास करता है। उसके अपने सर्वर, (1), DNSCurve चलाते हैं, (2), ठीक से टीसीपी का जवाब नहीं देते हैं। केवल वही +notcpसफल होगा (जो डिफ़ॉल्ट है):

% dig +trace @ordns.he.net +notcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to.
yp.to.                  86400   IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 151 ms

cr.yp.to.               600     IN      A       131.155.70.11
cr.yp.to.               600     IN      A       131.155.70.13
yp.to.                  3600    IN      NS      uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to.
yp.to.                  3600    IN      NS      uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.yp.to.
;; Received 244 bytes from 131.155.70.13#53(uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to) in 14 ms

, जबकि +tcpविफल हो जाएगा (जाहिर है एक अलग त्रुटि संदेश के साथ, जो उसके सर्वरों के चयन पर निर्भर करता है):

% dig +trace @ordns.he.net +tcp cr.yp.to | tail
yp.to.                  86400   IN      NS      uz5hjgptn63q5qlch6xlrw63tf6vhvvu6mjwn0s31buw1lhmlk14kd.ns.yp.to.
;; Received 300 bytes from 216.74.32.100#53(tonic.to) in 150 ms

;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.155.70.13#53: end of file
;; Connection to 131.155.71.143#53(uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to) for cr.yp.to failed: connection refused.
;; communications error to 131.193.32.147#53: end of file
;; connection timed out; no servers could be reached

2
आपका डीजेबी फैनबोय अभिनय पहनने के बजाय हो रहा है। DNS समुदाय ने DNSSEC को चुना है, और DNSCurve के बारे में अधिकांश साहित्य पूरी तरह से डेटा की प्रामाणिकता और डेटा की एन्क्रिप्शन की ऑर्थोगोनल आवश्यकताओं को बताता है । IMNSHO, आपके उत्तर का थोक इस प्रश्न के लिए कुछ भी नहीं योगदान देता है ।
अलनीतक

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

2
क्या वह दस्तावेज वास्तव में 2003 से है? आप सीधे चेहरे के साथ कैसे दावा कर सकते हैं कि यह 2017 में अभी भी प्रासंगिक है?
माइकल हैम्पटन

1
@Michael Hampton, हाँ, तहे दिल से और बिल्कुल। कुछ चीजें नहीं बदलती हैं, और डीजेबी एक गधे के रूप में हो सकता है, लेकिन वह उस पर एक बहुत चालाक है। सभी तर्क वह प्रस्तुत करते हैं जो प्रकृति में दार्शनिक हैं, और प्रौद्योगिकी के रूप में नहीं बदलते हैं। इस बीच, (1), यह विश्वास करना इतना कठिन क्यों है, (2), एक सीधे चेहरे के साथ किए गए पुराने RFC को भी क्यों लिंक कर रहा है, और आपके बिना एक पाखंडी होने के नाते, (3), आप किस वास्तविक प्रतिवाद से इतर हैं? एक तिथि"? लोग यह कहते रहते हैं कि उनके रास्ते में अंतर समस्याएँ हैं, फिर भी बहुत तर्क दिए जा रहे हैं (जैसे, बाउंस किए गए मेल) उन्होंने 2003 में वापस डेब्यू किया!
cnst

-5

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

हस्ताक्षरित डीएनएस उत्तरों की शुरुआत के साथ, यूपीडी उत्तरों के लिए 512 बाइट सीमा को ढीला करने की आवश्यकता होती है। EDNS0 अब UDP प्रतिक्रियाओं के लिए तंत्र प्रदान करता है। टीसीपी पर डीएनएस की अनुमति देने में विफलता एक सुरक्षित डीएनएस कार्यान्वयन को तोड़ने की अत्यधिक संभावना है।

DNS सर्वर चलाना पूरी तरह से संभव है जिसमें केवल UDP पोर्ट 53 इंटरनेट पर खुला है। DNS सहकर्मियों के लिए टीसीपी एक्सेस की आवश्यकता है, लेकिन यह मेजबानों की एक छोटी सूची है।

एक नया RFC596 है जिसे अब पूर्ण DNS कार्यान्वयन के लिए टीसीपी की आवश्यकता है। यह कार्यान्वयनकर्ताओं के उद्देश्य से है। दस्तावेज़ विशेष रूप से ऑपरेटरों को संबोधित नहीं करते हैं, लेकिन चेतावनी देते हैं कि टीसीपी की अनुमति नहीं देने से कई विफलता परिदृश्य हो सकते हैं। यह विभिन्न प्रकार की विफलताओं का विवरण देता है जो परिणाम दे सकता है यदि DNS ओवरसीपी समर्थित नहीं है।

डीएनएस प्रवर्धन हमलों को रोकने के लिए टीसीपी का उपयोग करने की चर्चा हुई है। टीसीपी के पास सेवा जोखिमों का अपना खंडन है, लेकिन वितरण अधिक कठिन है।


DNSSEC ने सीमा को ढीला नहीं किया, EDNS0 ने, 1999 में (RFC 2671 देखें)।
अलनीतक

नहीं, जैसा कि अलनीतक द्वारा समझाया गया है, ज्यादातर मामलों में टीसीपी की आवश्यकता होती है (जब तक कि आप पूरी तरह से निश्चित न हों कि आपके पास कभी भी उत्तर नहीं होगा> 512 बाइट्स, ऐसा कुछ जिसे आप आमतौर पर पहले से नहीं जानते हैं)
bortzmeyer

मैंने सफलतापूर्वक केवल UDP की अनुमति देने वाले फ़ायरवॉल के माध्यम से DNS चलाया है। पैथोलॉजिकल कॉन्फ़िगरेशन को छोड़कर, पता लुकअप 512 वर्णों के अंतर्गत होगा। मैंने ऐसे संदर्भ देखे हैं कि DNS पथ 256 वर्णों तक सीमित हैं। मेरे मेल सर्वर के लिए डेटाबेस में साक्ष्य से पता चलता है कि सर्वर डीएनएस पथ शायद ही कभी 100 वर्णों से अधिक होता है, और जिन साइटों के नाम एकाधिक नाम पीटीआर रिकॉर्ड करते हैं, वे शायद ही कभी 256 वर्णों से अधिक हो जाते हैं। ये सभी रिपोन यूडीपी पर चलेंगे। क्या किसी के पास एक उचित मामला है जो DNSSEC या ज़ोन स्थानांतरण के बिना 512 वर्णों के पास चलता है।
BillThor

पुन: DNSSEC, मैंने विस्तारित आकारों के लिए RFC का सत्यापन नहीं किया, लेकिन UDP पर विस्तारित पैकेट आकार का उपयोग करने के लिए मैंने जो संदर्भ देखे हैं उनमें बेन DSNSEC है।
बिलथोर

बड़े कंटेंट प्रदाताओं में से एक कुछ साल पहले आया था जब उन्होंने अपने एक वेबफार्म्स के लिए इतने ए रिकॉर्ड जोड़े कि यह 512 बाइट्स से अधिक हो गया। जिसके कारण वास्तविक अंतरोप संबंधी समस्याएं हुईं।
अलनीतक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.