14.1 引言

域名系統(tǒng)（DNS）是一種用于TCP/IP應(yīng)用程序的分布式數(shù)據(jù)庫，它提供主機(jī)名字和IP地址之間的轉(zhuǎn)換及有關(guān)電子郵件的選路信息。這里提到的分布式是指在Internet上的單個站點(diǎn)不能擁有所有的信息。每個站點(diǎn)（如大學(xué)中的系、校園、公司或公司中的部門）保留它自己的信息數(shù)據(jù)庫，并運(yùn)行一個服務(wù)器程序供Internet上的其他系統(tǒng)（客戶程序）查詢。DNS提供了允許服務(wù)器和客戶程序相互通信的協(xié)議。

從應(yīng)用的角度上看，對DNS的訪問是通過一個地址解析器（resolver）來完成的。在Unix主機(jī)中，該解析器主要是通過兩個庫函數(shù)gethostbyname(3)和gethostbyaddr(3)來訪問的，它們在編譯應(yīng)用程序時與應(yīng)用程序連接在一起。前者接收主機(jī)名字返回IP地址，而后者接收IP地址來尋找主機(jī)名字。解析器通過一個或多個名字服務(wù)器來完成這種相互轉(zhuǎn)換。

圖4-2中指出了解析器通常是應(yīng)用程序的一部分。解析器并不像TCP/IP協(xié)議那樣是操作系統(tǒng)的內(nèi)核。該圖指出的另一個基本概念就是：在一個應(yīng)用程序請求TCP打開一個連接或使用UDP發(fā)送一個數(shù)據(jù)報之前。心須將一個主機(jī)名轉(zhuǎn)換為一個IP地址。操作系統(tǒng)內(nèi)核中的TCP/IP協(xié)議族對于DNS一點(diǎn)都不知道。

本章我們將了解地址解析器如何使用TCP/IP協(xié)議（主要是UDP）與名字服務(wù)器通信。我們不介紹運(yùn)行名字服務(wù)器或有關(guān)可選參數(shù)的細(xì)節(jié)，這些技術(shù)細(xì)節(jié)的內(nèi)容可以覆蓋整整一本書。（見[Albitz and Liu 1992]標(biāo)準(zhǔn)Unix解析器和名字服務(wù)器介紹）。

RFC 1034 [Mockapetris 1987a] 說明了DNS的概念和功能，RFC 1035 [Mockapetris 1987b] 詳細(xì)說明了DNS的規(guī)范和實現(xiàn)。DNS最常用的版本（包括解析器和名字服務(wù)器）是BIND—伯克利Internet域名服務(wù)器。該服務(wù)器稱作named。[Danzig、Obraczka和Kumar 1992]分析了DNS在廣域網(wǎng)中產(chǎn)生的通信量。

14.2 DNS基礎(chǔ)

DNS的名字空間和Unix的文件系統(tǒng)相似，也具有層次結(jié)構(gòu)。圖14-1顯示了這種層次的組織形式。

每個結(jié)點(diǎn)（圖14-1中的圓圈）有一個至多63個字符長的標(biāo)識。這顆樹的樹根是沒有任何標(biāo)識的特殊結(jié)點(diǎn)。命名標(biāo)識中一律不區(qū)分大寫和小寫。命名樹上任何一個結(jié)點(diǎn)的域名就是將從該結(jié)點(diǎn)到最高層的域名串連起來，中間使用一個點(diǎn)“.”分隔這些域名（注意這和Unix文件系統(tǒng)路徑的形成不同，文件路徑是由樹根依次向下的形成的）。域名樹中的每個結(jié)點(diǎn)必須有一個唯一的域名，但域名樹中的不同結(jié)點(diǎn)可使用相同的標(biāo)識。

以點(diǎn)“.”結(jié)尾的域名稱為絕對域名或完全合格的域名FQDN（Full Qualified DomainName），例如sun.tuc.noao.edu.。如果一個域名不以點(diǎn)結(jié)尾，則認(rèn)為該域名是不完全的。如何使域名完整依賴于使用的DNS軟件。如果不完整的域名由兩個或兩個以上的標(biāo)號組成，則認(rèn)為它是完整的；或者在該域名的右邊加入一個局部后綴。例如域名sun通過加上局部后綴.tuc.noao.edu.成為完整的。

頂級域名被分為三個部分：

1. arpa是一個用作地址到名字轉(zhuǎn)換的特殊域（我們將在14.5節(jié)介紹）。
2. 7個3字符長的普通域。有些書也將這些域稱為組織域。
3. 所有2字符長的域均是基于ISO3166中定義的國家代碼，這些域被稱為國家域，或地理域。

圖14-2列出了7個普通域的正式劃分。

在DNS中，通常認(rèn)為3字符長的普通域僅用于美國的組織機(jī)構(gòu)，2字符長的國家域則用國際組織美國軍事網(wǎng)點(diǎn)于每個國家，但情況并不總是這樣。許多非美國的組織機(jī)構(gòu)仍然使用普通域，而一些美國的其他組織組織機(jī)構(gòu)也使用.us的國家域（RFC 1480 [Cooper and Postel 1993] 詳細(xì)描述了.us域）。普通域中只有.gov和.mil域局限于美國。

許多國家將它們的二級域組織成類似于普通域的結(jié)構(gòu)：例如，.ac.uk是英國研究機(jī)構(gòu)的二級域名，.co.uk則是英國商業(yè)機(jī)構(gòu)的二級域名。

DNS的一個沒在如圖14-1中表示出來的重要特征是DNS中域名的授權(quán)。沒有哪個機(jī)構(gòu)來管理域名樹中的每個標(biāo)識，相反，只有一個機(jī)構(gòu)，即網(wǎng)絡(luò)信息中心NIC負(fù)責(zé)分配頂級域和委派其他指定地區(qū)域的授權(quán)機(jī)構(gòu)。

一個獨(dú)立管理的DNS子樹稱為一個區(qū)域(zone)。一個常見的區(qū)域是一個二級域，如noao.edu。許多二級域?qū)⑺鼈兊膮^(qū)域劃分成更小的區(qū)域。例如，大學(xué)可能根據(jù)不同的系來劃分區(qū)域，公司可能根據(jù)不同的部門來劃分區(qū)域。

一旦一個區(qū)域的授權(quán)機(jī)構(gòu)被委派后，由它負(fù)責(zé)向該區(qū)域提供多個名字服務(wù)器。當(dāng)一個新系統(tǒng)加入到一個區(qū)域中時，該區(qū)域的DNS管理者為該新系統(tǒng)申請一個域名和一個IP地址，并將它們加到名字服務(wù)器的數(shù)據(jù)庫中。這就是授權(quán)機(jī)構(gòu)存在的必要性。例如，在一個小規(guī)模的大學(xué)，一個人就能完成每次新系統(tǒng)的加入。但對一個規(guī)模較大的大學(xué)來說，這一工作必須被專門委派的機(jī)構(gòu)（可能是系）來完成，因為一個人已無法維持這一工作。

一個名字服務(wù)器負(fù)責(zé)一個或多個區(qū)域。一個區(qū)域的管理者必須為該區(qū)域提供一個主名字服務(wù)器和至少一個輔助名字服務(wù)器。主、輔名字服務(wù)器必須是獨(dú)立和冗余的，以便當(dāng)某個名字服務(wù)器發(fā)生故障時不會影響該區(qū)域的名字服務(wù)。

主、輔名字服務(wù)器的主要區(qū)別在于主名字服務(wù)器從磁盤文件中調(diào)入該區(qū)域的所有信息，而輔名字服務(wù)器則從主服務(wù)器調(diào)入所有信息。我們將輔名字服務(wù)器從主服務(wù)器調(diào)入信息稱為區(qū)域傳送。

當(dāng)一個新主機(jī)加入一個區(qū)域時，區(qū)域管理者將適當(dāng)?shù)男畔?#xff08;最少包括名字和IP地址）加入到運(yùn)行在主名字服務(wù)器上的一個磁盤文件中，然后通知主名字服務(wù)器重新調(diào)入它的配置文件。輔名字服務(wù)器定時（通常是每隔3小時）向主名字服務(wù)器詢問是否有新數(shù)據(jù)。如果有新數(shù)據(jù)，則通過區(qū)域傳送方式獲得新數(shù)據(jù)。

當(dāng)一個名字服務(wù)器沒有請求的信息時，它將如何處理？它必須與其他的名字服務(wù)器聯(lián)系。（這正是DNS的分布特性）。然而，并不是每個名字服務(wù)器都知道如何同其他名字服務(wù)器聯(lián)系。相反，每個名字服務(wù)器必須知道如何同根的名字服務(wù)器聯(lián)系。1993年4月時有8個根名字服務(wù)器，所有的主名字服務(wù)器都必須知道根服務(wù)器的IP地址（這些IP地址在主名字服務(wù)器的配置文件中，主服務(wù)器必須知道根服務(wù)器的IP地址，而不是它們的域名）。根服務(wù)器則知道所有二級域中的每個授權(quán)名字服務(wù)器的名字和位置（即IP地址）。這意味著這樣一個反復(fù)的過程：正在處理請求的名字服務(wù)器與根服務(wù)器聯(lián)系，根服務(wù)器告訴它與另一個名字服務(wù)器聯(lián)系。在本章的后面我們將通過一些例子來詳細(xì)了解這一過程。

DNS的一個基本特性是使用高速緩存。即當(dāng)一個名字服務(wù)器收到有關(guān)映射的信息（主機(jī)名字到IP地址）時，它會將該信息存放在高速緩存中。這樣若以后遇到相同的映射請求，就能直接使用緩存中的結(jié)果而無需通過其他服務(wù)器查詢。14.7節(jié)顯示了一個使用高速緩存的例子。

14.3 DNS的報文格式

DNS定義了一個用于查詢和響應(yīng)的報文格式。圖14-3顯示這個報文的總體格式。

這個報文由12字節(jié)長的首部和4個長度可變的字段組成。

標(biāo)識字段由客戶程序設(shè)置并由服務(wù)器返回結(jié)果?？蛻舫绦蛲ㄟ^它來確定響應(yīng)與查詢是否匹配。

16 bit的標(biāo)志字段被劃分為若干子字段，如圖14-4所示。

我們從最左位開始依次介紹各子字段：

1. QR是1bit字段：0表示查詢報文，1表示響應(yīng)報文。
2. opcode是一個4bit字段：通常值為0（標(biāo)準(zhǔn)查詢），其他值為1（反向查詢）和2（服務(wù)器狀態(tài)請求）。
3. AA是1bit標(biāo)志，表示“授權(quán)回答(authoritative answer)”。該名字服務(wù)器是授權(quán)于該域的。
4. TC是1bit字段，表示“可截斷的(truncated)”。使用UDP時，它表示當(dāng)應(yīng)答的總長度超過512字節(jié)時，只返回前512個字節(jié)。
5. RD是1bit字段表示“期望遞歸（recursion desired）”。該比特能在一個查詢中設(shè)置，并在響應(yīng)中返回。這個標(biāo)志告訴名字服務(wù)器必須處理這個查詢，也稱為一個遞歸查詢。如果該位為0，且被請求的名字服務(wù)器沒有一個授權(quán)回答，它就返回一個能解答該查詢的其他名字服務(wù)器列表，這稱為迭代查詢。在后面的例子中，我們將看到這兩種類型查詢的例子。
6. RA是1bit字段，表示“可用遞歸”。如果名字服務(wù)器支持遞歸查詢，則在響應(yīng)中將該比特設(shè)置為1。在后面的例子中可看到大多數(shù)名字服務(wù)器都提供遞歸查詢，除了某些根服務(wù)器。
7. 隨后的3bit字段必須為0。
8. rcode是一個4bit的返回碼字段。通常的值為0（沒有差錯）和3（名字差錯）。名字差錯只有從一個授權(quán)名字服務(wù)器上返回，它表示在查詢中指定的域名不存在。

隨后的4個16 bit字段說明最后4個變長字段中包含的條目數(shù)。對于查詢報文，問題(question)數(shù)通常是1，而其他3項則均為0。類似地，對于應(yīng)答報文，回答數(shù)至少是1，剩下的兩項可以是0或非0。

14.3.1 DNS查詢報文中的問題部分

問題部分中每個問題的格式如圖14-5所示，通常只有一個問題。

查詢名是要查找的名字，它是一個或多個標(biāo)識符的序列。每個標(biāo)識符以首字節(jié)的計數(shù)值來說明隨后標(biāo)識符的字節(jié)長度，每個名字以最后字節(jié)為0結(jié)束，長度為0的標(biāo)識符是根標(biāo)識符。計數(shù)字節(jié)的值必須是0，63的數(shù)，因為標(biāo)識符的最大長度僅為63（在本節(jié)的后面我們將看到計數(shù)字節(jié)的最高兩比特為1，即值192~255，將用于壓縮格式）。不像我們已經(jīng)看到的許多其他報文格式，該字段無需以整32 bit邊界結(jié)束，即無需填充字節(jié)。

圖14-6顯示了如何存儲域名gemini.tuc.noao.edu。

每個問題有一個查詢類型，而每個響應(yīng)（也稱一個資源記錄，我們下面將談到）也有一個類型。大約有20個不同的類型值，其中的一些目前已經(jīng)過時。圖14-7顯示了其中的一些值。查詢類型是類型的一個超集(superset)：圖中顯示的類型值中只有兩個能用于查詢類型。

最常用的查詢類型是A類型，表示期望獲得查詢名的IP地址。一個PTR查詢則請求獲得一個IP地址對應(yīng)的域名。這是一個指針查詢，我們將在14.5節(jié)介紹。其他的查詢類型將在14.6節(jié)介紹。

查詢類通常是1，指互聯(lián)網(wǎng)地址（某些站點(diǎn)也支持其他非IP地址）。

14.3.2 DNS響應(yīng)報文中的資源記錄部分

DNS報文中最后的三個字段，回答字段、授權(quán)字段和附加信息字段，均采用一種稱為資源記錄RR（Resource Record）的相同格式。圖14-8顯示了資源記錄的格式。

域名是記錄中資源數(shù)據(jù)對應(yīng)的名字。它的格式和前面介紹的查詢名字段格式（圖14-6）相同。

類型說明RR的類型碼。它的值和前面介紹的查詢類型值是一樣的。類通常為1，指Internet數(shù)據(jù)。

生存時間字段是客戶程序保留該資源記錄的秒數(shù)。資源記錄通常的生存時間值為2天。

資源數(shù)據(jù)長度說明資源數(shù)據(jù)的數(shù)量。該數(shù)據(jù)的格式依賴于類型字段的值。對于類型1（A記錄）資源數(shù)據(jù)是4字節(jié)的IP地址。

現(xiàn)在已經(jīng)介紹了DNS查詢和響應(yīng)的基本格式，我們將使用tcpdump程序來觀察具體的交換過程。

14.4 一個簡單的例子

讓我們從一個簡單的例子來了解一個名字解析器與一個名字服務(wù)器之間的通信過程。在sun主機(jī)上運(yùn)行Telnet客戶程序遠(yuǎn)程登錄到gemini主機(jī)上，并連接daytime服務(wù)器：

在這個例子中，我們引導(dǎo)sun主機(jī)（運(yùn)行Telnet客戶程序）上的名字解析器來使用位于noao.edu（140.252.1.54）的名字服務(wù)器。圖14-9顯示了這三個系統(tǒng)的排列情況。

和以前提到的一樣，名字解析器是客戶程序的一部分，并且在Telnet客戶程序與daytime服務(wù)器建立TCP連接之前，名字解析器就能通過名字服務(wù)器獲取IP地址。

在這個圖中，省略了sun主機(jī)與140.252.1以太網(wǎng)的連接實際上是一個SLIP連接的細(xì)節(jié)(參見封2的插圖)，因為它不影響我們的討論。通過在SLIP鏈路上運(yùn)行tcpdump程序來了解名字解析器與名字服務(wù)器之間的分組交換。

sun主機(jī)上的文件/etc/resolv.conf將告訴名字解析器作什么：

第1行給出名字服務(wù)器—主機(jī)noao.edu的IP地址。最多可說明3個名字服務(wù)器行來提供足夠的后備以防名字服務(wù)器故障或不可達(dá)。域名行說明默認(rèn)域名。如果要查找的域名不是一個完全合格的域名（沒有以句點(diǎn)結(jié)束），那末默認(rèn)的域名.tuc.noao.edu將加到待查名后。

圖14-10顯示了名字解析器與名字服務(wù)器之間的分組交換。

讓tcpdump程序不再顯示每個IP數(shù)據(jù)報的源地址和目的地址。相反，它顯示客戶（resolver）的IP地址140.252.1.29和名字服務(wù)器的IP地址140.252.1.54?？蛻舻呐R時端口號為1447，而名字服務(wù)器則使用熟知端口53。如果讓tcpdump程序顯示名字而不是IP地址，它可能會和同一個名字服務(wù)器聯(lián)系（作指示查詢），以致產(chǎn)生混亂的輸出結(jié)果。

第1行中冒號后的字段（1+）表示標(biāo)識字段為1，加號“+”表示RD標(biāo)志（期望遞歸）為1。默認(rèn)情況下，名字解析器要求遞歸查詢方式。

下一個字段為A?，表示查詢類型為A（我們需要一個IP地址），該問號指明它是一個查詢（不是一個響應(yīng)）。待查名字顯示在后面：gemini.tuc.noao.edu.。名字解析器在待查名字后加上句點(diǎn)號指明它是一個絕對字段名。

在UDP數(shù)據(jù)報中的用戶數(shù)據(jù)長度顯示為37字節(jié)：12字節(jié)為固定長度的報文首部（圖14-3）；21字節(jié)為查詢名字（圖14-6），以及用于查詢類型和查詢類的4個字節(jié)。在DNS報文中無需填充數(shù)據(jù)。

tcpdump程序的第2行顯示的是從名字服務(wù)器發(fā)回的響應(yīng)。1*是標(biāo)識字段，星號表示設(shè)置AA標(biāo)志（授權(quán)回答）（該服務(wù)器是noao.edu域的主域名服務(wù)器，其回答在該域內(nèi)是可相信的。）

輸出結(jié)果2/0/0表示在響應(yīng)報文中最后3個變長字段的資源記錄數(shù)：回答RR數(shù)為2，授權(quán)RR和附加信息RR數(shù)均為0。tcpdump僅顯示第一個回答，回答類型為A（IP地址），值為140.252.1.11。

為什么我們的查詢會得到兩個回答？這是因為gemini是多接口主機(jī)，因此得到兩個IP地址。事實上，另一個有用的DNS工具是一個稱為host的公開程序，它能將查詢傳遞給名字服務(wù)器，并顯示返回的結(jié)果。如果使用這個程序，就能看到這個多地址主機(jī)的兩個IP地址：

圖14-10中的第一個回答與host命令的第一行輸出均是在同一子網(wǎng)（140.252.1）的IP地址。這不是偶然的。如果名字服務(wù)器和發(fā)出請求的主機(jī)位于相同的網(wǎng)絡(luò)（或子網(wǎng)），那么BIND會排列顯示的結(jié)果以便在相同網(wǎng)絡(luò)的地址優(yōu)先顯示。

在這個例子中要說明的最后一個問題是在查詢結(jié)果中的UDP數(shù)據(jù)長度：69字節(jié)。為說明這些字節(jié)需要知道以下兩點(diǎn)：

1. 在返回的結(jié)果中包含查詢問題。
2. 在返回的結(jié)果中會有許多重復(fù)的域名，因此使用壓縮方式。在這個例子中，域名gemini.tuc.noao.edu出現(xiàn)了三次。

壓縮方法很簡單，當(dāng)一個域名中的標(biāo)識符是壓縮的，它的單計數(shù)字節(jié)（范圍由0～63）中的最高兩位將被設(shè)置為11。這表示它是一個16 bit指針而不再是8bit的計數(shù)字節(jié)。指針中的剩下14 bit說明在該DNS報文中標(biāo)識符所在的位置（起始位置由標(biāo)識字段的第一字節(jié)起算）。我們明確說明只要一個標(biāo)識符是壓縮的，就可以使用這種指針，而不一定非要一個完整的域名壓縮時才能使用。因為一個指針可能指向一個完整的域名，也可能只指向域名的結(jié)尾部分（這是因為給定域名的結(jié)尾標(biāo)識符是相同的）。

圖14-11顯示了對應(yīng)于圖14-10的第2行的DNS應(yīng)答的格式。我們也顯示了IP首部和UDP首部來重申DNS報文被封裝在UDP數(shù)據(jù)報中。還明確顯示了在問題部分的域名中各標(biāo)識符的計數(shù)字節(jié)。返回的兩個回答除了返回的IP地址不同外，其余都是一樣的。在這個例子中，每個回答中的指針值為12，表示從DNS首部開始的偏移量。

在這個例子中最后要注意的是使用telnet命令后輸出的第2行，這里重復(fù)一下：

我們僅僅輸入了主機(jī)名(gemini)而不是FQDN，但Telnet客戶程序部輸出了FQDN。這是由于Telnet程序通過調(diào)用名字解析器（gethostbyname）對輸入的名字進(jìn)行查詢，返回的結(jié)果包括IP地址和FQDN。Telnet程序就輸出它試圖與之建立TCP連接的IP地址，當(dāng)連接建立后，它就輸出FQDN。

如果在輸入Telnet命令后間隔很長時間才顯示IP地址，這個時延是由名字解析器和名字服務(wù)器在由域名到IP地址的解析所引起的。而顯示Trying到顯示Connected to的時延則是由客戶與服務(wù)器建立TCP連接所引起的，與DNS無關(guān)。

14.5 指針查詢

DNS中一直難于理解的部分就是指針查詢方式，即給定一個IP地址，返回與該地址對應(yīng)的域名。

首先回到圖14-1，查看一下頂級域arpa，及它下面的in-addr域。當(dāng)一個組織加入Internet，并獲得DNS域名空間的授權(quán)，如noao.edu，則它們也獲得了對應(yīng)IP地址的in-addr.arpa域名空間的授權(quán)。在noao.edu這個例子中，它是網(wǎng)絡(luò)號為140.252的B類網(wǎng)絡(luò)。在DNS樹中結(jié)點(diǎn)in-addr.arpa的下一級必須是該IP地址的第一字節(jié)（例中為140），再下一級為該IP地址的下一個字節(jié)（252），依此類推。但應(yīng)牢記的是DNS名字是由DNS樹的底部逐步向上書寫的。這意味著對于IP地址為140.252.13.33的sun主機(jī)，它的DNS名字為33.13.252.140.in-addr.arpa。

必須寫出4字節(jié)的IP地址，因為授權(quán)的代表是基于網(wǎng)絡(luò)號：A類地址是第一字節(jié)，B類地址是第一、二字節(jié)，C類地址則是第一、二、三字節(jié)。IP地址的第一字節(jié)一定位于in-addr的下一級，但FQDN卻是自樹底往上書寫的。如果FQDN由頂往下書寫，則這個IP地址的DNS名字將是arpa.in-addr.140.252.13.33，而它所對應(yīng)的域名將是edu.noao.tuc.sun。

如果DNS樹中沒有獨(dú)立的分支來處理這種地址—名字的轉(zhuǎn)換，將無法進(jìn)行這種反向轉(zhuǎn)換，除非從樹根開始依次嘗試每個頂級域。毫不夸張地說，這將需要數(shù)天或數(shù)周的時間。雖然反寫IP地址和特殊的域名會造成某些混亂，但in-addr解決方案仍是一種最有效的方式。

只有在使用host程序或tcpdump程序直接同DNS打交道時，才會擔(dān)心in-addr域和反寫IP地址影響我們。從應(yīng)用的角度上看，正常的名字解析器函數(shù)（gethostbyaddr）將接收一個IP地址并返回對應(yīng)主機(jī)的有關(guān)信息。反轉(zhuǎn)這些字節(jié)和添加in-addr.arpa域均由該函數(shù)自動完成。

14.5.1 舉例

使用host程序完成一個指針查詢，并使用tcpdump程序來觀察這些分組。例子中的設(shè)置和圖14-9相同，在sun主機(jī)上運(yùn)行host程序，名字服務(wù)器在主機(jī)noao.edu上。我們指明svr4主機(jī)的IP地址：

既然IP地址是僅有的命令行參數(shù)，host程序?qū)⒆詣赢a(chǎn)生指針查詢。圖14-12顯示了tcpdump的輸出。

第1行顯示標(biāo)識符為1，期望遞歸標(biāo)志設(shè)置為1（加號“+”），查詢類型為PTR（應(yīng)注意：問號“？”表示它是一個查詢而不是響應(yīng)）。44字節(jié)的數(shù)據(jù)包括12字節(jié)的DNS報文首部、28字節(jié)的域名標(biāo)識符和4字節(jié)的查詢類型和查詢類。

查詢結(jié)果包含一個回答RR，且為授權(quán)回答比特置1（帶星號）。RR的類型是PTR，資源數(shù)據(jù)中包含該域名。

從名字解析器傳遞給名字服務(wù)器的指針查詢不再是32 bit的IP地址，而是域名34.13.252.140.in-addr.arpa。

14.5.2 主機(jī)名檢查

當(dāng)一個IP數(shù)據(jù)報到達(dá)一個作為服務(wù)器的主機(jī)時，無論是UDP數(shù)據(jù)報還是TCP連接請求，服務(wù)器進(jìn)程所能獲得的是客戶的IP地址和端口號（UDP或TCP）。某些服務(wù)器需要客戶的IP地址來獲得在DNS中的指針記錄。在27.3節(jié)會看到這樣的例子，從未知的IP地址使用匿名FTP訪問服務(wù)器。

其他的一些服務(wù)器如Rlogin服務(wù)器（第26章）不但需要客戶的IP地址來獲得指針記錄，還要向DNS詢問該IP地址所對應(yīng)的域名，并檢查返回的地址中是否有地址與收到的數(shù)據(jù)報中的源IP地址匹配。該檢查是因為.rhosts文件（見26.2節(jié)）中的條目僅包含主機(jī)名，而沒有IP地址，因此主機(jī)需要證實該主機(jī)名是否對應(yīng)源IP地址。

某些廠商將該項檢查自動并入其名字解析器的例程中，特別是函數(shù)gethostbyaddr。這使得任何使用名字解析器的程序均可獲得這種檢查，而無需在應(yīng)用中人為地進(jìn)行這項檢查。

來看一個使用SunOS 4.13名字解析器庫的例子。我們編制了一個簡單的程序通過調(diào)用函數(shù)gethostbyaddr來完成一個指針查詢。我們已在文件/etc/resolv.conf中將名字服務(wù)器設(shè)置為noao.edu，sun主機(jī)通過SLIP鏈路與它相連。圖14-13顯示了當(dāng)調(diào)用函數(shù)gethostbyaddr獲取與IP地址140.252.1.29（sun主機(jī)）對應(yīng)的名字時，tcpdump在SLIP鏈路上收到的內(nèi)容。

第1行是預(yù)期的指針查詢，第2行是預(yù)期的響應(yīng)。但第3行顯示了該名字解析器函數(shù)自動對第2行返回的名字發(fā)出一個IP地址查詢。既然sun主機(jī)有兩個IP地址，第4行的響應(yīng)就包括兩個回答記錄。如果這兩個地址中沒有與gethostbyaddr輸入?yún)?shù)匹配的地址，函數(shù)會向系統(tǒng)的日志發(fā)送一條報文，并向應(yīng)用程序返回差錯。

14.6 資源記錄

至今我們已經(jīng)見到了一些不同類型的資源記錄（RR）：IP地址查詢?yōu)锳類型，指針查詢?yōu)轭愋蚉TR。也已看到了由名字服務(wù)器返回的資源記錄：回答RR、授權(quán)RR和附加信息RR?，F(xiàn)有大約20種不同類型的資源記錄，下面將介紹其中的一些。另外，隨著時間的推移，會加入更多類型的RR。

這些是RR的常用類型。將在后面的例子中遇到它們。

14.7 高速緩存

為了減少Internet上DNS的通信量，所有的名字服務(wù)器均使用高速緩存。在標(biāo)準(zhǔn)的Unix實現(xiàn)中，高速緩存是由名字服務(wù)器而不是由名字解析器維護(hù)的。既然名字解析器作為每個應(yīng)用的一部分，而應(yīng)用又不可能總處于工作狀態(tài)，因此將高速緩存放在只要系統(tǒng)（名字服務(wù)器）處于工作狀態(tài)就能起作用的程序中顯得很重要。這樣任何一個使用名字服務(wù)器的應(yīng)用均可獲得高速緩存。在該站點(diǎn)使用這個名字服務(wù)器的任何其他主機(jī)也能共享服務(wù)器的高速緩存。

在迄今為止（圖14-9）所舉例子的網(wǎng)絡(luò)環(huán)境中，在sun主機(jī)上運(yùn)行客戶程序，通過主機(jī)noao.edu的SLIP鏈路訪問名字服務(wù)器?，F(xiàn)在將改變這種設(shè)置，在sun主機(jī)上運(yùn)行名字服務(wù)器。在這種情況下，如果使用tcpdump監(jiān)視在SLIP鏈路上的DNS通信量，將只能看到服務(wù)器因超出其高速緩存而不能處理的查詢。

在默認(rèn)情況下，名字解析器將在本地主機(jī)上（UDP端口號為53或TCP端口號為53）尋找名字服務(wù)器。從名字解析器文件中刪除nameserver行，而留下domain行：

在這個文件中缺少namerserver指示將導(dǎo)致名字解析器使用本地主機(jī)上的名字服務(wù)器。

使用host命令執(zhí)行下列查詢：

圖14-14顯示了這個查詢的輸出結(jié)果。

這次在tcpdump中使用了新的選項。使用-w選項來收集進(jìn)出UDP或TCP 53號端口的所有數(shù)據(jù)。將這些原始數(shù)據(jù)記錄在一個文件中供以后處理，同時防止tcpdump試圖調(diào)用名字解析器來顯示與那個IP地址相對應(yīng)的域名。執(zhí)行查詢后，終止tcpdump并使用-r選項再次運(yùn)行它。它會讀取含有原始數(shù)據(jù)的文件并產(chǎn)生正式的輸出顯示（如圖1414）。這個過程要花費(fèi)幾秒鐘，因為tcpdump調(diào)用了它自己的名字解析器。

在tcpdump輸出中要注意的第一點(diǎn)是標(biāo)識符(identifier)是小整數(shù)（2和3）。這是因為我們關(guān)閉這個名字服務(wù)器，后又重新啟動它來強(qiáng)制清空它的高速緩存。當(dāng)名字服務(wù)器啟動時，它將標(biāo)識符初始化為1。

當(dāng)鍵入查詢，查找主機(jī)ftp.uu.net的IP地址，該名字服務(wù)器就同8個根名字服務(wù)器中的一個ns.nic.ddn.mil（第1行）取得聯(lián)系。這是以前見到的正常的A類型查詢，但要注意的是它的期望遞歸表示沒有說明（如果該標(biāo)志被設(shè)置，在標(biāo)識符2的后邊會跟著一個加號）。在以前的例子中，經(jīng)?？吹矫纸馕銎髟O(shè)置期望遞歸標(biāo)志，但這里的名字服務(wù)器在與某個根服務(wù)器聯(lián)系時沒有設(shè)置這個標(biāo)志。這是因為不應(yīng)該向根名字服務(wù)器發(fā)出期望遞歸的查詢，它們僅用來尋找其他授權(quán)名字服務(wù)器的地址。

第2行顯示返回的響應(yīng)中沒有回答資源記錄，而包含5個授權(quán)資源記錄和5個附加信息資源記錄。標(biāo)識符2后的減號表示期望遞歸標(biāo)志（RA）沒有被設(shè)置。即使我們要求進(jìn)行遞歸查詢，這個根名字服務(wù)器也不會回答期望遞歸查詢。

盡管tcpdump沒有顯示返回的10個資源記錄，我們也能執(zhí)行host命令來查看高速緩存的內(nèi)容：

這次采用-v選項查看的不僅僅只是A記錄。它顯示出對于域uu.net有5個授權(quán)名字服務(wù)器，而由根名字服務(wù)器返回的5個附加信息資源記錄中含有這5個名字服務(wù)器的IP地址。這避免了在查找其中的某個名字服務(wù)器的地址時，無需再次與根名字服務(wù)器聯(lián)系。這是DNS中的另一個實現(xiàn)優(yōu)化。

host命令指出這個回答不是授權(quán)的，這是因為這個回答來自名字服務(wù)器的高速緩存，而不是來自授權(quán)名字服務(wù)器。

回到圖14-14中的第3行，我們的名字服務(wù)器與第一個授權(quán)名字服務(wù)器（ns.uu.net）詢問同一個問題：ftp.uu.net的IP地址？這次我們的服務(wù)器設(shè)置了期望遞歸標(biāo)志。返回的應(yīng)答（第4行）包含一個回答資源記錄。

而后我們再次執(zhí)行host命令，詢問相同的名字：

這時tcpdump沒有輸出，這正是我們所期望的，因為由host命令返回的回答來自于名字服務(wù)器的高速緩存。

再次執(zhí)行host命令，查找ftp.ee.lbl.gov的地址：

圖14-15顯示了這時的tcpdump輸出。

這時第1行顯示我們的服務(wù)器與另一個根名字服務(wù)器(c.nyser.net)聯(lián)系。一個名字服務(wù)器通常輪詢不同的根名字服務(wù)器來獲得往返時間估計，然后選擇往返時間最小的服務(wù)器。

既然我們的服務(wù)器向一個根服務(wù)器發(fā)出查詢，那么期望遞歸標(biāo)志不應(yīng)被設(shè)置。正如我們在圖14-14中所看到的該名字服務(wù)器并不清除期望遞歸標(biāo)志（即便這樣，一個名字服務(wù)器還是不應(yīng)該向一個根名字服務(wù)器發(fā)出期望遞歸的查詢）。

在第2行返回的響應(yīng)中不包含回答資源記錄，但含有4個授權(quán)記錄和4個附加信息資源記錄。正如我們所猜測的那樣，4個授權(quán)資源記錄是供主機(jī)ftp.ee.lbl.gov進(jìn)行域名服務(wù)的名字服務(wù)器名，其他4個記錄則是這4個服務(wù)器的IP地址。

第3行是向名字服務(wù)器nsl.lbl.gov（第2行中返回的4個名字服務(wù)器中的第一個）發(fā)出的查詢請求。它的期望遞歸標(biāo)志是被設(shè)置的。

第4行返回的響應(yīng)和以往的響應(yīng)不同。返回了兩個回答資源記錄，tcpdump指出其中的第一個是CNAME資源記錄。ftp.ee.lbl.gov的規(guī)范名稱是ee.lbl.gov。

這是CNAME記錄常見的用法。LBL的FTP站點(diǎn)的名字通常是以ftp開始的，但它可能不時地從一個主機(jī)移到另一個主機(jī)。用戶只需要知道ftp.ee.lbl.gov，必要時DNS會用它的規(guī)范名進(jìn)行替換。

記得我們在運(yùn)行host程序時，它顯示了規(guī)范域名的CNAME和IP地址。這是因為響應(yīng)（圖14-15中的第4行）中含有兩個回答資源記錄，第一個是CNAME，而第二個是A記錄。如果A記錄沒有隨CNAME記錄返回，我們的服務(wù)器將發(fā)出另一個查詢請求，詢問ee.lbl.gov的IP地址。這是另一個DNS的實現(xiàn)優(yōu)化—在一個響應(yīng)中同時返回一個規(guī)范域名的CNAME記錄和A記錄。

14.8 用UDP還是用TCP

注意到DNS名字服務(wù)器使用的熟知端口號無論對UDP還是TCP都是53。這意味著DNS均支持UDP和TCP訪問，但我們使用tcpdump觀察的所有例子都是采用UDP。那么這兩種協(xié)議都在什么情況下采用以及采用的理由都是什么呢？

當(dāng)名字解析器發(fā)出一個查詢請求，并且返回響應(yīng)中的TC（刪減標(biāo)志）比特被設(shè)置為1時，它就意味著響應(yīng)的長度超過了512個字節(jié)，而僅返回前512個字節(jié)。在遇到這種情況時，名字解析器通常使用TCP重發(fā)原來的查詢請求，它將允許返回的響應(yīng)超過512個字節(jié)（回想在11.10節(jié)討論的UDP數(shù)據(jù)報的最大長度）。既然TCP能將用戶的數(shù)據(jù)流分為一些報文段，它就能用多個報文段來傳送任意長度的用戶數(shù)據(jù)。

此外，當(dāng)一個域的輔助名字服務(wù)器在啟動時，將從該域的主名字服務(wù)器執(zhí)行區(qū)域傳送。我們也說過輔助服務(wù)器將定時（通常是3小時）向主服務(wù)器進(jìn)行查詢以便了解主服務(wù)器數(shù)據(jù)是否發(fā)生變動。如果有變動，將執(zhí)行一次區(qū)域傳送。區(qū)域傳送將使用TCP，因為這里傳送的數(shù)據(jù)遠(yuǎn)比一個查詢或響應(yīng)多得多。

既然DNS主要使用UDP，無論是名字解析器還是名字服務(wù)器都必須自己處理超時和重傳。此外，不像其他的使用UDP的Internet應(yīng)用（TFTP、BOOTP和SNMP），大部分操作集中在局域網(wǎng)上，DNS查詢和響應(yīng)通常經(jīng)過廣域網(wǎng)。分組丟失率和往返時間的不確定性在廣域網(wǎng)上比局域網(wǎng)上更大。這樣對于DNS客戶程序，一個好的重傳和超時程序就顯得更重要了。

14.9 另一個例子

讓我們通過另一個例子將已經(jīng)介紹的許多DNS特性作一個綜合性回顧。先啟動Rlogin客戶程序，然后連接到一個位于其他域的Rlogin服務(wù)器。圖14-16顯示了發(fā)生的分組交換過程。下面發(fā)生的11個步驟都假定客戶和服務(wù)器的高速緩存中沒有任何信息。

1. 客戶程序啟動后，調(diào)用它的名字解析器函數(shù)將我們鍵入的主機(jī)名轉(zhuǎn)換為一個IP地址。一個A類型的查詢請求被送往一個根服務(wù)器。
2. 由根服務(wù)器返回的響應(yīng)中包含為該服務(wù)器所在域服務(wù)的名字服務(wù)器名。
3. 客戶端的名字解析器將向該服務(wù)器的名字服務(wù)器重發(fā)上述A類型查詢，這個查詢通常是將期望遞歸標(biāo)志設(shè)置為1。
4. 返回的應(yīng)答中包含Rlogin服務(wù)器的IP地址。
5. Rlogin客戶和Rlogin服務(wù)器建立一個TCP連接（第18章將提供該步驟的細(xì)節(jié)）?？蛻艉头?wù)器的TCP模塊間將交換3個分組。
6. Rlogin服務(wù)器收到來自客戶的連接請求后，調(diào)用它的名字解析器通過TCP連接請求中的IP地址獲得客戶主機(jī)名。這是一個PTR查詢請求，由一個根名字服務(wù)器處理。這個根名字服務(wù)器可以不同于步驟1中客戶使用的根名字服務(wù)器。
7. 這個根名字服務(wù)器的響應(yīng)中含有為客戶的in-addr.arpa域的名字服務(wù)器。
8. 服務(wù)器上的名字解析器將向客戶的名字服務(wù)器重傳上述PTR查詢。
9. 返回的PTR應(yīng)答中含有客戶主機(jī)的FQDN。
10. 服務(wù)器的名字解析器向客戶的名字服務(wù)器發(fā)送一個A類型查詢請求，查找前一步返回的名字對應(yīng)的IP地址。這可能由服務(wù)器中的gethostbyaddr函數(shù)自動完成，正如我們在14.5節(jié)中介紹的那樣，否則Rlogin服務(wù)器將完成這一步。此外，客戶的名字服務(wù)器常常就是客戶的in-addr.arpa名字服務(wù)器，但這不是必需的。
11. 從客戶的名字服務(wù)器返回的響應(yīng)含有客戶主機(jī)的A記錄。Rlogin服務(wù)器將客戶的TCP連接請求中的IP地址與A記錄作比較。
    

高速緩存將減少這個圖中交換的分組數(shù)目。

14.10 小結(jié)

DNS是任何與Internet相連主機(jī)必不可少的一部分，同時它也廣泛用于專用的互聯(lián)網(wǎng)。層次樹是組成DNS域名空間的基本組織形式。

應(yīng)用程序通過名字解析器將一個主機(jī)名轉(zhuǎn)換為一個IP地址，也可將一個IP地址轉(zhuǎn)換為與之對應(yīng)的主機(jī)名。名字解析器將向一個本地名字服務(wù)器發(fā)出查詢請求，這個名字服務(wù)器可能通過某個根名字服務(wù)器或其他名字服務(wù)器來完成這個查詢。

所有的DNS查詢和響應(yīng)都有相同的報文格式。這個報文格式中包含查詢請求和可能的回答資源記錄、授權(quán)資源記錄和附加資源記錄。通過許多例子了解了名字解析器的配置文件以及DNS的優(yōu)化措施：指向域名的指針（減少報文的長度）、查詢結(jié)果的高速緩存、in-addr.arpa域（查找IP地址對應(yīng)的域名）以及返回的附加資源記錄（避免主機(jī)重發(fā)同一查詢請求）。