Active Directory 的 DNS 記錄的必要性
我熟悉 Active Directory 對 DNS 的依賴以及有關 Active Directory 命名中 DNS 的最佳實踐（例如，使用專用於 AD 的公司域的子域）。不過，我對此有一個相當概念性的問題：
- 將 DNS 記錄（實際上在任何地方）指向域控制器的必要性有多大？例如，假設我的網路擁有
example.com並且我正在考慮分配ad.example.com給域。由於域控制器是網路的權威 DNS 伺服器，如果你呼叫它ad.example.com，即使沒有為其添加 CNAME DNS 記錄，域上的所有請求ad.example.com都將由域控制器正確完成 - 這並不重要如果沒有外部請求。我錯過了什麼嗎？添加 DNS 記錄有什麼區別，因為 DC 不應該從外部訪問，無論如何？你能不做（功能上）就脫身嗎？這個答案似乎暗示了這一點，但那裡的 OP 也說他使用公共 DNS 記錄。- 我知道每個人都在譴責它，但我在 AD 域方面的大部分經驗是看到組織使用其根DNS 域作為 AD 域名（例如只是
example.com. 假設我也想走這條路（並且不會被勸阻），這樣做時要採取的步驟/要考慮的事情是什麼？我不斷聽到“衝突”，但不清楚這些衝突在什麼意義上存在。是否只是對網站的請求example.com將轉到域控制器本身，需要根據埠重定向請求？當您為 AD 重用根域時，處理這些衝突的“正確”方法是什麼？
對於你的第一個問題，我不確定你在說什麼。您是說您認為沒有必要為您的域提供公共 DNS 記錄嗎？你是對的，從技術上講，你沒有。問題是，您的域命名空間應該在全球範圍內是唯一的，如果它從屬於您已經擁有的命名空間，那麼您可以保證它是唯一的。如果您在稍後進行集成時擁有一個公共命名空間，這會讓生活變得更加輕鬆
這個建議可以追溯到 Windows 2000 天，它仍然具有相關性。
對於第二個問題，如果您擁有命名空間，請不要，不要，將您的 AD 域放在該命名空間的根目錄。始終、始終、始終為您的域創建從屬命名空間。
您不希望域控制器暴露在 Internet 上。您將始終需要某種 DNS“墊片”來將您的域控制器與面向公眾的 DNS 分開，在這種情況下，您不妨簡單地將根命名空間託管在那裡。
擁有一個單獨的命名空間意味著您不會遇到保持腦裂 DNS有序的痛苦和痛苦。來自戴爾的連結很好地總結了您可能遇到的問題類型。
是的，有像 Infoblox “DNS Views” 這樣的解決方案（甚至微軟現在也提供類似的東西），但它也需要照顧和餵養。您需要熟練的人來正確設置和維護它。否則，根據戴爾的文章，如果您在沒有這些額外好處的情況下為同一個命名空間擁有兩個“權威”的不同系統，那麼（它始終是 IME）可能會非常痛苦。
如果您在根命名空間中有 Web 服務，並且可能還有其他東西，例如用於批量電子郵件的其他命名空間（以使 SPF 更容易）或非 Windows 系統或幾乎任何您可能希望與之共享命名空間的第三方服務，它是更好地保持您的域分開。如果您可能想要做這些事情（提示，如果它是任何描述的企業或公共組織，您將**）。
這是通過默默無聞的一點點安全性。不多，可以肯定，但有一點。
從系統管理的角度來看，您的 DNS 委託和解析器要容易得多。您擁有根命名空間，並且該 DNS 伺服器將下級域命名空間委託給對其具有權威性的 DC。任何域客戶端都可以進行良好的安全 DNS 註冊，根 DNS 仍然對根命名空間具有權威性。AD DNS 區域可以安全地設置為清除過時的記錄，因為現代 Windows 客戶端可以根據需要重新註冊。當然，您仍然可以為您的伺服器創建靜態條目。
對於名稱解析，DC 將其解析器配置為指向上游 DNS，對於外部和根區域名稱解析，它對域和非域客戶端都很好而且乾淨。顯然，您只允許您的內部非域客戶端查詢內部域名稱空間，而不是外部客戶端。
實際上，我還建議為內部非 Windows 主機設置一個單獨的從屬命名空間——它可以託管在上游 DNS 上，或者委託給 Windows DC，甚至是一個完全獨立的 DNS 主機。或者，如果您只需要擔心一些不錯的現代 Linux，請將它們加入 AD 域，完成。
最後，自 2000 年以來我一直在管理 AD 域（以及之前的 NT 域），實際上我在域設計中遇到的第一個問題是它是否是在根命名空間中的裂腦 DNS 下完成的。可怕的“單一標籤”域在域問題的排名中遠遠落後，因為它非常罕見。比這個根 AD 命名空間問題更罕見。
我現在支持這樣的環境。該域有 1000 個帳戶中的 10 個，自 2002 年以來一直存在。我們擁有數百個 Web 服務、雲服務（多個雲提供商）、第三方 SAAS 和 PAAS 集成、電話、具有不相交命名空間的外部域、Windows 和非 Windows環境中的非域系統——都與該根命名空間和/或內部 AD 互動。可憐的 DNS 設計權威和我實際上每個月都會出於某種原因花費數小時來處理它。有很多手動處理來解決它引起的問題。
另一種選擇是註冊一個完全不相交的命名空間，僅用於託管您的域，而所有公共內容都保留在主命名空間中。例如，為他們的公共命名空間註冊一個 enterprise.com/.org 的實體，以及為他們的 Windows 域註冊一個 enterprise.net.cc 或其他東西的實體。這很好，但是您需要額外的管理成本來註冊 MX 和 TXT 記錄，並為您的不相交的命名空間創建自定義 UPN（可能）以與您的公共電子郵件地址/雲服務等內容集成。可行，但要花更多的錢，而且工作並沒有太多好處。而且您需要確保影子 IT 不會潛入使用“錯誤”的命名空間，然後突然之間它也必須可以公開訪問。
TL; DR - 沒有關於“正確”方法的好建議的原因是實際上沒有正確且可管理的方法來做到這一點。將您的 AD 放在根命名空間中沒有任何好處；如果有的話，會有很多缺點。
除非您在一個很小的環境中並且您並不真正關心您的 AD。在這種情況下，我實際上建議您根本不要打擾 AD，而直接轉到Azure AD 基於雲的身份。