針對 DNS 事件識別碼 4013 進行疑難解答 (DNS 伺服器無法載入 AD 整合的 DNS 區域)

本文會解析 Windows 啟動後裝載 DNS 伺服器角色之域控制器的 DNS 事件記錄檔中所記錄的事件識別碼 4013。

適用:Windows Server 2012 R2
原始 KB 編號: 2001093

徵狀

  • 在裝載 Active Directory 域控制器的 Windows 計算機上,DNS 伺服器角色會停止回應 15 到 25 分鐘。 此問題會在顯示 [準備網络連線 ] 訊息之後,以及在 Windows 登入提示 (Ctrl+Alt+Del) 顯示之前發生。

  • 下列 DNS 事件識別碼 4013 會記錄在 Windows 啟動後裝載 DNS 伺服器角色之域控制器的 DNS 事件記錄檔中:

    Event Type: Warning  
    Event Source: DNS  
    Event Category: None  
    Event ID: 4013  
    Date: Date  
    Time: Time  
    User: N/A  
    Computer: ComputerName  
    Description:  
    The DNS server was unable to open the Active Directory. This DNS server is configured to use directory service information and can not operate without access to the directory. The DNS server will wait for the directory to start. If the DNS server is started but the appropriate event has not been logged, then the DNS server is still waiting for the directory to start.
    
    For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.  
    Data:  
    0000: <%status code%>
    

    在此記錄專案中 <,可能不會記錄 %Status code% 的> 值。 或者,它們包含但不限於下列值:

    Hex 位元組 小數 符號 錯誤字串
    000025f5 f5 25 00 00 9717 DNS_ERROR_DS_UNAVAILABLE 目錄服務無法使用
    0000232d 2d 23 00 00 9005 DNS_ERROR_RCODE_REFUSED DNS 作業被拒。
    0000232a 2a 23 00 00 9002 DNS_ERROR_RCODE_SERVER_FAILURE DNS 伺服器失敗。

範例客戶案例

  • 同時重新啟動之 Active Directory 站台中的多個域控制器。

    • 兩個域控制器網域會部署在相同的數據中心。
    • DNS 伺服器角色會安裝在這兩個域控制器上,並裝載與 AD 整合的_msdcs複本。<樹系根域> 和 Active Directory 網域區域。
    • DC1 已設定為針對慣用 DNS 使用 DC2,並將其本身用於替代 DNS。
    • DC2 已設定為針對慣用 DNS 使用 DC1,並將其本身用於替代 DNS。
    • 所有域控制器都有不間斷的電源供應器, (UPS) 和發電機備份。
    • 數據中心經常發生 2 到 10 小時的電源中斷。 UPS 裝置會讓域控制器保持運作,直到產生器提供電源,但無法執行 HVAC 系統。 當內部溫度達到製造商限制時,伺服器類別計算機內建的溫度保護會關閉域控制器。
    • 最終還原電源時,域控制器會停止回應 20 分鐘。 此問題會在 [準備網络連線] 顯示之後,以及在顯示登入提示之前發生。
    • DNS 事件識別碼 4013 會記錄在 DNS 事件記錄檔中。

    開啟 DNS 管理主控台 (DNSMGMT。MSC) 失敗,併產生下列錯誤訊息:

    無法連絡伺服器 <計算機名稱> 。 錯誤為:伺服器無法使用。 您還是要新增嗎?

    在 DSA (開啟 Active Directory 使用者和電腦 嵌入式管理單元。MSC) 會產生下列錯誤訊息:

    找不到命名資訊

  • Active Directory 網站中的單一域控制器

    • 一個域控制器會部署在站臺中。

    • 已安裝 DNS 伺服器角色,並裝載與 AD 整合的_msdcs複本。<樹系根域> 和 Active Directory 網域區域。

    • 域控制器會針對慣用的 DNS 指向本身。

    • 域控制器沒有指定的替代 DNS 伺服器,或透過廣域網 (WAN) 連結指向域控制器。

    • 域控制器會因為電源中斷而重新啟動。

    • 在重新啟動期間,WAN 連結可能無法運作。

    • 域控制器啟動時,可能會停止回應 20 分鐘。 此問題會在 [準備網络連線] 顯示之後,以及在顯示登入提示之前發生。

    • DNS 事件識別碼 4013 會記錄在 DNS 事件記錄檔中。

    • 開啟 DNS 管理主控台 (DNSMGMT。MSC) 失敗,併產生下列錯誤訊息:

      無法連絡伺服器 <計算機名稱> 。 錯誤為:伺服器無法使用。 您還是要新增嗎?

    在 DSA (開啟 Active Directory 使用者和電腦 嵌入式管理單元。MSC) 會產生下列錯誤訊息:

    找不到命名資訊。

原因

某些域控制器中的 Active Directory 複本包含樹系中其他域控制器的參考。 這些域控制器會嘗試在 Windows 啟動期間輸入複寫所有本機保留的目錄分割區,作為初始同步處理或 init 同步處理的一部分。

為了嘗試以最新的 DNS 區域內容開機,裝載 DNS 區域之 AD 整合複本的 Microsoft DNS 伺服器會在 Windows 啟動後延遲 DNS 服務啟動數分鐘。 如果 Active Directory 已在 Windows 啟動期間完成初始同步處理,則不會發生延遲。 同時,Active Directory 會因為輸入複寫目錄分割區而延遲。 復寫會延遲,直到它可以將來源域控制器的 CNAME GUID 解析為目的地域控制器用於名稱解析之 DNS 伺服器上的 IP 位址為止。 準備網路連線時停止響應的持續時間取決於位於域控制器 Active Directory 複本中的本機保留目錄分割區數目。 大部分的域控制器至少有下列五個分割區:

  • 模式
  • 配置
  • 網域
  • 全樹系 DNS 應用程式分割區
  • 全網域 DNS 應用程式分割區

而且這些域控制器可能會遇到 15-20 分鐘的啟動延遲。 額外的分割區存在會增加啟動延遲。

DNS 事件記錄檔中的 DNS 事件識別碼 4013 表示 DNS 服務啟動已延遲。 這是因為未發生 Active Directory 磁碟分區的輸入復寫。

多個條件可能會使下列問題更加嚴重:

  • Windows 啟動速度緩慢
  • DNS 伺服器上設定為裝載 AD 整合區域的 DNS 事件 4013 記錄,其隱含地位於作為域控制器的電腦上。

這些條件包括:

  • 設定裝載 AD 整合式 DNS 區域的 DNS 伺服器。 其 Active Directory 複本包含樹系中其他域控制器的知識,以獨佔方式指向本身以進行 DNS 名稱解析。
  • 設定裝載 AD 整合式 DNS 區域的 DNS 伺服器。 其 Active Directory 複本包含樹系中其他域控制器的知識,可指出 DNS 伺服器不存在、目前離線、無法在網路上存取,或未裝載輸入複寫 Active Directory 所需的必要區域和記錄。 範例包括域控制器 CNAME GUID 記錄及其對應的主機 A 或潛在來源域控制器的 AAAA 記錄。
  • 啟動裝載 AD 整合式 DNS 區域的域控制器和 DNS 伺服器。 其 Active Directory 複本包含其他域控制器的知識,這些域控制器實際上就是隔離的網路,因為:
    • 呼叫端或目標電腦上的網路適配器或網路堆疊已停用或無法運作。
    • 域控制器已在隔離的網路上開機。
    • 本機域控制器的 Active Directory 複本包含不再存在於網路上的過時域控制器參考。
    • 本機域控制器的 Active Directory 複本包含目前已關閉之其他域控制器的參考。
    • 來源域控制器、目的地域控制器或 DNS 或網路基礎結構發生問題。 因此,本機域控制器的 Active Directory 複本包含其他域控制器的參考,這些域控制器在在線且可存取,但無法成功從中複寫。

在 Windows Server 2003 和 Windows 2000 Server SP3 或更新版本中,裝載作業主機角色的域控制器也必須成功復寫維護作業主機角色狀態之目錄分割區的輸入變更。 必須先成功複寫,才能執行 FSMO 相依作業。 已新增這類初始同步處理,以確保域控制器同意 FSMO 角色擁有權和角色狀態。 FSMO 角色運作所需的初始同步處理需求,與本文中討論的初始同步處理不同,在本文中,Active Directory 必須進行輸入複寫,才能立即啟動 DNS 伺服器服務。

解決方案

某些 Microsoft 和外部內容建議將登錄值 Repl Perform Initial Synchronizations 設定為 0 ,以略過 Active Directory 中的初始同步處理需求。 特定登入子機碼和該設定的值如下:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
值名稱:Repl 執行初始同步處理
實值類型:REG_DWORD
數值資料:0

不建議在生產環境中或任何環境中持續使用此組態變更。 只有在要解決暫時和特定問題的重要情況下,才應該使用 Repl Perform Initial Synchronizations 的 。 解決這類問題之後,應該還原預設設定。

其他可行的選項包括:

  • 拿掉過時域控制器的參考。

  • 讓離線或無法運作的域控制器運作。

  • 裝載 AD 整合式 DNS 區域的域控制器不應該指向單一域控制器,特別是只指向自己作為名稱解析的慣用 DNS。

    域控制器的 DNS 名稱註冊和名稱解析是相對輕量的作業,DNS 用戶端和伺服器會高度快取。

    將域控制器設定為指向單一 DNS 伺服器的 IP 位址,包括 127.0.0.1 回送位址,代表單一失敗點。 此設定可在只有一個域控制器的樹系中容許,但不能在具有多個域控制器的樹系中執行。

    中樞月臺域控制器應該指向與它們位於相同站台中的 DNS 伺服器,以作為慣用和替代 DNS 伺服器,最後指向本身作為另一個替代 DNS 伺服器。

    分支月臺域控制器應設定慣用的 DNS 伺服器 IP 位址,以指向中樞月臺 DNS 伺服器、替代 DNS 伺服器 IP 位址,以指向月臺內 DNS 伺服器或最接近可用站台中的 DNS 伺服器,最後使用 127.0.0.1 回送位址或目前的靜態 IP 位址指向本身。

    指向中樞月臺 DNS 伺服器可減少取得重要域控制器 SRV 和主機記錄完整註冊所需的躍點數目。 中樞網站內的域控制器通常最常受到系統管理注意,通常在同一個站台中擁有最大的域控制器集合。 因為它們位於相同的站臺中,所以會在彼此之間複寫變更:

    • Windows Server 2003 或更新版本中每隔 15 秒
    • 在 Windows 2000 Server 中每隔五分鐘

    此行為可讓這類 DNS 記錄成為已知的。

    如果分支站台中註冊的域控制器無法輸出複寫,動態域控制器 SRV 和主機 A 和 AAAA 記錄註冊可能無法離線。

    成員計算機和伺服器應該繼續指向月臺最佳 DNS 伺服器作為慣用的 DNS。 而且它們可能會指向異地 DNS 伺服器,以進行額外的容錯。

    您的最終目標是防止所有專案造成阻斷服務,同時平衡成本、風險和網路使用率,例如:

    • 複寫延遲和複寫失敗
    • 硬體失敗,軟體失敗
    • 作業實務
    • 短期和長期電源中斷
    • 火災、竊取、水流和地震
    • 會發生事件
  • 例如,請確定目的地域控制器可以使用 DNS (解析來源域控制器,避免後援) 。

    您應該確保域控制器可以成功解析引導式 CNAME 記錄,以裝載目前和潛在來源域控制器的記錄。 這樣做可避免名稱解析後援邏輯所導入的高延遲。

    網域控制器應該指向下列 DNS 伺服器:

    • 可在 Windows 啟動時取得。
    • 裝載、轉送或委派_msdcs。<目前和潛在來源域控制器的樹系根域> 和主要 DNS 後綴區域。
    • 可以解析目前的 CNAME GUID 記錄 (例如, dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com) 目前和潛在來源域控制器的主機記錄。

    遺漏、重複或過時的 CNAME 和主機記錄都會造成此問題。 默認不會在 Microsoft DNS 伺服器上啟用清除功能,這會增加過時主機記錄的機率。 同時,DNS 清除可能設定太積極,導致有效記錄提前從 DNS 區域清除。

  • 優化域控制器的名稱解析後援。

    無法正確設定 DNS,讓域控制器可以解析域控制器 CNAME GUID 記錄以在 DNS 中裝載記錄是很常見的。 為了確保 Active Directory 磁碟分區的端對端復寫,已修改 Windows Server 2003 SP1 和更新版本的域控制器,以執行名稱解析後援:

    • 從域控制器 CNAME GUID 到完整主機名。
    • 從完整主機名到 NetBIOS 計算機名稱。

    目錄服務事件記錄檔中的 NTDS 複寫事件識別碼 2087 和 2088 表示:

    • 目的地域控制器無法將域控制器 CNAME GUID 記錄解析為主機記錄。
    • 名稱解析後援正在發生。

    WINS、HOST 檔案和 LMHOST 檔案都可以設定。 因此,目的地域控制器可以解析目前和潛在來源域控制器的名稱。 在三個解決方案中,WINS 的使用比較可調整,因為 WINS 支援動態更新。

    計算機的IP位址和名稱難免會過時。 此問題會導致 HOST 和 LMHOST 檔案中的靜態專案在一段時間內變成無效。 發生此問題時,可能會將某個域控制器的查詢不正確地解析為另一個域控制器。 而且在網路追蹤中不會觀察到任何名稱查詢。

  • 將 DNS 伺服器服務的啟動值變更為手動,以在開機時變成已知的不正確組態。

    如果在本文討論的已知錯誤組態中開機域控制器,請遵循下列步驟:

    1. 將 [DNS 伺服器服務啟動] 值設定為 [手動]。
    2. 重新啟動,等候域控制器通告。
    3. 重新啟動 DNS 伺服器服務。

    如果 DNS 伺服器服務的服務啟動值設定為手動,Active Directory 就不會等待 DNS 伺服器服務啟動。

其他考量

  • 避免單一失敗點。

    單一失敗點的範例包括:

    • 設定 DC 以指向單一 DNS 伺服器 IP
    • 將所有 DNS 伺服器放在相同實體主電腦上的客體虛擬機上
    • 將所有 DNS 伺服器放在相同的實體站台中
    • 限制網路連線能力,讓目的地域控制器只有單一網路路徑可存取 KDC 或 DNS 伺服器

    安裝足夠的 DNS 伺服器來提供本機、區域和企業範圍的備援效能,但不會安裝太多 DNS 伺服器,讓管理成為負擔。 DNS 通常是由 DNS 用戶端和 DNS 伺服器高度快取的輕量型作業。

    在現代化硬體上執行的每個 Microsoft DNS 伺服器可以滿足每部伺服器 10,000-20,000 個用戶端。 在每個域控制器上安裝 DNS 角色可能會導致您企業中的 DNS 伺服器數量過多。 這麼做會增加成本。

  • 盡可能錯開企業中 DNS 伺服器的重新啟動。

    • 安裝某些 Hotfix、Service Pack 和應用程式可能需要重新啟動。
    • 有些客戶會依排程重新啟動域控制器 (每隔 7 天,每隔 30 天) 一次。
    • 以智慧方式排程重新啟動,以及安裝需要重新啟動的軟體。 這麼做可防止目的地域控制器為了進行名稱解析而指向的唯一 DNS 伺服器或潛在來源複寫夥伴同時重新啟動。

    如果 Windows Update 或管理軟體正在安裝需要重新啟動的軟體,請錯開目標域控制器上的安裝,讓域控制器指向的一半可用 DNS 伺服器同時重新啟動名稱解析。

  • 在策略性位置安裝 UPS 裝置,以確保短期電源中斷期間的 DNS 可用性。

  • 使用月台產生器來增強UPS支援的 DNS 伺服器。

    為了處理延伸中斷,某些客戶已部署現場電源發電機,讓密鑰伺服器保持在線狀態。 有些客戶發現產生器可以在數據中心內為伺服器提供電源,但無法在內部部署 HVAC 中開啟電源。 缺少空調可能會導致本機伺服器在內部計算機溫度達到特定閾值時關閉。

其他相關資訊

Active Directory 開發小組在 2010 年 5 月 10 日測試:

DNS 會等候NTDS,而且在目錄的初始複寫完成之前無法啟動。 這是因為最新的 DNS 資料可能尚未復寫到域控制器。 另一方面,NTDS 需要 DNS 來解析複寫來源域控制器的 IP 位址。 假設DC1指向DC2作為其 DNS 伺服器,而DC2則指向DC1作為其 DNS 伺服器。 同時重新啟動DC1和DC2時,由於相互相依性,啟動速度會變慢。 此緩慢啟動的根本原因是 DNSQueryTimeouts。

如果 DNS 伺服器服務在 NTDS 啟動時運作良好,NTDS 只會接受兩個 DNS 查詢來解析來源域控制器的 IP 位址:

  • 一個用於 IPv4
  • 另一個適用於 IPv6

而且這些 DNS 查詢幾乎會立即傳回。

如果 NTDS 啟動時無法使用 DNS 伺服器服務,NTDS 將需要傳送 10 個 DNS 查詢來解析 IP 位址:

  • 四個用於 GUID 型名稱
  • 四個用於完整名稱
  • 兩個用於單一標籤名稱

每個 DNS 查詢的延遲是由 DNSQueryTimeouts 控制。 根據預設,DNSQueryTimeouts 設定為 1 1 2 4 4。 這表示 DNS 用戶端會等候 12 (1 + 1 + 2 + 4 + 4) 秒,以取得 DNS 伺服器回應。 每個命名內容來源都需要 120 秒來解析 IP 位址。 假設有五個命名內容 (組態、架構、網域、ForestDnsZones、DomainDnsZones) ,以及一個單一復寫來源。 在此案例中,NTDS 需要 850 (170 X 5) 秒,或大於 14 分鐘才能完成初始復寫。

已完成數個測試來驗證上述行為。

  • 當 DNS 伺服器是第三個線上域控制器時,請重新啟動域控制器。 針對每個來源的每個命名內容,我們有兩個 DNS 查詢,而且它們幾乎會立即完成:

    in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com
    in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com  
    in resolveDnsAddressWithFallback  
    GUID based DNS name  
    in GetIpVxAddrByDnsNameW  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:31:40.534  
    end   GetAddrInfoW: 22:31:40.534  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:31:40.534  
    end   GetAddrInfoW: 22:31:40.534
    
  • 同時重新啟動DC1和DC2。 DC1 正在使用DC2 for DNS DC2 正在針對 DNS 使用 DC1。 針對每個來源的每個命名內容,我們有10個 DNS查詢,而每個查詢大約需要12秒:

    in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com  
    in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.microsoft.com  
    in resolveDnsAddressWithFallback  
    GUID based DNS name  
    in GetIpVxAddrByDnsNameW  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:37:43.066  
    end   GetAddrInfoW: 22:37:55.113  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:37:55.113  
    end   GetAddrInfoW: 22:38:07.131  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:38:07.131  
    end   GetAddrInfoW: 22:38:19.161  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:38:19.176  
     end   GetAddrInfoW: 22:38:31.185  
    FQDN  
    in GetIpVxAddrByDnsNameW  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:38:31.200  
    end   GetAddrInfoW: 22:38:43.182  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:38:43.182  
    end   GetAddrInfoW: 22:38:55.191  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:38:55.191  
    end   GetAddrInfoW: 22:39:07.216  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:39:07.216  
    end   GetAddrInfoW: 22:39:19.286  
    NetBios  
    in GetIpVxAddrByDnsNameW  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:39:19.286  
    end   GetAddrInfoW: 22:39:31.308d  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 22:39:31.308  
    end   GetAddrInfoW: 22:39:43.324
    
  • 為了進一步研究 DNSQueryTimeouts 與緩慢啟動之間的關聯性,DNSQueryTimeouts 設定為 1 1 2 4 4 ,讓 DNS 用戶端等候 31 (1 + 1 + 2 + 4 + 4) 秒。 在此測試中,等候時間為 31 秒:

    in I_DRSGetNCChanges, NC = CN=Configuration,DC=contoso,DC=com  
    in getContextBindingHelper, pszAddress = dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com  
    in resolveDnsAddressWithFallback  
    GUID based DNS name  
    in GetIpVxAddrByDnsNameW  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 18:06:48.143  
    end   GetAddrInfoW: 18:07:19.158  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 18:07:19.158  
    end   GetAddrInfoW: 18:07:50.162  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 18:07:50.162  
    end   GetAddrInfoW: 18:08:21.161  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 18:08:21.161  
    end   GetAddrInfoW: 18:08:52.158  
    FQDN  
    in GetIpVxAddrByDnsNameW  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 18:08:52.221  
    end   GetAddrInfoW: 18:09:23.231  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 18:09:23.231  
    end   GetAddrInfoW: 18:09:54.243  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 18:09:54.243  
    end   GetAddrInfoW: 18:10:25.239  
     in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 18:10:25.239  
    end   GetAddrInfoW: 18:10:56.243  
    NetBios  
    in GetIpVxAddrByDnsNameW  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 18:10:56.243  
    end   GetAddrInfoW: 18:11:27.244  
    in GetIpAddrByDnsNameHelper  
    start GetAddrInfoW: 18:11:27.244  
    end   GetAddrInfoW: 18:11:58.265