本章內容包括
&#
;動態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
