फोर्स फारवर्डर डीएनएस अनुरोधों को टीसीपी मोड में भेजती है

Question

मैंने एक बहु-होम सर्वर पर SLES10 (वर्तमान में बाइंड 9.6) पर DNS-सर्वर स्थापित किया है। यह सर्वर सभी आंतरिक नेटवर्कों से क्वियर किया जा सकता है और सभी आंतरिक नेटवर्कों के लिए उत्तर देता है। हमारे पास दो अलग डीएनएस "मास्टर" ज़ोन हैं। इनमें से प्रत्येक क्षेत्र को कई आधिकारिक विंडोज-डीएनएस-सर्वर द्वारा सेवा दी जा रही है।

अब मेरा लिनक्स-सर्वर इन ज़ोन (निजी आंतरिक क्षेत्र) में से एक के लिए एक द्वितीयक DNS सर्वर है और दूसरे क्षेत्र (सार्वजनिक आंतरिक क्षेत्र) के लिए फारवर्डर के रूप में कार्य करता है।

कुछ समय पहले तक यह सेटअप बिना किसी समस्या के काम करता था। अब मुझे मिलता है - सार्वजनिक आंतरिक क्षेत्र (उदाहरण के लिए hostएक लिनक्स क्लाइंट पर कमांड द्वारा ) त्रुटि संदेश पर क्वेरी करना

;; टीसीपी मोड में छंटनी, पुन: प्रयास करना

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

अब प्रश्न: क्या मैं पहले UDP को आज़माए बिना TCP मोड में फ़ॉरवर्डर्स को क्वेरी करने के लिए अपने बाइंड को कॉन्फ़िगर कर सकता हूँ?

अपडेट: ASCII- कला पर अपना हाथ आजमाना ...

+--------------+   +--------------+   +-----------------+
| W2K8R2 DNS   |   | SLES 10 DNS  |   | W2K8R2 DNS      |
| Zone private +---+ All internal +---+ Zone public     |
| internal 2x  |   |   Zones      |   | internal 30+ x  |
+--------------+   +-+----------+-+   +-----------------+
                     |          |
                  +--+---+   +--+---+
                  |Client|   |Client|
                  +------+   +------+

Comments

इसका एक छोटा आरेख उपयोगी होगा - मैं यह जानने के लिए संघर्ष कर रहा हूं कि कौन सा सर्वर आपके विवरण से है।

— अलनीतक

कुछ हद तक बेहतर है, हालांकि यह अभी भी स्पष्ट नहीं है कि कौन से मेजबान इस hostकमांड को चला रहे हैं , और किस क्वेरी को भेजा जा रहा है।

— अलनीतक

क्लाइंट SLES10 के माध्यम से ज़ोन पब्लिक इंटरनल से एंट्री का अनुरोध करते हैं। ज़ोन निजी आंतरिक को नुकसान नहीं होता है - क्योंकि वहां केवल 2 एनएस प्रविष्टियां हैं।

— निल्स

और ग्राहक सिर्फ सादे ठूंठ रिसोल्वर हैं?

— अलनीतक

सुझाव है कि आप minimal-responses: yesSLES 10 पर BIND कॉन्फ़िगरेशन में जोड़ें - यह प्रतिक्रिया आकारों को कम कर सकता है। किसी भी घटना में, अधिकांश सामान्य प्रश्न 512 बाइट सीमा से अधिक नहीं होंगे।

— एल्निटैक

Answer 1

सबसे पहले, मैं उस त्रुटि को सिर्फ एक सूचना संदेश नहीं कहूंगा।

दूसरा, DNS सर्वर हमेशा यूडीपी प्रश्नों का उत्तर देंगे (कम से कम, मुझे यूडीपी को अक्षम करने के लिए विकल्प नहीं मिल सकते हैं) और क्लाइंट हमेशा (?) पहले एक यूडीपी क्वेरी भेजने की कोशिश करेंगे (उदाहरण के लिए इसे बदलने के लिए resolv.conf में कोई विकल्प नहीं हैं) न तो JVM में) - अगर वे UDP पैकेट में फिट होते हैं (अनुरोध आमतौर पर करते हैं)

यदि आपके पास एक विशिष्ट उपयोग का मामला है, तो आप टीसीपी का उपयोग करने के लिए निर्दिष्ट कर सकते हैं, जैसे शेल स्क्रिप्ट में 'डिग + टीसीपी' या रिजॉल्यूशन के लिए 'होस्ट-टी' का उपयोग करें, और आप सिस्टम कॉल का इस्तेमाल कर सकते हैं पृष्ठ) अन्य मामलों में टीसीपी को मजबूर करने के लिए।

यदि आप वास्तव में UDP को आज़माना चाहते हैं, तो एकमात्र विकल्प जो मैं देख सकता हूं, वह एक iptable नियम के साथ है, लेकिन मुझे यकीन नहीं है कि यह सेट अप काम करेगा। मुझे उम्मीद है कि DNS रिज़ॉल्यूशन बस विफल हो जाएगा।

Comments

मुख्य रूप से एक प्राथमिकता जानने से एक प्रदर्शन लाभ होता है कि यूडीपी क्वेरी विफल हो जाएगी, और पहले टीसीपी पर प्रयास करना होगा। उस की कुछ चर्चा के लिए RFC 5966 देखें।

— अलनीतक

@ अलनीतक और मैं उस लाभ को प्राप्त करना चाहते हैं।

— निल्स

@ तो हमें यह पता लगाने की आवश्यकता है कि EDNS जाहिरा तौर पर काम क्यों नहीं कर रहा है ...

— Alnitak

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

— निल्स

@ निल्स, मुद्दा यह है कि क्लाइंट यूडीपी / टीसीपी तय करता है, लेकिन सर्वर को जवाब का आकार पता है।

— डैन एंड्राट्टा

Answer 2

आपका BIND सर्वर चाहिए EDNS (RFC 2671 देखें) का उपयोग यूडीपी पैकेट 512 बाइट्स से अधिक समय की अनुमति के लिए हो सकता है।

options {
    edns-udp-size 4096;
    max-udp-size 4096;
};

अन्य छोटे प्रश्नों के लिए टीसीपी कनेक्शन के ओवरहेड की आवश्यकता के बिना, आपके बड़े एनएस सेट को यूडीपी पर पुनर्प्राप्त करने की अनुमति दी जानी चाहिए।

ध्यान दें कि ये वास्तव में डिफ़ॉल्ट मान हैं। यदि EDNS का उपयोग नहीं किया जा रहा है, तो या तो कुछ इसे अवरुद्ध कर रहा है, या EDNS विकल्प प्राप्त करने वाले सर्वर इसका समर्थन नहीं कर रहे हैं।

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

dig +bufsize=4096 @server hostname Aउपयोग करने के बजाय प्रयास करें host।

Comments

इसका उपयोग किसको करना चाहिए? ज़ोन "पब्लिक इंटरनल" से मेरे सर्वर और मेरे फारवर्डर्स दोनों को मूल रूप से?

— निल्स

वैसे भी जवाब में एनएस की पूरी सूची भेजने का क्या मतलब है?

— निल्स

@Nils DNS प्रोटोकॉल के लिए आवश्यक है कि समान (QNAME, QTYPE और QCLASS) के मिलान का पूरा सेट टपल को अविभाज्य हो (उर्फ "a" RRset ")

— Alnitak

क्या आप कृपया मुझे इस RRset के बारे में RFC की ओर इशारा कर सकते हैं?

— निल्स

Actaully होस्ट मानक रिज़ॉल्वर लाइब्रेरी का उपयोग करता है, और मेरे कार्य केंद्र पर यह EDNS0 का समर्थन करता है। यह जांचने के लिए कि क्या अनुरोध EDNS0 निर्दिष्ट करते हैं, 'tcpdump -x port 53' चलाएं और हेक्स डंप में (अतिरिक्त खंड में, अंत में) अनुक्रम 0029 1000 0000 8000 0000 होना चाहिए, जो कि OPT RR का द्विआधारी प्रतिनिधित्व है।

— डान एंड्राट्टा