幾年前第一次接觸到活動目錄的時候，正是領導要求部署活動目錄的時候。雖然當時手頭上有幾本書，但是時間緊迫沒有來得及仔細研究。邊看著幫助邊運行dcpromo就開始活動目錄的部署了，相信不少人和我當年差不多，稀里糊涂的就開始當起了活動目錄的管理員。對于DNS，因為安裝會提示自動部署，相信很多人都不會在這方面下很多功夫（包括我原來也是）。我為此付出了不少代價－－因為不懂DNS所以遇到DNS的問題不知如何解決。我有保存論壇上感興趣帖子的習慣（顯然直接另存是保存不下來的），我保存有關DNS問題的帖子數量，占各種問題的第三位（我也很吃驚）。

　　但是論壇上也沒有很系統的關于DNS的總結（這畢竟是一個可以寫成一本書的很大的方面）。我通過對自己收藏的帖子和參考書的閱讀，加上自己經驗的總結得出一些操作方面的結論和總結。希望對大家能有所幫助，因為我不擅長DNS（在論壇上我也很少給朋友解決DNS問題），所以我想肯定有我寫錯的地方，我希望斑竹們能幫忙校正（我臉皮厚）。我的真正目的是通過這篇文章認識到我在DNS方面都存在哪些誤解（我還是挺有私心的）。

　　閑話少說，書歸正傳。

　　有過DNS域部署經驗的朋友都能感覺到，活動目錄的DNS、DHCP和WINS（用的不多了）和NetBios是息息相關的。也是很容易混淆的。所以很麻煩，通常我們開始部署AD的時候是在一個小公司里，大約有幾十臺電腦的局域網。人員流動不是很頻繁，所以的電腦也差不多的天天都開。很少有電腦會換地方，我們全都使用DNS的默認配置就可以很少會出問題。但這樣的地方我們不能待一輩子，我們來到一個相對復雜的網絡環境時，意識到自己缺乏對DNS的起碼常識，怎么辦？為了在遇到難題時能正確表述自己的問題（否則別人想幫你都沒辦法，除了UP我們更重要的是說清楚自己的問題和聽明白高手的意思）那么和我一樣從基礎開始吧。

　　什么樣的DNS系統是一個比較完美的系統呢？Dns服務器的連續性能提供出色的性能，減少WAN的通信，安全性也必須得到保障。

　　我們先從概念開始

　　1。DNS和活動目錄關系

　　DNS定義“命名空間”（名字空間）－－－微軟把例如“contoso.com”的東東叫命名空間，這個空間內的主機儲存在一個“區域文件”（zonefile）里－－－主要是一種映射的關系（中學數學就有映射的概念）

　　活動目錄的域（domain）“存儲域和域中的對象”，把用戶、租計算機帳戶記錄組注冊表的SAM里。－－－當然域不止這些內容。

　　DNS和域的結合－－完全合格域名（FQDN）：例如srv1.contoso.com－－說明了srv1主機位于contoso.com這個域里面。
注意：

　　DNS的結構中，頂級域com.的末尾是有一個句點"."的。DNS解析器是從左到右解析FDQN（看看上面FDQN的例子）的，最后到“.”結束。因為windows的DNS會自動在末尾添加“.”所以我們很容易忘了它的存在，在我們檢測DNS（尤其是命令行方式）最好加上末尾的這個"."正因為根域上有這個點，所以我們在林根的DNS上設置轉發的時候會發現那個轉發器的選現是灰的，不讓你設置，因為"."認為自己是根了，沒必要轉發。所以解決的方法是刪掉這個點，才能轉發（刪掉后就不會灰色可以選擇轉發了）。

　　如果沒有行政方面的要求你完全可以在域里使用例如devil.coco的域名稱，不一定非要.net或者.com.即使父域叫contoso.com，子域也可以叫devil.coco。

　　當一個企業在做DNS規劃時要注意。當企業外部服務（例如網站）需要在internet上注冊名稱（例如，公司.com）。如果企業內部使用活動目錄，那么要使內外部使用不同的名字或者內部的活動目錄使用外部名稱的一個子域。例如：“contoso.com”，作為企業在internet上的網站，使用www.contoso.com域名。內部的域可以使用contoso.net或者corp.contoso.com作為DNS名。如果不這么做將有可能使內部和外部名稱空間出現重疊。客戶端登陸域或訪問internet都將可能產生問題。尤其當涉及網絡地址轉換(NAT)并且外部IP地址處于內部客戶端夠不到的范圍中時就會有麻煩了(了解NAT的人應該知道,如果客戶端不配置可以正確解析外部地址的DNS是無法訪問相關網站的.)。

　　DNS和活動目錄使用各自不同的數據庫解析名字。關于這一點我覺得對于實際操作意義不大所以不說了有興趣的看看上面提到的那個帖子。

 

　　2。hosts文件

　　很多帖子里都有人回復說，看看那個hosts文件有沒有問題，或者說修改那個hosts文件里的什么地方（例如屏蔽QQ）。這是為什么？

　　hosts存在的目的：減少DNS服務器的工作量，如果客戶端查找的一個主機名在hosts文件里有記錄（說明不久前訪問過），那么客戶端就不必找Dns服務器了直接就知道了該主機的IP。我們可以用記事本打開hosts文件。找不到？一般在這里C:\WINDOWS\system32\drivers\etc這里除了hosts還有好幾個文件，也能用記事本打開。都是和TCP/IP相關的，詳細我就不說了跟DNS關系不大。

　　TTL（生存時間），DNS記錄必須有TTL，Hosts中得緩存超過了ttl就將被刪除，否則DNS得改變將無法在hosts文件中體現。

　　我們需要一個具體的例子：

　　有天，客戶發現srv1.contoso.com主機無法訪問了，我們查看DNS表，發現確實沒有相關A記錄了。我們手動添加了記錄，但是客戶還是抱怨無法訪問該主機――因為客戶端的緩存里里，還是認為該主機無法訪問。這時我們就必須在客戶的電腦上運行ipconfig/flushdns來清除緩存信息。是的，服務器也有緩存。服務器清理緩存的命令是dnscmd/clearcache
3．主Dns服務器和輔助名稱服務器

　　這個概念在論壇上也無數次的被提起，我覺得還是有必要說明一下的。照例我不會用很專業的詞匯，需要考MCSE的朋友最好不要看我寫的東西。

　　我是這樣認為的，DNS服務器把所有資源記錄到一個文件中（zonefile）。只有“主DNS服務器”能對該文件進行寫操作（能修改DNS記錄），輔助DNS服務器從主DNS服務器（或者其他輔助DNS服務器）那里獲得該文件的拷貝（默認24小時得不到拷貝的話，輔助Dns服務器就將失效）。

　　除此之外還有一種“僅緩存名稱服務器”（caching－onlynameserver），它上面僅保存緩存的查詢結果（從輔助Dns服務器那里獲得），以便使客戶端盡快獲得查詢信息。

　　這種機制讓人想起NT時代的主域控制器和備份域控制器――當然這是一種脆弱的機制。微軟為了能多湊合一些時間，允許任何運行DNS的DC都能被設置為它所在域的主Dns服務器。

　　4．權威性應答與非權威性應答

　　按照我的理解，如果DNS服務器在自己的區域文件里找到了客戶端需要查詢的記錄，就會返回一個權威性應答。―――例如客戶端要查找srv1.contoso.com主機的IP地址。在contoso.com的DC（也就是Dns服務器）上查找該主機的“A記錄”，我們找到了。就把記錄內容通過DNS應答的方式發還給客戶端，這就是一個權威性應答。――當然實際的查詢方式比較復雜遠沒有我說的這么簡單。

　　此外，如果Dns服務器最近被查找過該主機（可能其他客戶端也查找過）記錄，就會在緩存里找到記錄應答客戶端――當然上一種方法快。

　　如果該DC服務器找不到srv1.contoso.com主機的A記錄，就會返回（RecordNotFound）應答――同樣也是權威性應答

　　如果接到DNS查詢請求的服務器不是contoso.com的DC（Dns服務器），那么有3種方法處理該請求：

　　首先，查詢其他Dns服務器直到找到，然后此服務器將找到的內容返回給客戶端――非權威性應答

　　其次，推薦客戶端到上一級Dns服務器找。―――非權威性應答。

 

 

 

　　最后，如果原來被別人訪問過，本地有該緩存，那么用緩存里的數據回答―――非權威性應答。

　　說到這里就要講清楚，為什么會出現3種方法，為什么有的時候Dns服務器要努力幫客戶端查尋有的時候又只是打發到上層就不管了？
因為在客戶端查詢的請求里面包含一個“搜索類型”（Searchtype）的東東，一共有兩種狀態：

　　(1)遞歸查詢（Recursive），要求Dns服務器一定要救人救到底送佛送上西。反正我就賴上你了，你得給我查到。

　　(2)迭代查詢（Iterative），你（DNS服務器）如果找不到可以給我介紹到另一個DNS服務器那里去找――這種方式的客戶端就文明多了――自然Dns服務器的壓力就減輕了。

　　默認情況是遞歸查詢的，我們可以在Dns服務器參數配置禁用（高級選項）。

　　當DNS服務器被客戶端要求遞歸查詢而去查詢其他Dns服務器時，默認是迭代查詢的。

　　5.Netbios解析和DNS解析

　　對于兩者的概念我不想多做說明了，值得注意得是他們的查詢步驟。

　　假定我們啟用了Netbios解析，windows客戶端會按照下面的步驟進行解析（默認B節點配置可以修改為H節點）

　　（1）Netbios緩存

　　（2）Wins查詢

　　（3）Lmhosts文件（看看hosts的目錄）

　　（4）廣播

　　（5）hosts文件

　　（6）DNS

　　我們舉個例子，如果我們在客戶端ping一下srv1.contoso.com主機。我們通常的做法是運行cmd。輸入pingsrv1回車。這時發生了什么？

　　首先，客戶端會把計算機的DNS后綴附在名稱上發送到Dns服務器。

　　如果名字里有“.”存在，但是末尾并沒有“.”結束，系統會自動追加末尾“.”，如果這樣查詢也失敗了，就會向上面那樣追加DNS后綴再試。

　　如果添加DNS后綴也無法獲得主機記錄，那么系統就會追加事先為“接口”配置好得備用DNS后綴（仔細看看本地連接的屬性）。

　　不明白為什么要選擇“在域成員身份變化時，更改主DNS后綴”的朋友，和經常問“為啥我ping完整的名字才能ping通”的朋友有必要仔細研究一下。

　　我覺得有關DNS的問題范圍太大，短時間很難總結完。今天累了，下次繼續總結。有問題可以問，我說錯了的趕快指出來。明天還要上班接下來只能業余時間來補充了，爭取一周時間完成DNS的總結，自己也全當復習了，也希望能幫到昨天說“這也算是回答”的朋友。