Прив’язати DNS рекурсії повільно


9

Ми тільки що налаштували рекурсивний DNS-сервер за допомогою останнього стабільного випуску Bind 9.10

Ми виявляємо, що рекурсивні пошуки DNS відбуваються досить повільно. Десь від 1 до 3 секунд. Після того, як пошук знаходиться в кеші, DNS вирішує за лічені мілісекунди, як очікувалося.

Ми використовуємо підказки ROOT для рекурсивних пошуку, і, здається, саме тут йде повільність. Якщо ми налаштуємо форвардера, роздільна здатність DNS зводиться до розумного часу рекурсії 100 - 300 мс.

Для сервісу, який ми створюємо, я не хочу покладатися на експедиторів, я б вважав за краще використовувати підказки root.

Ось головна конфігурація з нашого файлу 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

Щось у журналах?
Хокан Ліндквіст

Відповіді:


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

2

У мене була ця сама проблема з дуже повільними рекурсивними запитами на фізичному сервері 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-berely-packets-to-big-for-configured-512/td-p/861718

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.