來源:http://book.51cto.com/art/200801/64743.htm
http://www.xxeb.com/site/domain/20070314/23.html
作者: 發布時間:2007-03-14
當 DNS 用戶端需要查詢程式中使用的名稱時,它會查詢 DNS 伺服器來解析該名稱。用戶端發送的每條查詢訊息都包括三條資訊,指定伺服器回答的問題:
| • |
指定的 DNS 網域名稱,規定為完全合格的網域名稱 (FQDN) |
| • |
指定的查詢類型,可根據類型指定資源記錄,或者指定查詢操作的專用類型。 |
| • |
DNS 網域名稱的指定類別。 對於 Windows DNS 伺服器,它始終應指定為 Internet (IN) 類別。 |
例如,指定的名稱可為電腦的 FQDN,如
host-a.example.microsoft.com,並且指定的查詢類型用於通過該名稱搜尋地址 (A) 資源記錄。將 DNS
查詢看作用戶端向伺服器詢問由兩部分組成的問題,如“您是否擁有名為‘hostname.example.microsoft.com’的電腦的 A
資源記錄?”當用戶端收到來自伺服器的應答時,它將讀取並解釋應答的 A 資源記錄,擷取根據名稱詢問的電腦的 IP 位址。
DNS 查詢以各種不同的方式進行解析。有時,用戶端也可使用從先前的查詢獲得的緩衝資訊在本地應答查詢。DNS
伺服器可使用其自身的資源記錄資訊緩衝來應答查詢。DNS 伺服器也可代表請求用戶端查詢或聯絡其他 DNS
伺服器,以便完全解析該名稱,並隨後將應答返回至用戶端。這個過程稱為遞迴。
另外,用戶端自己也可嘗試聯絡其他的 DNS 伺服器來解析名稱。當用戶端執行此操作時,它會根據來自伺服器的參考答案,使用其他的獨立查詢。這個過程稱為迭代。
總之,DNS 查詢進程分兩部分進行:
| • |
名稱查詢從用戶端電腦開始,並傳輸至解析程式即 DNS 用戶端服務程式進行解析。 |
| • |
不能在本地解析查詢時,可根據需要查詢 DNS 伺服器來解析名稱。 |
下面將更加詳細地解釋這兩個過程。
第 1 部分:本地解析程式
顯示了完整的 DNS 查詢進程的概況。
如查詢過程的初始步驟所示,DNS 網域名稱
由原生程式使用。該請求隨後傳輸至 DNS 用戶端服務,以便使用本機快取資訊進行解析。如果可以解析查詢的名稱,則應答該查詢,該進程完成。
本地解析程式的緩衝可包括從兩個可能的來源擷取的名稱資訊:
• |
如果在本地配置主機檔案,則來自該檔案的任何主機名稱到地址的映射,在 DNS 用戶端服務啟動時將積極式載入到緩衝中。 |
| • |
從以前的 DNS 查詢應答的響應中擷取的資源記錄,將被添加至緩衝並保留一段時間。 |
如果此查詢與緩衝中的項目不匹配,則解析過程繼續進行,用戶端查詢 DNS 伺服器來解析名稱。
第 2 部分:查詢 DNS 伺服器
如前面的圖中所示,用戶端將查詢首選 DNS 伺服器。在此進程的初始用戶端/伺服器查詢部分中使用的實際伺服器選自全域列表。
當 DNS 伺服器
接收到查詢時,首先檢查它能否根據在伺服器的本地配置地區中擷取的資源記錄資訊作出權威性的應答。如果查詢的名稱與本地地區資訊中的相應資源記錄匹配,則使用該資訊來解析查詢的名稱,伺服器作出權威性的應答。
如果地區資訊中沒有查詢的名稱,則伺服器檢查它能否通過來自先前查詢的本機快取資訊來解析該名稱。如果從中發現匹配的資訊,則伺服器使用該資訊應答查詢。接著,如果首選伺服器可使用來自其緩衝的完全符合響應來應答發出請求的用戶端,則此次查詢完成。
如果查詢名稱在首選伺服器中未發現來自緩衝或地區資訊的匹配應答,則查詢進程可繼續進行,使用遞迴來完全解析名稱。這涉及來自其他 DNS
伺服器的支援,以協助解析名稱。在預設情況下,DNS
用戶端服務需求伺服器在返回應答之前,使用遞迴過程來代表用戶端完全解析名稱。在大多數情況下,DNS 伺服器預設配置為支援遞迴過程,如所示。
為了使 DNS 伺服器正確執行遞迴過程,首先需要使用 DNS 網域命名空間內有關其他 DNS 伺服器的一些有用的聯絡資訊。該資訊以根提示
的形式提供,它是一個初始資源記錄列表,DNS 服務可利用這些記錄定位其他 DNS 伺服器,它們對 DNS 網域命名空間樹的根具有絕對控制權。根伺服器對於 DNS 網域命名空間樹中的根域和頂級域具有絕對控制權。
使用根提示尋找根伺服器,DNS 伺服器可完成遞迴的使用。理論上,該進程將啟用 DNS 伺服器,以定位那些對網域命名空間樹的任何層級使用的任何其他 DNS 網域名稱具有絕對控制權的伺服器。
例如,當用戶端查詢單個 DNS 伺服器時,考慮使用遞迴過程來定位名稱 host-b.example.microsoft.com。在
DNS
伺服器和用戶端初次開機,並且沒有本機快取資訊可協助解析名稱查詢時,就會進行上述過程。根據其配置的地區,它假定由用戶端查詢的名稱是網域名稱,該伺服器在
本地不包含有關該網域名稱的資訊。
首先,首選伺服器分析全名並確定對於頂級域“com”具有絕對控制權的伺服器的位置。隨後,對“com”DNS
伺服器使用迭代查詢,以擷取“microsoft.com”伺服器的參考資訊。隨後,參考應答從“microsoft.com”伺服器傳送到
“example.microsoft.com”的 DNS 伺服器。
最後,與伺服器 example.microsoft.com
建立聯絡。因為該伺服器包括作為其配置地區一部分的查詢名稱,所以它向啟動遞迴的原始伺服器作出權威性地應答。當原始伺服器接收到表明已獲得對請求查詢的權威
性應答的響應時,它將此應答轉寄給發出請求的用戶端,這樣遞迴查詢過程就完成了。
儘管執行上述遞迴查詢過程可能需要佔用大量資源,但對於 DNS 伺服器來說它仍然具有一些效能上的優勢。例如,在遞迴過程中,執行遞迴查詢的
DNS 伺服器可獲得有關 DNS
網域命名空間的資訊。該資訊由伺服器緩衝起來並可再次使用,以便提高使用此資訊或與之匹配的後續查詢的應答速度。隨著時間的推移,這些緩衝資訊會不斷增加並
佔據大量的伺服器記憶體資源,儘管每次 DNS 服務重新啟動時這一資訊將被清除。
可選的查詢響應
以前對 DNS 查詢的討論,都假定此過程在結束時會向用戶端返回一個肯定的響應。然而,查詢也可返回其他應答。最常見的應答有:
| • |
權威性應答 |
| • |
肯定應答 |
| • |
參考性應答 |
| • |
否定應答 |
權威性應答是返回至用戶端的肯定應答,並隨 DNS 訊息中設定的“授權機構”位一同發送,訊息指出此應答是從帶直接授權機構的伺服器擷取的。
肯定應答可由查詢的 RR 或 RR 列表(也稱作 RRset)組成,它與查詢的 DNS 網域名稱和查詢訊息中指定的記錄類型相符。
參考性應答包括查詢中名稱或類型未指定的其他資源記錄。如果不支援遞迴過程,則這類應答將返回至用戶端。這些記錄的作用是為了提供一些有用的參考性應答,用戶端可使用參考性應答繼續進行遞迴查詢。
參考性應答包含其他的資料,如不屬於查詢類型的資源記錄 (RR)。例如,如果查詢主機名稱為“www”並且在這個地區未找到該名稱的 A RR,而是找到了“www”的 CNAME RR,則 DNS 伺服器在響應用戶端時可包含該資訊。
如果用戶端能夠使用迭代過程,則它可使用這些參考性資訊為自己進行其他查詢,以便完全解析此名稱。
來自伺服器的否定應答可以表明:當伺服器試圖處理並且權威性地徹底解析查詢的時候,遇到兩種可能的結果之一:
• |
權威性伺服器報告:在 DNS 命名空間中沒有查詢的名稱。 |
| • |
權威性伺服器報告:查詢的名稱存在,但該名稱不存在指定類型的記錄。 |
以肯定或否定響應的形式,解析程式將查詢結果傳回請求程式並把響應訊息緩衝起來。
注意
| • |
如果查詢的最終應答太長而不能在一個 UDP 訊息資料包中發送和解析,則 DNS 伺服器可以在 TCP 通訊埠 53 上發送容錯移轉響應訊息,以便在 TCP 串連會話中完全應答用戶端。 |
| • |
當 限定 DNS 用戶端的名稱解析到特定的 DNS 伺服器(如 Intranet 上的 DNS 伺服器)的時候,系統通常會禁止在 DNS 伺服器上使用遞迴。當 DNS 伺服器不能解析外部 DNS 名稱的時候,可能也會禁用遞迴,而且期望用戶端容錯移轉到其他 DNS 伺服器,以便解析這些名稱。 在相應伺服器的 DNS 控制台中,可以在“進階”屬性中進行配置,以禁用遞迴。 |
| • |
如果在 DNS 伺服器上禁用遞迴,那麼您將無法在同一伺服器上使用轉寄站。 |
| • |
預設情況下,在執行遞迴查詢並聯絡其他 DNS 伺服器時,DNS 伺服器使用若干預設的時間設定。它們是:
| • |
3 秒的遞迴稍候再試。這是 DNS 服務在遞迴查詢期間重試查詢之前等候的時間長度。 |
| • |
15 秒的遞迴逾時間隔。這是 DNS 服務在重試的遞迴查詢失敗之前等候的時間長度。 |
在大多數情況下,這些參數不需要進行調整。但是,如果在慢速廣域網路鏈路上使用遞迴查詢,那麼或許可通過對設定略作調整,來改善伺服器的效能,加快查詢的完成速度。 |
迭代的工作原理
迭代是在以下條件生效時 DNS 用戶端和伺服器之間使用的名稱解析類型:
| • |
用戶端申請使用遞迴過程,但在 DNS 伺服器上禁用遞迴。 |
| • |
查詢 DNS 伺服器時用戶端沒有申請使用遞迴。 |
來自用戶端的迭代請求告知 DNS 伺服器:用戶端希望直接從 DNS 伺服器那裡得到最好的應答,無需聯絡其他 DNS 伺服器。
使用迭代時,DNS 伺服器根據它自身對與查詢的名稱資料有關的命名空間的特定知識應答用戶端。例如,如果 Intranet 上的 DNS
伺服器接收到來自本地用戶端“www.microsoft.com”的查詢,則可能會返回來自其名稱緩衝的應答。如果查詢的名稱當前未儲存在伺服器的名稱
緩衝中,則伺服器可能會通過提供參考資訊對用戶端作出響應,即提供一張與用戶端所查詢的名稱比較接近的其他 DNS 伺服器的 NS 和 A
資源記錄列表。
在形成參考性資訊的時候,假定 DNS 用戶端負責向其他配置的 DNS
伺服器繼續進行遞迴查詢,以便解析該名稱。例如,在大多數情況下,DNS 用戶端可能會將其搜尋擴充到 Internet
上的根網域服務器,以定位對於“com”域具有絕對控制權的 DNS 伺服器。一旦聯絡上 Internet
根伺服器,它就會從指向“microsoft.com”域的實際 Internet DNS 伺服器的這些 DNS
伺服器中獲得進一步的遞迴響應。當用戶端收到這些 DNS 伺服器的記錄時,可以向 Internet 上的外部 Microsoft DNS
伺服器發送其他迭代查詢,它們可以提供肯定和權威性的應答。
使用迭代時,除了向用戶端提供自己最好的應答外,DNS 伺服器還可在名稱查詢解析中提供進一步的協助。對於大部分迭代查詢,如果它的主 DNS 不能辯識該查詢,那麼用戶端使用本地配置的 DNS 伺服器列表,在整個 DNS 命名空間中聯絡其他名稱伺服器。
緩衝的工作原理
DNS 伺服器採用遞迴或迭代來處理用戶端查詢時,它們將發現並獲得大量有關 DNS 命名空間的重要訊息。然後這些資訊由伺服器緩衝。
緩衝為 DNS 解析流行名稱的後續查詢提供了加速效能的方法,同時大大減少了網路上與 DNS 相關的查詢通訊量。
當 DNS 伺服器代表用戶端進行遞迴查詢時,它們將暫時緩衝資源記錄 (RR)。緩衝的 RR 包含從 DNS
伺服器獲得的資訊,對於在進行迭代查詢以便搜尋和充分應答代表用戶端所執行的遞迴查詢過程中所獲知的 DNS
網域名稱而言,此資訊具有絕對的權威性。稍後,當其他用戶端發出新的查詢,請求與緩衝的 RR 匹配的 RR 資訊時,DNS 伺服器可以使用緩衝的 RR
資訊來應答它們。
當資訊緩衝時,存留時間 (TTL) 值適用於所有緩衝的 RR。只要緩衝 RR 的 TTL 沒有到期,DNS 伺服器就可繼續緩衝並再次使用
RR 來應答與這些 RR 相匹配的用戶端提出的查詢。將大部分地區配置中 RR 所用的緩衝 TTL
值指定為“最小的(預設)TTL”,它被設定為用於地區的起始授權機構 (SOA) 資源記錄。在預設情況下,最小的 TTL 為 3,600 秒(1
小時),但是可以進行調整,也就是說如果需要可以在每個 RR 上分別設定各自的緩衝 TTL。
注意
| • |
可將 DNS 伺服器安裝為僅用於快取服務器。 |
| • |
默 認情況下,DNS 伺服器使用根提示檔案 Cache.dns,該檔案儲存體在伺服器電腦的 systemroot/System32/Dns 檔案夾中。當服務啟動時,該檔案的內容積極式載入到伺服器儲存區,並包含運行 DNS 伺服器所在的 DNS 命名空間的根伺服器的指標資訊。 |