ผูก DNS ซ้ำช้า


9

เราเพิ่งตั้งค่าเซิร์ฟเวอร์ DNS แบบเรียกซ้ำโดยใช้ Bind 9.10 ที่เสถียรล่าสุด

เราพบว่าการค้นหา DNS แบบเรียกซ้ำค่อนข้างช้า ทุกที่ตั้งแต่ 1 - 3 วินาที เมื่อการค้นหาอยู่ในแคช DNS จะแก้ไขในเรื่องของมิลลิวินาทีตามที่คาดไว้

เรากำลังใช้คำแนะนำ ROOT สำหรับการค้นหาแบบเรียกซ้ำและสิ่งนี้ดูเหมือนจะเป็นที่มาของความเชื่องช้า หากเรากำหนดค่าตัวส่งต่อความละเอียด DNS จะลดลงเป็นเวลาเรียกคืนที่เหมาะสมระหว่าง 100 - 300ms

สำหรับบริการที่เรากำลังตั้งค่าฉันไม่ต้องการพึ่งผู้ส่งต่อฉันต้องการใช้คำแนะนำราก

นี่คือการกำหนดค่าหลักจากไฟล์named.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 และดูสิ่งที่เกิดขึ้นจริงในช่วงคำขอช้า
yoonix

มีอะไรในบันทึกบ้าง
Håkan Lindqvist

คำตอบ:


6

เราพบปัญหา มันเป็นปัญหาการถ่ายฮาร์ดแวร์ NIC

การเรียกใช้tcpdump -vvv -s 0 -l -n port 53พบ[bad udp cksum 6279!]ข้อผิดพลาดเล็กน้อยสำหรับแต่ละแบบสอบถาม DNS

การเรียกดูบน Google เล็กน้อยชี้ให้ฉันในทิศทางที่ถูกต้อง ตามที่ปรากฏออกมาเนื่องจากระบบ CentOS ของเราทำงานเป็น VM บน XenServer (ปัญหาที่คล้ายกันที่รายงานกับ 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ปิดใช้งานการถ่าย TCP TCP ไม่ทำงาน ฉันเริ่มบริการเครือข่ายใหม่เพื่อการวัดที่ดี

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 ที่มุ่งเน้นจำนวนมากรอบเธรดต่างๆ

ปรากฎตำแหน่งของเซิร์ฟเวอร์ที่สงสัยว่ามีไฟร์วอลล์ Cisco ASA รุ่นเก่าซึ่ง จำกัด ขนาดของแพ็คเก็ตการตอบสนอง UDP ไว้ที่ 512 ไบต์; ดูเหมือนว่าทุกวันนี้การตอบสนอง UDP สำหรับการค้นหา DNS มักจะใหญ่กว่ามากถึง 2,000 ไบต์ มีหน้าเกี่ยวกับที่นี่:

ทำไม DNS ถึง UDP ถึงขีด จำกัด 512 ไบต์

ฉันกำหนดค่า ASA ให้อนุญาตแพ็คเก็ตการตอบสนอง UDP ที่ใหญ่กว่า (มีคำสั่ง fixup เฉพาะสำหรับสิ่งนี้) ซึ่งแก้ไขปัญหาได้:

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.