バインドDNS再帰が遅い


9

Bind 9.10の最新の安定版リリースを使用して、再帰DNSサーバーをセットアップしました

再帰的な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";

5
私はtcpdumpを使用して、遅い要求の間に実際に何が起こっているかを確認します。
yoonix

ログに何かありますか?
ホーカンLindqvist

回答:


6

問題が見つかりました。NICハードウェアのオフロードの問題でした。

実行すると、各DNSクエリでtcpdump -vvv -s 0 -l -n port 53いくつかの[bad udp cksum 6279!]エラーが見つかりました。

グーグルで少し閲覧して、私は正しい方向に向かった。結局のところ、XenServerでVMとして実行されているCentOSシステム(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オフロード)とさまざまなスレッドに関する多くのIPv6指向の修正が見つかりましたが、どれもうまくいきませんでした。

問題のサーバーの場所には、古いCisco ASAファイアウォールがあり、UDP応答パケットのサイズを512バイトに制限していたことがわかりました。最近では、DNSクエリに対するUDP応答がはるかに大きくなり、最大で約2000バイトになる場合があります。ここにそれについてのページがあります:

UDPを介したDNSに512バイトの制限があるのはなぜですか?

問題を解決するために、より大きなUDP応答パケットを許可するようにASAを設定しました(これには特定のfixupコマンドがあります)。

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.