Мы только что настроили рекурсивный DNS-сервер с использованием последней стабильной версии Bind 9.10.
Мы обнаружили, что рекурсивный поиск в DNS выполняется довольно медленно. От 1 до 3 секунд. Как только поиск находится в кеше, DNS разрешает за считанные миллисекунды, как и ожидалось.
Мы используем ROOT-подсказки для рекурсивного поиска, и, похоже, именно отсюда и происходит медлительность. Если мы настраиваем пересылку, разрешение DNS сводится к разумному времени рекурсии 100–300 мс.
Что касается сервиса, который мы настраиваем, я не хочу полагаться на серверы пересылки, я бы предпочел использовать корневые ссылки.
Вот основной конфиг из нашего 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";
Мы нашли проблему. Это была проблема разгрузки оборудования NIC.
Бег tcpdump -vvv -s 0 -l -n port 53 нашел горстку [bad udp cksum 6279!] ошибки для каждого DNS-запроса.
Небольшой поиск в Google указал мне правильное направление. Как оказалось, из-за того, что наша система CentOS работает как виртуальная машина на 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 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
У меня была такая же проблема с очень медленными рекурсивными запросами на физическом сервере CentOS 7 BIND, и я нашел этот ответ (разгрузка TX) и множество исправлений, ориентированных на IPv6, для различных потоков, ни один из которых не помог мне.
Оказывается, в месте расположения рассматриваемого сервера был установлен более старый брандмауэр Cisco ASA, который ограничивал размер пакетов ответа UDP до 512 байтов; Кажется, что в наши дни ответы UDP на запросы DNS часто намного больше, примерно до 2000 байт. Об этом есть страница:
Почему DNS через UDP имеет ограничение в 512 байт?
Я настроил ASA, чтобы разрешить более крупные пакеты ответов UDP (для этого есть специальная команда исправления), которая разрешила проблему: