解析主機名稱需要 5 秒

Question 1

簡短回答：

解決方法是透過新增一行來強制glibc重複使用套接字來尋找AAAA和記錄：A/etc/resolv.conf

options single-request-reopen

這個問題的真正原因可能是：

設定錯誤的防火牆或路由器（例如此處所述的 Juniper 防火牆配置) 這會導致丟棄AAAADNS 封包
DNS 伺服器中的錯誤

長答案：

curl類似或wget使用glibc的功能的程序取得地址資訊()，它嘗試透過並行查找 DNS 記錄來相容 IPv4 和 IPv6。在收到兩筆記錄之前它不會回傳結果（有與這種行為相關的幾個問題) - 這解釋了strace上面的內容。當強制使用 IPv4 時，例如curl -4在內部僅gethostbyname()查詢A記錄。

從中tcpdump我們可以看出：

-> A?開頭發送兩個請求
-> AAAA?（請求 IPv6 位址）
<- AAAA回覆
-> A?再次請求 IPv4 位址
<- A收到回覆
-> AAAA?再次請求 IPv6
<- AAAA回覆

A由於某種原因，一個回覆被刪除，這是一條錯誤訊息：

error sending response: host unreachable

但我不清楚為什麼需要第二次AAAA查詢。

要驗證您是否遇到相同的問題，您可以在以下位置更新逾時/etc/resolv.conf：

options timeout:3

首先建立一個文字文件自訂時間報告配置:

cat >./curl-format.txt  <<-EOF
   time_namelookup: %{time_namelookup}\n
      time_connect: %{time_connect}\n
   time_appconnect: %{time_appconnect}\n
     time_redirect: %{time_redirect}\n
  time_pretransfer: %{time_pretransfer}\n
time_starttransfer: %{time_starttransfer}\n
                    ----------\n
time_total: %{time_total}\n
EOF

然後發送請求：

$ curl -w "@curl-format.txt" -o /dev/null -s https://example.com

            time_namelookup:  3.511
               time_connect:  3.511
            time_appconnect:  3.528
           time_pretransfer:  3.528
              time_redirect:  0.000
         time_starttransfer:  3.531
                            ----------
                 time_total:  3.531

還有另外兩個相關選項man resolv.conf：

單一請求（自 glibc 2.10 起）設定RES_SNGLKUP 在 _res.options.預設情況下，glibc 從 2.9 版本開始並行執行 IPv4 和 IPv6 查找。某些設備 DNS 伺服器無法正確處理這些查詢並使請求逾時。此選項會停用該行為並使 glibc 依序執行 IPv6 和 IPv4 請求（代價是解析過程會減慢）。

單一請求重新開啟（自 glibc 2.9 起） 解析器對 A 和 AAAA 請求使用相同的套接字。某些硬體錯誤地只發回一個回應。當這種情況發生時，客戶端系統將坐下來等待第二個回應。開啟此選項會變更此行為，以便如果來自相同連接埠的兩個請求未正確處理，它將關閉套接字並在發送第二個請求之前開啟一個新套接字。

相關問題：

Answer

簡短回答：

解決方法是透過新增一行來強制glibc重複使用套接字來尋找AAAA和記錄：A/etc/resolv.conf

options single-request-reopen

這個問題的真正原因可能是：

設定錯誤的防火牆或路由器（例如此處所述的 Juniper 防火牆配置) 這會導致丟棄AAAADNS 封包
DNS 伺服器中的錯誤

長答案：

curl類似或wget使用glibc的功能的程序取得地址資訊()，它嘗試透過並行查找 DNS 記錄來相容 IPv4 和 IPv6。在收到兩筆記錄之前它不會回傳結果（有與這種行為相關的幾個問題) - 這解釋了strace上面的內容。當強制使用 IPv4 時，例如curl -4在內部僅gethostbyname()查詢A記錄。

從中tcpdump我們可以看出：

-> A?開頭發送兩個請求
-> AAAA?（請求 IPv6 位址）
<- AAAA回覆
-> A?再次請求 IPv4 位址
<- A收到回覆
-> AAAA?再次請求 IPv6
<- AAAA回覆

A由於某種原因，一個回覆被刪除，這是一條錯誤訊息：

error sending response: host unreachable

但我不清楚為什麼需要第二次AAAA查詢。

要驗證您是否遇到相同的問題，您可以在以下位置更新逾時/etc/resolv.conf：

options timeout:3

首先建立一個文字文件自訂時間報告配置:

cat >./curl-format.txt  <<-EOF
   time_namelookup: %{time_namelookup}\n
      time_connect: %{time_connect}\n
   time_appconnect: %{time_appconnect}\n
     time_redirect: %{time_redirect}\n
  time_pretransfer: %{time_pretransfer}\n
time_starttransfer: %{time_starttransfer}\n
                    ----------\n
time_total: %{time_total}\n
EOF

然後發送請求：

$ curl -w "@curl-format.txt" -o /dev/null -s https://example.com

            time_namelookup:  3.511
               time_connect:  3.511
            time_appconnect:  3.528
           time_pretransfer:  3.528
              time_redirect:  0.000
         time_starttransfer:  3.531
                            ----------
                 time_total:  3.531

還有另外兩個相關選項man resolv.conf：

單一請求（自 glibc 2.10 起）設定RES_SNGLKUP 在 _res.options.預設情況下，glibc 從 2.9 版本開始並行執行 IPv4 和 IPv6 查找。某些設備 DNS 伺服器無法正確處理這些查詢並使請求逾時。此選項會停用該行為並使 glibc 依序執行 IPv6 和 IPv4 請求（代價是解析過程會減慢）。

單一請求重新開啟（自 glibc 2.9 起） 解析器對 A 和 AAAA 請求使用相同的套接字。某些硬體錯誤地只發回一個回應。當這種情況發生時，客戶端系統將坐下來等待第二個回應。開啟此選項會變更此行為，以便如果來自相同連接埠的兩個請求未正確處理，它將關閉套接字並在發送第二個請求之前開啟一個新套接字。

相關問題：

Question 2

正如@Tombart 所說，延遲是由於等待 IPv6 解析逾時造成的。

另一個可能的做法是在 /etc/gai.conf 中優先考慮 IPv4

來自 /etc/gai.conf 中的註釋

#   For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96  100

更改後gai.conf，您需要重新啟動任何使用 DNS 解析器庫的應用程式才能使更改生效。

請注意，如果您使用沒有 IPv6 連接的 BIND 伺服器，我建議停用 IPv6named並從根提示中取得 IPv6 位址。顯然它仍然會嘗試解析 AAAA 位址。

所以對於 BIND 配置，

在 /etc/default/bind9 中，為 IPv4 位址新增 -4：

OPTIONS="-4 -u bind"

並在中/etc/bind/db.root刪除所有具有 AAAA DNS 根的行。

Answer