引言
上一期我們基本上将用戶端的查詢行為及其特性盡可能地梳理了一次，而本期我們關注DNS伺服器部分。由于DNS協定本身已經有相當詳細的分析了，本文将不再贅述，若感興趣可直接在Internet搜尋。推薦關注DNS RFC，可參考文後資料了解詳情（1）。
與DNS協定工作
多數DNS服務提供商有各自的DNS服務應用來提供名稱解析功能，一般來說此類應用最主要的是完成标準DNS協定，并提供較好的性能、完善的日志服務以及特殊的GEO解析等進階功能。針對DNS服務，各家産品的實作雖各不相同，但總體解析的過程是一定符合協定标準的。下面分别看一下Windows的DNS服務和Linux的Bind應用。
Windows DNS server服務
DNS标準協定定義的兩種查詢方式在Windows的DNS server服務中支援得很好。自Windows NT開始，DNS server總是一個基礎服務帶在server的發行版中，曆經多次更新，功能相當全面。由于與Windows的AD完全整合，Windows DNS server功能複雜，适合内網使用。其功能簡單羅列如下：
圖1：Windows DNS server功能展示
Linux Bind應用
在Linux上Bind（Berkeley Internet Name Domain）應用提供了完善的DNS功能，其功能相對簡單，但性能較好，我們簡單将其作為本地DNS服務學習和研究。Bind是實作DNS協定的一種開放源碼軟體，已經成為使用最廣泛的DNS伺服器軟體，它包含對域名的查詢和響應所需的所有軟體。與Windows DNS類似，BIND軟體包包括以下主要的幾個部分：
- DNS伺服器：這是一個叫做named的程式，代表name daemon的簡寫。它根據DNS協定标準的規定，響應收到的查詢。
- DNS解析庫（resolver library）：一個解析器是一個程式，通過發送請求到合适的伺服器并且對伺服器的響應做出合适的回應，來解析對一個域名的查詢。一個解析庫是程式元件的集合，可以在開發其它程式時使用，為這些程式提供域名解析的功能。
DNS伺服器配置建議
DNS查詢行為配置細節
Iterative Query疊代查詢
疊代查詢是DNS名稱解析的基礎，一般情況下，DNS server使用疊代查詢，根據root-hints server的響應一級一級得到最終結果。與疊代查詢相關的配置項如下：
Windows：
root-hints server配置： C:\Windows\System32\dns\cache.dns
NoRecursion開關： dnscmd /config /NoRecursion
root zone配置： Create a .(dot) zone
Linux Bind：
預設使用Iterative Query，除非在named.conf中配置forwarders
注：root zone的建立将會使DNS服務拒絕所有轉發查詢的請求，對于一些僅提供本域名解析功能的伺服器來說，會是一個比較安全的做法。
另外，參與查詢的過程中，Windows DNS server有隐含的一個拒絕查詢清單，配置在系統資料庫的GlobalQueryBlockList下，所有比對的名稱（不包含domain name），會傳回REFUSED響應。預設EnableGlobalQueryBlockList為true。
Recursive Query遞歸查詢
遞歸查詢相對來說比較簡單，類似用戶端的行為，将請求發送給上遊DNS Forwarder，期望收到直接的查詢結果。與遞歸查詢相關的配置項如下：
Windows：
Recursion配置：
dnscmd /config /RecursionRetry
dnscmd /config /RecursionTimeout
Forward配置：
dnscmd /config /EnableForwarderReordering
dnscmd /config /ForwardDelegations
dnscmd /config /ForwardingTimeout
Linux Bind：
forwarders
forward (first | only )
first設定優先使用forwarders DNS伺服器做域名解析，如果查詢不到再使用本地DNS伺服器做域名解析。
only設定隻使用forwarders DNS伺服器做域名解析，如果查詢不到則傳回DNS用戶端查詢失敗。
結合疊代查詢，推薦做法是明确DNS服務的目的，例如：
- 僅供内部解析使用推薦建立root zone，避免内部查詢的請求外洩。
- 内部解析外部，使用專門的DNS伺服器做轉發（Forwarder）指向疊代查詢DNS伺服器，同時根據需要考慮是否選擇Forwarder first or only等選項，使用專門的DNS伺服器做遞歸查詢，避免上級DNS服務異常等問題。
- 提供網際網路用戶端擷取外部域名解析的DNS伺服器上，關注兩種情形。一種提供Authoritative Answer，建議也是建立root zone，避免額外的查詢服務。一種是類似ISP提供查詢轉發，需要關注DNS cache緩存的配置。
DNS cache配置
對于DNS緩存來說，最重要的一項就是DNS資源記錄（Resource Record）的TTL。影響TTL的因素很多，一般預設在DNS記錄建立的時候，我們必須指定對應記錄的TTL時間，或者使用對應DNS zone的預設值。當我們配置轉發器（Forwarder）時，該伺服器作為非權威DNS服務需要關注緩存的配置。Windows DNS server和Linux Bind各自有不同的配置項，具體如下：
Windows：
Possitive cache: dnscmd /config /MaxCacheTtl
Negative cache: dnscmd /config /MaxNegativeCacheTtl
cache size: dnscmd /config /MaxCacheSize
Linux Bind：
max-cache-ttl
max-ncache-ttl
max-cache-size
lame-ttl
注：在配置轉發器（Forwarder）的時候，要特别注意緩存時間，因為該伺服器所有可以提供解析的記錄基本都在緩存中，如果緩存更新不及時、或者造成Lame Delegation，那可能會帶來查詢異常等問題。例如，在2012之前的Windows DNS server上，預設的DNS Max Cache TTL為172800s，錯誤的配置可能會帶來意外的解析問題。
DNS響應
現今網際網路上DNS已經是流量管理的重要手段，智能流量排程等功能最開始是從修改DNS響應開始。通過對DNS響應結果的調整，可以根據地理位置來負載不同地域的用戶端通路請求，或者是智能地判斷伺服器DNS請求的數量來估計負載情況，進而進行負載均衡等操作。基礎版的DNS服務也有相關的配置項可供選擇：
Windows：
Round robin: dnscmd /config /RoundRobin
Netmask Ordering: dnscmd /config /LocalNetPriority
DNS Policies相關内容可參考文後資料了解詳情（2）
Linux Bind：
response-policy相關内容可參考文後資料了解詳情（3）
rrset-order
sortlist
由于用戶端一般總是使用第一個A，是以，調整響應結果的順序可以從一定程度上達到流量調整的目的。
EDNS支援
Windows：
dnscmd /config /EnableEDnsProbes
Linux Bind：
預設bind 9.10以上版本支援Edns0
EDNS協定按标準來說就是在遵循已有的DNS消息格式的基礎上增加一些字段，來支援更多的DNS請求業務。EDNS标準協定最著名的功能是支援超過512位元組的udp消息，即Edns0。沒有Edns0，DNS使用tcp來完成超過512位元組的響應接收。無論是提供解析結果的DNS伺服器，還是中間DNS轉發器（Forwarder）服務，都推薦關注DNS伺服器上是否開啟EDNS，以及檢查EDNS是否符合規範。EDNS(0)的RFC文檔（4）以及去年國際知名廠商發起的DNS Flag Day活動（5）、Client subnet in DNS requests草案（6）等相關資訊，可參考文後資料了解詳情。
DNSSEC支援
Windows：
dnscmd /config /EnableDnsSec
Linux Bind：
named.conf 配置：
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
DNSSEC協定在DNS服務上實作，是通過查詢NSEC等Resource Record，來驗證DNS響應是否經過篡改。如果驗證通過，則将解析結果經過正常的DNS Recursive Query Response傳回給用戶端。目前應該還沒有特别多的DNSSEC的需求，但是考慮到已經有一部分國外的網站域名已經開啟了DNSSEC，我們可能需要對此進行了解。當然，在發生DNSSEC查詢異常的情況下可以考慮在DNS轉發器（Forwarder）上禁用DNSSEC來回退到普通遞歸、疊代查詢。注：DNS用戶端不參與DNSSEC的驗證過程。DNSSEC如何工作可參考文後資料進行參考（7）。
以上就是本次DNS規範化的全部内容，不過想要透徹地了解各産品，最好的辦法是閱讀相應的産品文檔，可參考文後資料了解詳情（8），（9），希望能夠對讀者有所幫助。
參考資料：
（1）DNS RFC：
https://www.ietf.org/rfc/rfc1035.txt（2）Windows DNS Policies Overview：
https://docs.microsoft.com/en-us/windows-server/networking/dns/deploy/dns-policies-overview（3）DNS Response Policy Zones：
https://dnsrpz.info/（4）EDNS(0)的RFC文檔：
https://tools.ietf.org/html/rfc6891（5）去年國際知名廠商發起的一個比較著名的活動DNS Flag Day：
https://dnsflagday.net/2019/（6）Client subnet in DNS requests草案：
https://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-01（7）DNSSEC如何工作：
https://www.cloudflare.com/dns/dnssec/how-dnssec-works/（8）Windows産品文檔：
https://docs.microsoft.com/en-us/windows-server/networking/dns/dns-top（9）Linux Bind産品文檔：
https://docs.freebsd.org/doc/8.2-RELEASE/usr/share/doc/bind9/arm/Bv9ARM.html作者：陳鴿
阿裡雲智能GTS-SRE團隊技術專家
曾就職于微軟負責Windows作業系統網絡協定棧及網絡産品技術支援相關工作，了解各産品标準協定例如TCPIP、DNS等。現就職于阿裡雲智能GTS-SRE團隊，負責專有雲網絡相關産品（SLB/VPC等）的高可用、高可靠運維。
我們是阿裡雲智能全球技術服務-SRE團隊，我們緻力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基于雲建構更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運作更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿裡雲SRE技術學院釘釘圈子，和更多雲上人交流關于雲平台的那些事。
