書接上回，在上一篇內容中重點剖析了互聯網DNS體系及造成權威DNS變更復雜的主要原因，今天我們通過搭建實驗環境，研究權威DNS的原理及細節。enjoy：
在介紹實驗過程之前，先直接說結論，建議爲權威NS記錄變更預留2天時間是一個相對保險的建議值，可以確保全網絕大部分LocalDNS都會刷新。若超過這個時間後仍有問題，需要考慮其他可能的原因。實際上從工程經驗看，域名變更後大部分ISP和Public DNS最多在1-2小時後就可以刷新。
P.S. 若需要變動的是edu.cn、gov.cn等結尾的域名，建議提前聯繫域名註冊管理機構進行流程和手續的諮詢，切記~
1. 基本原理及實驗
之前的文章中，從互聯網DNS體系並不能看出DNS的實際運行機制，因此我們首先搭建實驗環境來進行模擬，在此基礎上研究權威DNS的原理及細節。
1.1 搭建實驗環境
實踐是驗證理論的唯一標準。很多人經過初步的學習後，對互聯網DNS的體系有了一定的瞭解，但是不能解答之前的疑問，爲什麼DNS的收斂時間如此之長，問題出在哪個地方？每個環節的配置和參數對於整體的影響分別是什麼？
帶着這些疑問我們搭建了互聯網DNS的模擬環境，由1臺根DNS（兼職頂級域）、2臺權威DNS和1臺遞歸DNS組成。
所有DNS不做特殊設置，均爲通用配置。測試的域名區域爲test.com，配置NS記錄及www域名記錄。
測試根DNS配置根區及com頂級域；
com. 1800 IN NS ns.com.
ns.com. 1800 IN A 192.168.30.135
ns1.test.com. 660 IN A 192.168.30.136
test.com. 600 IN NS ns1.test.com.
ns2.test.com. 660 IN A 192.168.30.137
test.com. 600 IN NS ns2.test.com.
測試權威DNS配置test.com權威區域（記錄相同TTL不同，便於識別）；
權威DNS 01：
test.com. 120 IN NS ns1.test.com.
ns1.test.com. 140 IN A 192.168.30.136
ns2.test.com. 140 IN A 192.168.30.137
test.com. 120 IN NS ns2.test.com.
www.test.com. 160 IN A 1.2.3.4
權威DNS 02：
test.com. 240 IN NS ns1.test.com.
ns1.test.com. 260 IN A 192.168.30.136
ns2.test.com. 260 IN A 192.168.30.137
test.com. 240 IN NS ns2.test.com.
www.test.com. 300 IN A 1.2.3.4
測試遞歸DNS將根服務器設置爲測試根DNS，不使用默認的13個根；
測試客戶端無特殊設置，使用DIG、NSLOOKUP等工具進行測試並抓包；
以上就是本次搭建的實驗環境及其關鍵配置。
1.2 實驗原理及路線
根權威、頂級域權威、二級及以上級域權威、遞歸是互聯網DNS體系的組成部分，根權威包含1000多個頂級域NS記錄，頂級域權威包含歸屬於其區域的二級域名權威DNS的NS記錄，依次類推，而負責從各級權威獲取信息直至完成域名解析的就是遞歸服務器。爲了確保分級的、複雜的流程下信息的準確傳遞，DNS協議設計了很多保證措施，並最終由DNS軟件來實現。
遞歸DNS會從不同級別的權威DNS上獲取NS記錄併發起迭代查詢，直至最終獲取到需要的域名記錄的解析結果。在實際使用過程中，遞歸DNS會從上級權威獲取下級權威的NS記錄（包括記錄名稱和Gelu IP），同時也會從下級權威DNS獲取其NS記錄，這兩個記錄很可能是不一致的，這就是本次實驗主要驗證的內容。
實驗步驟如下：
1) 在測試頂級域DNS上只配置test.com的NS記錄ns1，指向測試權威DNS 01，並在權威DNS 01上也只配置ns1，在測試客戶端上觀察解析結果；
2) 在權威DNS 01上配置第二個NS記錄ns2，等測試域名記錄www.test.com過期後，在測試客戶端上觀察解析結果；
3) 在測試頂級域DNS上添加test.com的NS記錄ns2，指向測試權威DNS 02，並關閉測試權威DNS01，等測試域名記錄www.test.com過期後，在測試客戶端上觀察解析結果；
1.3 實驗過程
首先清除遞歸DNS和操作系統上的緩存記錄（不光遞歸DNS有緩存，還有瀏覽器緩存和操作系統(OS)緩存，不清除緩存可能會影響實驗結果）。
在測試頂級域DNS上只配置test.com的NS記錄ns1，指向測試權威DNS 01，並在權威DNS 01上也只配置ns1。測試客戶端結果如下：
在權威DNS 01上配置第二個NS記錄ns2，等測試域名記錄www.test.com過期後，在測試客戶端上觀察解析結果如下：
在測試頂級域DNS上添加test.com的NS記錄ns2，指向測試權威DNS 02，並關閉測試權威DNS01，等測試域名記錄www.test.com過期後，在測試客戶端上觀察解析結果如下：
上述測試爲連續測試，每次均等待 www.test.com的A記錄過期後重新進行查詢。
1.4 實驗結論及分析
由該實驗可得出以下推論：
本實驗中遞歸DNS最終使用從本級權威DNS上獲取的NS記錄TTL，並以此爲準。實際上有一個更貼切的說法是以上級權威和本級權威的TTL最小值爲準。實驗中是本機權威配置的NS記錄TTL小於上級權威的NS記錄TTL，反過來的話效果如下：
在上級權威和本級權威的NS記錄配置不一致時，以本級權威的NS記錄爲準。（例如實驗中上級權威未配置ns2但本級權威DNS上有配置ns2，且被遞歸DNS獲取並使用）
遞歸DNS上的NS記錄過期後，一旦有不命中緩存的查詢出現，遞歸DNS會到上級權威開始重新查詢該區域的NS記錄。命中緩存的查詢則直接回復，不會去上級權威查詢更新NS記錄。下圖爲命中記錄緩存的查詢效果。
上級權威服務器中，變更域名的NS記錄生效後，最長不超過本機權威的NS記錄TTL時間，遞歸DNS就會更新該域名的最新NS記錄。
那麼是不是我們可以選擇不改註冊NS記錄直接改權威DNS就可以了呢？答案是否定的，測試的話在確保記錄一致性的情況下可以這麼做，但正式變更還是要按照先增後減的原則來進行，要的就是一個字，穩。
遞歸DNS有一個很複雜的運行機制，而且每個不同的遞歸DNS軟件甚至不同版本都會有細微的差距，再加上權威DNS的配置差異（例如是否開最小應答）、LAME Server（簡單來說就是對權威NS的主動標記拉黑機制）、DNS緩存強制修改（有些流氓DNS會這麼幹）、遞歸強制解析等因素，按照上述結論去使用是不太穩的。
特別是一旦註冊的NS記錄不能用時，等同於全部NS故障，權威DNS服務將會中斷，所有在線業務會受到很大影響。
而一旦錯誤配置的權威NS記錄或域名記錄在互聯網DNS體系中擴散，Hmm……那種等待收斂的無力你感絕對不會想體會第二次。雖然可以通過刷ISP的遞歸緩存的方式快速收斂，但這個方式的使用難度和費用是個問題。
1.5 從試驗結果展開的一點小思考
實驗中的模擬結構是一個理想模型，但是在實際的互聯網上，在遞歸DNS下面往往還有其他的LocalDNS，如轉發服務器、緩存服務器等，那麼這個TTL時間傳遞到客戶端後可能跟權威的設置沒有什麼太大關係，此時傳遞給最終客戶端的TTL主要取決於這些DNS服務器的配置。比如最小TTL的限制爲3600秒，即便該DNS服務器從遞歸DNS上查詢到的域名記錄TTL只剩30秒，也會被強制修改爲3600並返回給查詢者。
這個場景並不少見，ISP和Public的DNS大部分都是遞歸緩存分離的，再加上二級運營商或企事業單位自建的DNS採用全區轉發的查詢策略（降低服務器負載），最終從客戶端到權威DNS服務器之間可能有3個或以上的DNS服務器，此時這個TTL生效時間跟權威的設置會有很大的區別
依次類推，實際上權威記錄變更可能需要更長的時間纔會被客戶端感知，即便權威DNS上配置60甚至更小的TTL也是這樣！如果不能容忍這個問題，APP類的應用可以選擇使用HTTP DNS的方式來避開，附贈一大堆好處，此處略。
（未完待續）
關於ZDNS
互聯網域名系統國家工程研究中心（簡稱ZDNS）是國家發改委批覆的國家級工程研究中心，是工信部批准的根鏡像運行機構，是中科院孵化的專注於域名領域的高新技術企業；ZDNS連續四年在DDI（DNS、DHCP、IPAM）設備領域市場佔有率第一，服務金融、廣電、教育、政府、軍工、醫療、互聯網等多個行業，全球近千家大型企業。