尋找有關最佳實踐方法的一些意見。
- 目前，AD 網域已停用安全動態 DNS 更新（例如，任何用戶端都可以更新 DNS 記錄）。想要遠離這個。
- 50 多個遠端站點（透過 MPLS 連接，每個站點也都有 Internet 線路）—其中一些具有本地 DHCP 伺服器 (Windows)，許多具有在 Cisco 交換器上運行的 DHCP。只有大約 30-40% 的站點擁有本地 IT 員工。
- 有些用戶端指向 AD 的 DNS（但大多數網站沒有 AD 伺服器），其他用戶端則指向 BIND 解析器。將更多內容轉移到本地站點的 BIND 解析器，以處理站點 Internet 線路之外的 Internet 解析，從而為 SaaS 應用程式和 RPZ 提供最佳地理位置和效能。我們將 AD 區域從屬到 BIND 伺服器以提高效能和彈性。然而，如果用戶端指向 BIND，顯然動態 DNS 更新將無法運作。
我們正在努力標準化並盡可能保證安全。查看選項：
- 在 AD 中啟用安全 DNS 更新，並讓 DHCP 伺服器代表用戶端處理 DNS 名稱的更新。看起來這並沒有增加任何安全價值，因為任何人都可以發送帶有選項 81 標頭的 DHCP 請求。另外，不確定 Cisco 設備是否可以安全地更新動態 DNS（例如使用 Kerberos）。猜想不是。
- 與 #1 類似，但僅使用 MS DHCP 進行更新（在這種情況下，如果網站沒有伺服器基礎設施，則 DHCP 不一定位於辦公室本地）。
- 在每個網站取得 AD 伺服器，用戶端可將其用於主 DNS（和 DHCP）（並直接處理來自用戶端的安全 DNS 更新）。還有用於 Internet 查找的 BIND 伺服器。
- 與 #3 相同，但讓 AD 執行內部和 Internet 操作。然而，我們大量使用了 BIND 視圖，因此不確定這是否可行，除非我們遷移到 Server 2016（現在是 2012 年）。
大中型組織中的人都做什麼？
答案1
在我的1000 多個位置網路中，出於明顯的成本原因，我們很久以前就放棄了在每個位置設定AD DC，更不用說如果網路出現故障，用戶無論如何都無法完成任何工作，無論AD與否AD（工業系統單獨處理）。我們針對 DHCP/DNS 有多種方法，但主要的方法是：
- 專用設備上的集中式 DHCP（本質上包含 ISC DHCP 和 BIND）。它們使用特定的服務帳戶處理從選項 81 到 AD DNS 伺服器的動態 DNS 更新。在世界其他地方，這仍然使用 MS DHCP 來處理。我們並不特別信任在 DNS 中動態更新的名稱，但到目前為止還沒有感覺到需要更進一步，因為這很可能需要網路上更好的外圍安全性，以便非託管設備無法先連接網路。
- 資料中心和最大使用者位置上可用的 AD 網域控制站上的內部 DNS
- 用於公共名稱解析的專用設備
- 用戶端都指向 AD DNS，然後轉送到外部網域的裝置。這裡沒有太多高級功能。
此設定的主要問題是地理定位不起作用，因為僅在 3 個主要資料中心上有公共解析器。這通常不是一個大問題，因為大多數瀏覽器請求都是透過處理DNS 的雲端過濾服務代理的，但最近當我們使用視訊服務（例如Google Hangouts）時，事情變得複雜化，視訊服務將受益於準確的地理資訊來選擇正確的資料中心。