Bind DNS đệ quy chậm


9

Chúng tôi vừa thiết lập một máy chủ DNS đệ quy bằng cách sử dụng bản phát hành ổn định mới nhất của Bind 9.10

Chúng tôi thấy rằng việc tra cứu DNS đệ quy khá chậm. Bất cứ nơi nào từ 1 - 3 giây. Khi tra cứu trong bộ đệm, DNS sẽ giải quyết trong một phần nghìn giây như mong đợi.

Chúng tôi đang sử dụng các gợi ý ROOT cho các tra cứu đệ quy và đây dường như là nơi mà sự chậm chạp đến từ. Nếu chúng ta định cấu hình bộ chuyển tiếp, độ phân giải DNS sẽ giảm xuống còn 100 - 300ms.

Đối với dịch vụ chúng tôi đang thiết lập, tôi không muốn dựa vào các nhà giao nhận, tôi muốn sử dụng các gợi ý gốc.

Đây là cấu hình chính từ chúng tôi named.conf tập tin. Bất kỳ con trỏ để giúp cải thiện hiệu suất sẽ là tuyệt vời.

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
Tôi sẽ sử dụng tcpdump và xem những gì thực sự xảy ra trong các yêu cầu chậm.
yoonix

Bất cứ điều gì trong các bản ghi?
Håkan Lindqvist

Câu trả lời:


6

Chúng tôi tìm thấy vấn đề. Đó là một vấn đề giảm tải phần cứng NIC.

Chạy tcpdump -vvv -s 0 -l -n port 53tìm thấy một số [bad udp cksum 6279!]lỗi cho mỗi truy vấn DNS.

Một chút duyệt trên Google chỉ cho tôi đi đúng hướng. Hóa ra, do hệ thống CentOS của chúng tôi chạy dưới dạng VM trên XenServer (các vấn đề tương tự được báo cáo với VMWare, v.v.), giảm tải phần cứng NIC được bật theo mặc định.

Chạy ethtool -k eth0 | grep oncho thấy sau đây

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]

Đang chạy ethtool -K eth0 tx off rx offgiảm tải TCP TX. Tôi khởi động lại dịch vụ mạng để có biện pháp tốt

service network restart

và thử nghiệm BIND. Chúng tôi hiện đang nhận được thời gian phản hồi rất nhanh từ 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

Tôi gặp vấn đề tương tự với các truy vấn đệ quy rất chậm trên máy chủ CentOS 7 BIND vật lý và tìm thấy câu trả lời này (Giảm tải TX) và nhiều bản sửa lỗi định hướng IPv6 xung quanh các luồng khác nhau, không có cách nào phù hợp với tôi.

Hóa ra vị trí của máy chủ được đề cập có tường lửa Cisco ASA cũ hơn, giới hạn kích thước của các gói phản hồi UDP là 512 byte; có vẻ như ngày nay các phản hồi UDP cho các truy vấn DNS thường lớn hơn nhiều, lên tới khoảng 2000 byte. Có một trang về nó ở đây:

Tại sao DNS thông qua UDP có giới hạn 512 byte?

Tôi đã cấu hình ASA để cho phép các gói phản hồi UDP lớn hơn (có lệnh sửa lỗi cụ thể cho việc này) để giải quyết vấn đề:

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

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.