Mengikat Rekursi DNS Lambat

Kami baru saja menyiapkan server DNS rekursif menggunakan rilis stabil terbaru dari Bind 9.10

Kami menemukan bahwa pencarian DNS rekursif cukup lambat. Di mana saja dari 1 - 3 detik. Setelah pencarian dalam cache, DNS menyelesaikan dalam hitungan milidetik seperti yang diharapkan.

Kami menggunakan petunjuk ROOT untuk pencarian rekursif dan ini tampaknya dari mana kelambatan itu berasal. Jika kita mengkonfigurasi penerusan, resolusi DNS turun ke waktu rekursi masuk akal 100 - 300 ms.

Untuk layanan yang kami siapkan, saya tidak ingin mengandalkan forwarder, saya lebih suka menggunakan petunjuk root.

Ini adalah konfigurasi utama dari file named.conf kami . Setiap petunjuk untuk membantu meningkatkan kinerja akan sangat bagus.

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";

Kami menemukan masalahnya. Itu adalah masalah pembongkaran perangkat keras NIC.

Running tcpdump -vvv -s 0 -l -n port 53menemukan beberapa[bad udp cksum 6279!] kesalahan untuk setiap permintaan DNS.

Jelajah kecil di Google mengarahkan saya ke arah yang benar. Ternyata, karena sistem CentOS kami berjalan sebagai VM pada XenServer (masalah serupa dilaporkan dengan VMWare dll.) Pembongkaran perangkat keras NIC diaktifkan secara default.

Berlari ethtool -k eth0 | grep onmenunjukkan hal berikut

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]

Menjalankan ethtool -K eth0 tx off rx offoffloading TCP TX yang dinonaktifkan. Saya memulai kembali layanan jaringan untuk ukuran yang baik

service network restart

dan diuji BIND. Kami sekarang mendapatkan waktu respons yang sangat cepat dari 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

Saya memiliki masalah yang sama dengan pertanyaan rekursif yang sangat lambat pada server fisik BOS CentOS 7 dan menemukan jawaban ini (TX Offloading) dan banyak perbaikan berorientasi IPv6 di sekitar berbagai utas, tidak ada yang bekerja untuk saya.

Ternyata lokasi server tersebut memiliki firewall Cisco ASA yang lebih lama yang membatasi ukuran paket respons UDP hingga 512 byte; tampaknya akhir-akhir ini tanggapan UDP untuk permintaan DNS seringkali jauh lebih besar, hingga sekitar 2000 byte. Ada halaman tentang itu di sini:

Mengapa DNS melalui UDP memiliki batas 512 byte?

Saya mengkonfigurasi ASA untuk memungkinkan paket respons UDP yang lebih besar (ada perintah perbaikan khusus untuk ini) yang menyelesaikan masalah:

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