“遞歸解析”是最常見的也是默認的一種解析方式。在這種解析方式中，如果客戶端配置的本地域名服務器（Local DNS服務器）不能解析的話，則后面的查詢過程全部由本地域名服務器代替DNS客戶端進行查詢，直到本地域名服務器從權威域名服務器得到了正確的解析結果，然后由本地域名服務器高速DNS客戶端查詢結果。

在整個遞歸查詢過沉重，除一開始客戶端向本地域名服務器發起查詢請求外，其余各個環節均以本地域名服務器為中心進行迭代查詢，DNS客戶端一直處于等待狀態，直到本地域名服務器發回最終查詢結果。相當于，在整個查詢環節中本地域名服務器承擔了中介代理的角色。

遞歸解析一般由各線路的運營商提供，因此無論是網站管理房還是權威解析方都無權對遞歸解析進行配置改動。但是在實際網站解析過程中，遞歸解析的效率往往是影響整個解析進程的關鍵所在。

說到遞歸解析的機制，不得不談及解析記錄中的一個關鍵詞：存活時間（TTL，time to live）。

TTL是指遞歸解析在獲取權威解析回答的解析記錄時，該條解析記錄在遞歸解析中緩存的有效時間，當時間超過TTL值，此條解析視為無效，新的訪問請求發送到遞歸解析時，遞歸解析將重新詢問此條解析記錄。

TTL值的設置存在一定的矛盾性：若管理員希望解析記錄高頻率刷新以保證地址修改效果能快速呈現到客戶端，或希望快速刷新掉因操作失誤或攻擊產生的錯誤地址，則需將TTL設置為較小值；如果服務器的地址穩定，且管理員希望客戶訪問網站能獲得更好的訪問體驗，而不是每次訪問都要經歷解析層層詢問的等待過程，則可將TTL設為較大值。

除TTL值會影響解析記錄的刷新外，遞歸解析的一種“偷懶”機制——互相詢問機制，也在其中扮演了重要角色。

當一條解析記錄失效但有新的訪問請求到來時，本應詢問權威解析的遞歸解析并不愿意按規章制度查找一遍權威地址，然后再長途跋涉去“老師家”尋求解答，反而傾向于找“身邊的同學”——也就是附近的其他遞歸解析，直接拷貝對方的解析記錄返回給訪客。

由于訪問機制的原因，遞歸解析已成為黑客們攻擊解析系統最方便的入手點之一。黑客的主要目的無外乎對DNS進行劫持或污染，解析緩存投毒是其中最常用的攻擊手段。根據上文提到的內容，如果TTL值設置較大，則緩存投毒將長期存在；如果TTL值設置較小，除了用戶訪問體驗會變差，由于遞歸解析互相詢問的機制，又會使緩存投毒在遞歸解析群落中反復傳遞，難以根除。

各地通信管理局會針對在使用的服務器不定期進行巡查，如果發現存在疑似存在遞歸解析服務行為，會通知到對應的服務商定期整改。排查的首要任務檢查服務器DNS服務端口（53端口）是否開放，可通過tcping命令查詢：

上圖代表53端口是開的，如果沒有運行相關業務，建議關掉。