बाइंड डीएनएस रिकर्सन स्लो


9

हमारे पास सिर्फ एक पुनरावर्ती DNS सर्वर है, जो Bind 9.10 के नवीनतम स्थिर रिलीज का उपयोग करता है

हम पा रहे हैं कि पुनरावर्ती DNS लुकअप काफी धीमा है। कहीं भी 1 - 3 सेकंड से। एक बार लुकअप कैश में होने के बाद, DNS उम्मीद के मुताबिक मिलीसेकंड के मामले में हल हो जाता है।

हम पुनरावर्ती लुकअप के लिए रूट संकेत का उपयोग कर रहे हैं और यह प्रतीत होता है कि धीमापन कहां से आ रहा है। यदि हम फारवर्डर को कॉन्फ़िगर करते हैं तो DNS रिज़ॉल्यूशन 100 - 300ms के एक समझदार पुनरावृत्ति समय के लिए नीचे आता है।

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

यहाँ हमारे name.conf फ़ाइल से मुख्य विन्यास है । प्रदर्शन को बेहतर बनाने में मदद करने के लिए कोई भी संकेत महान होगा।

options{
allow-recursion  { any; };
allow-query-cache  { any; };
allow-query  { any; };

listen-on  port 53  { any; };
listen-on-v6  port 53  { any; };

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

zone-statistics yes;
max-cache-ttl 3600;
max-ncache-ttl 3600;

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";

directory  "/var/named";
dump-file  "/var/named/data/cache_dump.db";
statistics-file  "/var/named/stats/named_stats.txt";
memstatistics-file  "/var/named/stats/named_mem_stats.txt";

rate-limit {
    responses-per-second 10;
    log-only yes;
};

prefetch 5;};

zone "." {
type hint;
file "named.ca";};

include "/var/named/conf/logging.conf";

5
मैं tcpdump का उपयोग करता हूं और देखता हूं कि धीमे अनुरोधों के दौरान वास्तव में क्या हो रहा है।
यूनिक्स

लॉग में कुछ भी?
हाकन लिंडक्विस्ट

जवाबों:


6

हमें मुद्दा मिल गया। यह एक एनआईसी हार्डवेयर ऑफलोडिंग मुद्दा था।

प्रत्येक DNS क्वेरी के लिए रनिंग tcpdump -vvv -s 0 -l -n port 53में कुछ [bad udp cksum 6279!]त्रुटियां पाई गईं ।

Google पर थोड़ा ब्राउज़ करने से मुझे सही दिशा में संकेत मिला। जैसा कि यह पता चला है, हमारे CentOS सिस्टम पर XenServer पर VM के रूप में चलने के कारण (VMWare आदि के साथ रिपोर्ट किए गए समान मुद्दे) NIC हार्डवेयर ऑफ़लोडिंग डिफ़ॉल्ट रूप से सक्षम है।

रनिंग ethtool -k eth0 | grep onने निम्नलिखित दिखाया

x-checksumming: on
tx-checksum-ipv4: on
scatter-gather: on
tx-scatter-gather: on
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off
tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
tx-gso-robust: on [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]

ethtool -K eth0 tx off rx offअक्षम टीसीपी TX ऑफलोडिंग चल रहा है । मैंने अच्छे उपाय के लिए नेटवर्किंग सेवा को फिर से शुरू किया

service network restart

और BIND का परीक्षण किया। अब हमें BIND की ओर से बहुत तेजी से प्रतिक्रिया समय मिल रहा है

dig centos.org

; <<>> DiG 9.10.2-P4-RedHat-9.10.2-P4.el6 <<>> centos.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61933
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;centos.org.INA

;; ANSWER SECTION:
centos.org.60INA85.12.30.227

;; Query time: 268 msec
;; SERVER: 192.168.10.25#53(192.168.10.25)
;; WHEN: Thu Sep 17 08:25:39 AEST 2015
;; MSG SIZE  rcvd: 55

2

मुझे एक भौतिक CentOS 7 BIND सर्वर पर बहुत धीमी गति से पुनरावर्ती प्रश्नों के साथ यह समस्या थी और यह जवाब मिला (TX ऑफलोडिंग) और विभिन्न थ्रेड्स के आसपास कई IPv6- उन्मुख फ़िक्सेस, जिनमें से किसी ने भी मेरे लिए काम नहीं किया।

यह पता चला है कि प्रश्न में सर्वर का स्थान एक पुराने सिस्को एएसए फ़ायरवॉल था जो यूडीपी प्रतिक्रिया पैकेटों के आकार को 512 बाइट्स तक सीमित कर रहा था; ऐसा लगता है कि इन दिनों DNS प्रश्नों के लिए यूडीपी प्रतिक्रियाएं लगभग 2000 बाइट तक, अक्सर बड़ी होती हैं। यहाँ इसके बारे में एक पृष्ठ है:

क्यों UDP के माध्यम से DNS में 512 बाइट्स की सीमा है?

मैंने बड़े यूडीपी प्रतिक्रिया पैकेट की अनुमति देने के लिए एएसए को कॉन्फ़िगर किया (इसके लिए एक विशिष्ट फ़िक्सअप कमांड है) जिसने इस मुद्दे को हल किया:

https://supportforums.cisco.com/t5/getting-started-with-lans/dns-dropped-because-packets-to-big-for-configured-512/td-p/861718

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.