DNS記錄消失了！不要慌張，沒有這么可怕，你首先要做的是找到不見的DNS記錄（上文所述），現在你已經鎮定了些，那么就和我們一起來看看如何修復消失的DNS記錄吧！

修復“損壞”或錯誤的DNS記錄

如果DNS記錄損壞或者沒有及時更新，可以用動態注冊來輕松地修復問題。例如，用于映射服務器GUID到服務器FQDN的DNS別名記錄常用于AD復制。恢復或重裝DC可能導致復制了沒有清理老記錄的別名記錄。如果有多個別名記錄，或該記錄是錯誤的，那么刪除這些問題記錄，服務器會重新登錄正確的記錄。這通常花費15分鐘，但是你可以重啟Netlogon服務來更快地反饋。記住刷新DNS管理單元來查看新記錄。所有記錄類型都能用這種方法來注冊正確的記錄。

修復“消失”DNS區

一名管理員正在試著從DC上清除DNS。他錯誤地從該DC上的單元處刪除了DNS區。他忽略了這會從AD上移除區的警告。幾分鐘內，整個生產DNS區都不見了...天啊！消失了！他正在思量著尋找下一份工作，但是我向他保證這可以輕松修復，這多虧了動態注冊。我們簡單地重建了DNS區，在每個DC上重啟Netlogon，然后區就重新構成了。有一些靜態A記錄必須要手動輸入，但是他擁有這些信息。我并不建議這作為一個解決方法，但是當整個區被清洗（有意義記錄和名稱解析在各臺DNS服務器上不一致）時我確實用到它了。刪除該區并讓DC重新注冊。

恢復損壞ADI區

雖然綜合活動目錄（ADI）基礎DNS功能（它在活動目錄中存儲區文件）比標準DNS更快、更高效，但它也有一些缺點：

區文件不是磁盤上一個簡單的文本文件，且只能用訪問AD的工具來查看和操作。

不同的復制范圍在AD中的不同位置存儲區文件，這讓定位DNS記錄非常困難。

ADI區變“損壞”因為DNS記錄不是在所有DC上都一致，給了DNS查詢不一致的結果。

假設你不想毀掉整個區，如果你懷疑ADI區中有損壞（在域名解析中的不致行為），有一個很酷的技巧可以讓ADI（多基礎）重回正軌。

確定一個正確的名稱服務器來用作新來源（選取PDC模擬器或查看DNS錯誤、性能等等）。

進入DNS管理單元-區屬性。選擇區類型并配置區到標準DNS區（見這里）。通過不選“”在活動目錄中存儲區“選項可以完成該動作。這將DNS信息從AD轉儲到該DC硬盤上的文本區文件。

進入另一個DC/名稱服務器-DNS管理單元，然后刪除該區。這將從活動目錄中刪除它（會有一提示）。

等待復制然后檢查每個DC/名稱服務器來確保該區從AD中消失。你也可以運用LDP并查看AD中的3個位置（表1所示）來確保那里沒有DNS記錄。如果你看到它們，那么你就沒有刪除該區或者復制沒有完成。

當DNS從AD中消失時，讓它保持這種配置兩三天。現在你擁有一個單一來源（控制），所以可能不會有不一致。確保所有工作都正常。創建一個指向該名稱服務器的標準次級區作為控制是一個不錯的主意，那么你在這個過渡期間就能擁有更好的名稱解析性能了。

將標準基礎更改至ADI區。進入DNS單元-區-屬性-輸入并檢查“在活動目錄中存儲該區”選項。

在區屬性中-復制-選擇想要的復制范圍（見這里）。

將次級區更改到ADI區：

在每臺名稱服務器上從DNS單元刪除次級區，重啟DNS，它會自動登錄。你可能需要在名稱服務器上重建該區，然后它會自動完成。或者，重啟DC。是的，重啟托管次級DNS區的DC，ADI Primary會在它備份時將次級區變更到ADI。

消失的區（故意的）

我曾經遇到過管理員聲稱自己的DNS區只消失了一段時間（有時是一兩天，有時是一周）的情況。查看每個DC/名稱服務器上的DNS單元，區消失了。這實際上是故意的，而且是根據以上的七個步驟。在這種情況下，管理員有一個標準的基礎-次級配置，并且決定遷移到一個ADI Primary配置。當標準基礎區變成ADI基礎時，所有DC必須托管一個ADI基礎區。他們會在重啟前保留次級區，因為該信息在放在內存中。重啟后，ADI區會在所有DC/名稱服務器上重新構成。

在ADI基礎區中擁有次級區是允許的，但是他們必須托管在成員服務器上，而不是在DC上。這讓DNS服務器可以放置在不需要DC的遠程站點。

雖然多控制復制和綜合活動目錄（多基礎）區功能集優點與缺點于一身，了解它們工作的方式會為AD管理員在解決這些問題時節省很多時間和精力。