Bind DNS Recursion Slow

Мы только что установили рекурсивный 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 и т. Д.), Аппаратная разгрузка сетевых адаптеров включена по умолчанию.

Бег 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 Offloading) и множество IPv6-ориентированных исправлений вокруг различных потоков, ни один из которых не работал для меня.

Оказывается, в расположении рассматриваемого сервера был более старый межсетевой экран Cisco ASA, который ограничивал размер пакетов ответа UDP 512 байтами; кажется, что в наши дни ответы UDP на DNS-запросы часто бывают намного больше, примерно до 2000 байт. Здесь есть страница об этом:

Почему DNS через UDP имеет ограничение в 512 байт?

Я настроил ASA, чтобы позволить большие пакеты ответа UDP (есть определенная команда исправления для этого), который решил проблему:

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