問題描述
# 04/16/2019
主機 centos 4.18.12-1.el7.elrepo.x86_64 系統，鏡像 apline 系統。在容器里PING某個域名，在進行DNS解析時會有一段時間的延遲。
使用tcpdump抓包，發現：在容器中，當PING某個域名時，發出兩次DNS查詢，一個IPv4的A記錄，一個IPv6的AAAA記錄。當DNS查詢記錄為A類型時，是整正常的。當DNS查詢類型為AAAA時，返回的DNS狀態碼是SERVFAIL(RCODE=2)。當然，我們的DNS服務器中並沒有IPv6的記錄，但是返回SERVFAIL是不正常的（我查了返回SERVFAIL的原因）。但是，在容器中PING百度時是正常的。因為BAIDU的IPv6返回的不是ServFail狀態，而是IPv6地址。
使用PING -4時，馬上返回結果，因為值進行了IPv4的A記錄解析。然后，結合 DNS Issue #255 中的描述，我們將問題的焦點放在了DNS上，DNS服務器是BIND，使用它的了DLZ技術。
這里面有很多猜疑的成分，由於不具備某些方面的知識，正確的思路是：在 PING 出現問題的時候，進行調試，堆棧追蹤，找到程序的行為，然后確定是 DNS 返回的 SERVFAIL導致程序的延遲，然后了解 SERFFAIL 的狀態值、含義、返回原因，然后綜合處理問題。
原因分析
問題是DNS服務器返回SERVFAIL狀態導致的。該狀態導致了PING命令延遲。（這里面存在猜疑的成分，但是結論的可信度還是很高的）
還有一方面，好多程序開始嘗試同時進行IPv4的A記錄和IPv4之上的AAAA記錄的解析。在PHP的CURL中，也出現了類似的現象，但是我沒有進行驗證，只是相信是同樣的原因。時間成本太高了，還有很多其他的事情要做，又不是只解決這個一個問題。
解決方法
解決方法由以下幾個：
1）從根本上解決DNS服務器返回SERVFAIL狀態的。（我們采用的方案）
2）更換鏡像或者依賴程序類庫，來使得解析的時候只進行IPv4的A記錄解析。（不根本，影響后期IPv4切換）
3）調整容器，修改/etc/resov.conf配置，設置 timeout 和 attempts 選項，減少重試和超時。（不根本，時間粒度大，影響體驗，最多就是暫緩問題）
4）調整容器，在 /etc/hosts 手動綁定。（此方案最多就是暫緩了問題，依舊沒有解決問題）
5）還有一些其他的辦法，最后都被過濾掉了。技術不可行，或者工作量太大。
該問題特定於BIND的DLZ技術，問題已經記錄在 BIND DLZ 筆記中。
# 04/02/2021 今天，在 Ubuntu 18.04 中，我們再次遇見該問題，在 tcpdump 后，我們發現相同的原因導致該問題。解決方案有以下幾種：
1）修改 /etc/resolv.conf 文件，添加 options single-request 選項（因為從 glibc 2.9 開始，將並行執行 A 與 AAAA 查詢，而部分服務端不響應而導致客戶端等待，參考 man 5 resolv.conf 對 single-request 的說明）。 但是，在 Ubuntu 18.04 中，默認使用 Netplan 管理網絡，暫不支持設置 single-request 選項。
2）禁用 Linux IPv6 協議棧，參考 [[99.Operating Systems Administration:Network Configuration:Disable IPv6 on Linux|Disable IPv6 on Linux]] 筆記。
參考文獻
DNS Issue #255
DNS/IPV6 Problem #153
What does it mean when I get a server failure when connecting to a router with DNS protocol