為什麼bind比公共dns提供者慢

Question

我們在ubuntu 12.04 中綁定了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。綁定使用谷歌8.8.8.8和8.8.4.4作為貨運代理：

切勿刷新正在運行的綁定的快取。綁定使用谷歌8.8.8.8和8.8.4.4作為貨運代理：

在第一個請求系列之前刷新快取rndc flush。 Bind 使用更新的根伺服器清單作為轉發器：

切勿刷新正在運行的綁定的快取。 Bind 使用更新的根伺服器清單作為轉發器：

為什麼 google public dns 的最大查詢時間（第一張圖上大約 5k，第三張圖上大約 2.5k）大於根伺服器？

為什麼透過bind查詢比直接查詢公共dns伺服器慢？

我的測驗可能有問題嗎？

更新1

圖表上有 20 秒 TTL - 這是錯誤的。 redhat.com 的 TTL 為 60 秒。

Answer 1

您的測試正在測量執行查詢的總時間，包括

• 運行測試腳本的機器之間的網路延遲
• 被測名稱伺服器上的處理時間
• 被測試的名稱伺服器等待其他名稱伺服器的答案所花費的時間，即執行任何遞歸子查詢的時間

結果與預期差不多。

• 如果您查詢本機 BIND 伺服器而不刷新快取，則大多數情況下答案將來自快取。即使 A RR 的 TTL 已過期，NS RR 仍將在快取中，因此只需從外部請求 A RR 本身。
• 如果您在刷新快取後查詢本機 BIND 伺服器並取得不是配置轉發器後，您的本機 BIND 伺服器將從根伺服器開始向下執行遞歸查詢。
• 如果您在刷新快取後查詢本機 BIND 伺服器並將 Google 伺服器設定為轉發器，則您的本機 BIND 伺服器將按原樣將查詢轉發到其中一台 Google 伺服器，然後該伺服器將從其快取應答查詢，或執行遞歸查詢。請注意，您無法控制 Google 伺服器的快取。

因此，在不先清除快取的情況下對本機 BIND 伺服器的查詢速度最快，且不受轉發器配置的影響。清除快取並將 Google 伺服器配置為轉發器後對本地 BIND 伺服器的查詢比直接對 Google 伺服器的查詢要慢，因為它們會增加後者首先透過本機 BIND 伺服器的開銷。