☰

なぜバインドはパブリックDNSプロバイダーよりも遅いのか

tag-icon • tag-icon bind
なぜバインドはパブリックDNSプロバイダーよりも遅いのか

Ubuntu 12.04 には bind 9.8.1.dfsg.P1-4ubuntu0.13 があり、これは負荷の高くないサーバー (負荷平均: 0.19、0.12、0.13) で実行されており、macOS と Ubuntu ワークステーションを備えた小規模オフィス ネットワークの要求に応えています。

DNS サーバーとして実行されているコンテナ上のスクリプトでいくつかの DNS テストを実行し、結果を influxdb にプッシュしました。

#!/bin/bash
while true
do
        rndc flush

        bind_timeout=$( dig @192.168.128.3 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        google_timeout=$( dig @8.8.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        yandex_timeout=$( dig @77.88.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "bind,server=bind,without_cache=yes value=$bind_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "google,server=google,without_cache=yes value=$google_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "yandex,server=yandex,without_cache=yes value=$yandex_timeout" &
        wait

        bind_timeout=$( dig @192.168.128.3 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        google_timeout=$( dig @8.8.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        yandex_timeout=$( dig @77.88.8.8 redhat.com | grep 'Query time' | awk '{ print $4 }' )
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "bind,server=bind,without_cache=no value=$bind_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "google,server=google,without_cache=no value=$google_timeout" &
        curl -i -XPOST 'http://ts.example.lab:8086/write?db=dnstest' -d "yandex,server=yandex,without_cache=no value=$yandex_timeout" &
        wait

        sleep 5
done

バインドのリクエストへの応答が遅いことが分かりました8.8.8.8そして77.88.8.8これはグラフで確認できます。

最初のリクエストシリーズの前にキャッシュをフラッシュしますrndc flush。BindはGoogleを使用します8.8.8.8そして8.8.4.4フォワーダーとして:

ここに画像の説明を入力してください

実行中のbindのキャッシュをフラッシュしないでください。bindはgoogleを使用します8.8.8.8そして8.8.4.4フォワーダーとして:

ここに画像の説明を入力してください

最初のリクエスト シリーズの前にキャッシュをフラッシュしますrndc flush。Bind は、フォワーダーとしてルート サーバーの更新されたリストを使用します。

ここに画像の説明を入力してください

実行中の bind のキャッシュをフラッシュしないでください。bind は、フォワーダーとしてルート サーバーの更新されたリストを使用します。

ここに画像の説明を入力してください

Google パブリック DNS の最大クエリ時間 (最初のグラフでは約 5k、3 番目のグラフでは 2.5k) がルート サーバーよりも長いのはなぜですか?

バインドを介したクエリがパブリック DNS サーバーの直接クエリよりも遅いのはなぜですか?

私のテストに何か問題があるのでしょうか?

アップデート1

グラフには 20 秒の TTL が表示されていますが、これは誤りです。redhat.com の TTL は 60 秒です。

答え1

テストでは、クエリを実行するのにかかる合計時間を測定します。これには、

  • テストスクリプトを実行しているマシンとの間のネットワーク遅延
  • テスト中のネームサーバの処理時間
  • テスト対象のネームサーバーが他のネームサーバーからの応答を待つ時間、つまり再帰サブクエリを実行する時間

結果はほぼ予想通りです。

  • キャッシュをフラッシュせずにローカル BIND サーバーにクエリを実行すると、ほとんどの場合、キャッシュから応答が返されます。A RR の TTL が期限切れになっても、NS RR はキャッシュ内に残っているため、A RR 自体のみを外部から要求する必要があります。
  • キャッシュをフラッシュした後にローカルBINDサーバーにクエリを実行し、ないフォワーダーが設定されている場合、ローカル BIND サーバーはルート サーバーから下方向に再帰クエリを実行します。
  • キャッシュをフラッシュした後にローカル BIND サーバーにクエリを実行し、Google サーバーをフォワーダーとして設定した場合、ローカル BIND サーバーはクエリをそのまま Google サーバーの 1 つに転送し、その Google サーバーはキャッシュからクエリに応答するか、再帰クエリを実行します。Google サーバーのキャッシュは制御できないことに注意してください。

その結果、最初にキャッシュをクリアせずにローカル BIND サーバーにクエリを実行すると、最も高速になり、フォワーダー構成の影響を受けません。キャッシュをクリアし、Google サーバーをフォワーダーとして構成した後のローカル BIND サーバーへのクエリは、Google サーバーへの直接クエリよりも遅くなります。これは、ローカル BIND サーバーを最初に通過するオーバーヘッドが後者に追加されるためです。

関連情報