熱點推薦:
您现在的位置: 電腦知識網 >> 操作系統 >> Windows服務器 >> 正文

DNS專題(7)---動態DNS和活動目錄①

2013-11-23 21:50:49  來源: Windows服務器 

  本章內容包括
  &#;動態DNS(DDNS)從windows 和DNS管理員的角度對DNS最新的動態更新特征作了一個簡要的概述該節略述了安全連結問題和域區文件清除還詳細討論了windows 中的廢物清理問題
  &#;DNS域區的活動目錄集成論及了用活動目錄來存儲DNS域區文件為何這樣使用的原因它提供什麼服務以及面對決定是否使用這個可選功能時的考慮還詳細討論它提供的動態更新安全問題
  &#;依賴於SRV記錄的活動目錄概覽windows 域環境中SRV記錄的用法在所有windows 支持的DNS的新特征中SRV記錄是支持活動目錄所必需的
  &#;把活動目錄與DNS結合起來(或不結合)收集一些因素的服務以及在使用這項技術時哪些方面需要作出有見地的決定
  windows 的活動目錄實現了LDAP(輕便目錄訪問協議)目錄服務一段歷史可以幫助理解這意味著什麼最初的X目錄服務協議因為種種原因沒能完全實現商業化從而退出了歷史舞台特別指出的是正是這樣一個如此復雜的規范導致了它的一個子集的實現那就是LDAP協議
  盡管LDAP協議的特征仍然在發展但windows 現在支持一個事實是現有的LDAP協議的實現通常不支持全球范圍的定位服務DNS便是其中一個X最初的概念是只提供定位的目錄結構及在目錄結構中定位的能力而LDAP協議的實現卻集中於目錄結構的使用更甚於對它的定位
  活動目錄的設計利用了現有DNS的定位能力並通過活動目錄與域名空間的緊密聯系而實現結果活動目錄裡最高層的對象在名字上看起來像DNS域這恰恰是因為在這兒使用的域控制器對象代表windows 的域邊界對windows 的最初版本而言它們本來是打算以有相同結構的DNS域和子域命名的
  這裡隱含的意義有很多本章分析了一些源於這種設計及源於使用支持此設計的DNS的最新特征的能力相互作用以及缺陷
  動態DNS
  DDNS(動態DNS)RFC詳述了能被DNS客戶端用來請求改變DNS域的更新操作(定義了新的DNS操作碼)和消息格式正如我們所看到的域內容必須在本域的主服務器上產生於是動態DNS定義當輔服務器接收到一個更新請求時應該被向前傳送到主服務器進行如果認為這些聽起來很簡單易懂那麼就等一會兒後面還有很多內容更新很容易實現就難了
  通過對客戶機所在域的授權域名服務器的定位(對NS記錄的請求)來更動態更新客戶端這樣可以通過請求地址注冊或任意的指針記錄的注冊來廣播它的存在windows 實際上是查詢SOA記錄而不是NS記錄然後直接向此域的主機注冊在客戶機做完這些以後它的名字就可以被解析了同時IP地址也能被任意檢驗就象資資源記錄被手工鍵入的一樣
  如果這樣做很簡單的話任何一個DNS管理員都會像一個剛擁有一輛新自行車的小孩一樣激動正如我們所知道的不付出代價或冒險是很難從新事物中獲利的否則老早以前就這樣做了
  什麼是動態DNS
  RFC說明了DNS的動態更新能力它介紹了DNS更新消息格式利用更新消息格式客戶端可以刪除一個資源記錄添加一個資源記錄或檢測與維護先前狀態
  RFC詳細說明了記錄集的用法例如在一個DNS域裡對WWW有多個相同名字(就像多個A記錄一樣)的記錄集更新操作可能針對單個資源記錄一個資源記錄集或多個資源記錄集通過動態更新可以添加資源記錄也可以刪除資源記錄和資源記錄集
  測試一定的規則是否適合能夠應用(例如對沒有A記錄存在)這些測試中有的是更新請求能繼續下去而必須使用的先決條件有的只是沒有相關操作的簡單的維護這些維護利用了一種更新消息這種更新消息有一個沒有相關更新操作的測試從而提供了一種查詢DNS數據庫以確定某些資源記錄或資源記錄集是否存在的簡單方式
  DNS服務器告知客戶機維護測試或者更新操作的輸出結果如果更新操作有相關操作和必需的先決條件就由DNS服務器實現更新在這種情況下更新在一種完全無反應的方式下進行也就是說此時的更新操作是原語
  對於對單個資源記錄的簡單的添加或刪除請求更新消息是沒有限制的更新請求可以刪除整個資源記錄集因為對通配符使用的限制更新操作需要被清楚地指定
  RFC規定了實時指定的或標准的RFC安全保障用以施加於更新過程但卻並未為此定義一套機制RFC首次定義了安全DNS動態更新規程動態更新的安全問題在繼續發展許多標准的RFC方法需要公共密鑰機制提供支持在windows 的最初版本中實現了支持Kerberos的安全方法(見本章後續章節)
  windows 客戶端對動態DNS的使用
  上節提到windows 客戶端可以直接到主DNS服務器進行DNS更新之所以能這樣做是因為對域數據的任何改變都要在SOA服務器上進行windows 第一版的客戶端配置的動態DNS更新的缺省值是每小時試圖對它的DNS條目刷新一次
  後續章節將會更清楚地講到不必要的更新帶來了整個系統不必要的開銷所以windows 客戶端做的其實比它們被指示的更高明當它們注冊的時候它們首先發送一個只有斷言的更新即測試一下DNS所知道的東西從客戶端的角度來看是否是正確的如果是則不必更新如果客戶端確實需要更新並且域區是活動目錄集成的它將在注冊失敗後嘗試是否存在任何其他主服務器如果客戶端仍然失敗更新過程將在分鐘後重試並且等待分鐘如果仍然不成功則將在再一次嘗試之前等待分鐘一台windows 的機器在被設置為動態更新DNS之後將會堅持不懈地讓自己為人所知
  第章中討論了windows DHCP(動態主機配置協議)服務器代表客戶機進行注冊的能力它能被設置成多種方式但windows 客戶端的缺省值是處理A記錄而DHCP服務器的缺省值是處理PTR記錄windows NTDHCP服務器沒有這種能力DHCP能被設置為既注冊記錄類型又能對非windows 客戶端執行這種注冊這都是通過升級安全措施和注冊清理來實現的(見後續章節)
  問題是什麼
  既然動態DNS能讓DNS管理員從維護域區文件的繁重勞動中解脫出來並且在月的RFC文件中已被定義那麼為什麼它還是很少被使用?或者說在使用動態DNS之前究竟需要知道些什麼?
  安全
  對前一個問題的回答用一個詞來說就是安全問題如果任何人都能注冊的話欺騙和搶劫之間的很多變化幾乎就變的微不足道了比如說對於的A記錄或者更大膽一點對域名服務器的A記錄如果不對誰的機器或什麼機器被允許更新哪個記錄進行什麼控制的話則DDNS將像一項極限運動—只有勇敢者才去試
  微軟已通過活動目錄對域區的集成實現了對動態更新過程的保護集成特征將是本章接下來的主要話題
  服務廣播
  在域區能被動態更新後你也許會注意到新的SRV服務記錄開始出現活動目錄依靠使用SRV記錄來定位它必要的服務例如預計在將來_http_tcp和_ftp_tcp將用SRV記錄來實現這對你的環境來說也許是個問題所以要清楚windows 這艘大船已經完全准備好了並且能夠讓SRV記錄上載至它的最大載量
  域區清理
  安全更新的另一方面的問題是更新沖突與域區清理如果更新操作包括應該被允許的刪除操作被拒絕記錄將會變成孤立的例如如果客戶端在允許移動已注冊的記錄時失敗並且在過一會後又被安全機制拒絕移動那麼誰來清除這些記錄?
  假設DNS服務器拒絕對一個已在域中使用名字域或相應IP地址的A記錄進行注冊更新的話那麼考慮一下DHCP客戶端試圖注冊其已存在的名字或者是其他的機器將要被解析到它所注冊的IP地址時的情形
  這只是對過期記錄造成的問題的兩個概念上的例子如果對於更新過程沒有安全問題這些問題就會消失當客戶端試圖更新時他就會成功然後客戶端就能執行查詢和更新操作來消除潛在沖突以及舊的記錄來保證更新的正確執行
  DNS組織提供的一個明顯的選擇是在犧牲清理的代價下得到安全保障但是問題在於舊的記錄將成為降低整個機器可用性的障礙
  在windows 的缺省操作中只允許DNS管理員和創建該資源記錄的客戶機刪除此記錄因此如果注冊一個記錄的客戶機拋棄了此記錄它將繼續保留在DNS數據庫裡直到其他什麼操作被執行而把它清除使用DHCP協議進行注冊的一個動機是清除舊記錄的責任能夠被移植到一個更穩定的DHCP服務器上去別忘了客戶機能夠改變並且經常改變他們的行動
  服務影響
  動態DNS的使用也給域區行為帶來新的影響也帶來完成工作的新方法例如使用DNS記錄進行DHCP客戶機的注冊提供了一個對更早的WINS的DNS集成的標准替換再比如說當動態DNS和SRV記錄類結合時動態DNS提供服務廣播能力該服務以前僅可在windows 系統中通過NetBIOS名字獲得
  動態域區是指不斷變化(至少是可能變化)的域區不僅要求引入域區傳送機制還帶來了一些新的問題域區傳遞如何提供對域區一致的拷貝?DNS管理員如何手動地編輯一個域區文件並且在沒有版本序列號時如何進行載入?你可能會說干嘛要手動編輯呢?動態DNS已經把我們從那一堆改變方法中解脫出來了是的但是域區清理呢?
  windows 試圖提前考慮這些問題DNS服務器在傳送過程中鎖定域區以防改變然而對於傳送而言防御的第一要務是使用遞增傳送的通告選項其次是根據域區的大小來設計它以便進行完全傳送時它們能盡量簡單(因為鎖定的緣故)DNS服務器的改變日志是如此的所以當被請求的遞增改變超出了日志裡已注冊的改變時一些IXFR請求會帶來AXFR傳送活動目錄集成域區在主服務之間避免了這種可能的問題但在向輔服務器傳遞時卻未能避免

From:http://tw.wingwit.com/Article/os/fwq/201311/29777.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.