本文始發於：雲棲社區
時間：2020-06-02
原文鏈接：https://yq.aliyun.com/articles/763329
現代系統大量依賴DNS提供的便捷的名稱和IP映射關係來獲取更好的適配性和穩定性（包括流量引導、均衡請求等功能），DNS的規範配置和使用變得越來越重要。因此，筆者將通過幾篇系列文章來詳細梳理下DNS的行為。
1 DNS客戶端行為
目前主流兩套操作系統，Windows和Linux，在DNS客戶端的行為上各有不同。由於客戶端是DNS請求發起的地方，我們詳細梳理下各系統默認的DNS客戶端行為。
1.1 Windows DNS Client service
每個Windows系統都默認使用DNS Client service來處理名稱解析請求，系統API GetHostByName的調用在DNS Client service存在並啟動的情況下，使用LRPC call將請求發往該服務內部處理；在DNS Client停用的情況下則直接使用Winsock的Namespace Provider直接解析（此時，行為與Linux的DNS請求類似）。
因此，在Windows中，DNS名稱解析的行為主要在DNS Client service存在的情況下發生，具體包括：
- 檢查DNS Client服務本地cache，如果命中緩存直接返回結果（包括negative result）。（注：hosts文件中的記錄將會在我們修改hosts文件的時候由操作系統通知DNS Client服務重新加載hosts文件到DNS Client的緩存中）。
- 如果緩存命中失敗，第一次查詢請求將發送給配置在主網卡上的Preferred DNS server。（注：在主機運行過程中會動態調整，默認我們認為主機開機後，第一個查詢的服務器就是Preferred DNS server）。
- 若前一步沒有得到響應，一秒後，查詢配置在所有網卡上的Preferred DNS server。
- 同樣的一秒後，查詢所有網卡上的所有DNS server。
- 此後，間隔兩秒，四秒，八秒，再次查詢所有DNS server，直到DNS Client內置的超時時間到期（約17秒）。
注：若DNS Client查詢發現服務器無響應，將會調整DNS server的順序，避免下次查詢繼續發往無響應服務器。
1.2 Linux DNS Client
Linux主機的DNS查詢行為相對直接一些，大多數Linux主機默認不安裝nscd，因此查詢是直接進行而沒有本地cache。
根據/etc/resolv.conf的配置，gethostbyname API直接執行查詢，具體包括：
- 查詢hosts文件。
- 加載resolv.conf，根據nameserver配置，向第一個nameserver發送查詢請求。
- 若前一步沒有得到響應，查詢超時後（默認超時時間5秒），向下一個nameserver發起請求。
- 輪詢直至超過attempts配置。
至於特有的domain/search/ndots/rotate(Linux)，prefix/suffix/devolution(Windows)等等配置，可以在遇到具體問題的時候查詢。
注：在Windows/Linux中，DNS Client的查詢總是recusive。它對DNS服務器的預期只是需要返回查詢對應的結果（而非引用）。
1.3 瀏覽器緩存
其實這部分並不屬於DNS客戶端討論範疇，但是由於現今瀏覽器的發展，瀏覽器已經包攬了越來越多的工作，在瀏覽器內部也已經出現了類似HTTP內容緩存的DNS緩存，在排查過程中不可忽視。
chrome: about:net-internals/#dns
firefox: about:networking#dns
Chromium: about:net-internals/#dns
IE/Edge: 暫無2 客戶端排查方案
從客戶端的角度來看，一般我們需要知道客戶端選擇DNS服務器地址的邏輯，檢查DNS查詢名稱生成的邏輯是否符合預期，以及是否從服務器的響應中得到了正確的結果。
在Windows上，我們主要通過DNS Client的ETL來追蹤查詢的行為。注意：Windows的內部調用比較複雜，我們需要追蹤的組件較多，例如：
• dnsapi.dll負責LRPC的CCALL和SCALL，在應用程序中以CCALL形式調用在DNS Client服務的SCALL名稱解析功能。
• dnsrslvr.dll負責名稱解析功能，由dnsapi.dll SCALL調用，運行在DNS Client服務進程空間。
• nslookup.exe摒除DNS Client服務調用，直接使用namespace provider執行名稱解析。
更進一步可以追蹤winsock相關組件和tcpip組件。DNS行為追蹤工具有procmon，netmon，ETL trace(netsh.exe)，DNS名稱解析排查工具有nslookup.exe/dig.exe(需安裝)。
本地cache檢查：
ipconfig /displaydns
ipconfig /flushdns在Linux上，可以通過strace來判斷應用程序的名稱解析行為，因為所有的名稱解析操作都是直接在進程中調用gethostbyname來完成，在沒有類似nscd緩存的情況下，所有名稱解析行為發生在應用程序進程中。排查工具有strace，tcpdump，dig，nslookup。
下期本文將介紹DNS客戶端相關的排查方案，以及實際的案例，並根據實際經驗總結DNS客戶端的推薦配置，敬請期待！
作者：陳鴿
阿里雲智能GTS-SRE團隊技術專家
曾就職於微軟負責Windows操作系統網絡協議棧及網絡產品技術支持相關工作，瞭解各產品標準協議例如TCPIP、DNS等。現就職於阿里雲智能GTS-SRE團隊，負責專有云網絡相關產品（SLB/VPC等）的高可用、高可靠運維。
我們是阿里雲智能全球技術服務-SRE團隊，我們致力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基於雲構建更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運行更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿里雲SRE技術學院釘釘圈子，和更多雲上人交流關於雲平臺的那些事。