【51CTO.com獨家特稿】2009年5月19日21：50開始，江蘇、安徽、廣西、海南、甘肅、浙江等六省用戶申告訪問網站速度變慢或無法訪問。5月20日，工業和信息化部通信保障局召集國家計算機應急處理協調中心、電信研究院、中國電信集團、暴風影音等參加緊會議，經查明，事故原因是系DNS域名解析故障，網絡故障造成多家網站受到影響，暴風也是受害者之一。

例子中提到的DNS系統用于命名組織到域層次結構中的計算機和網絡服務。它主要應用于Internet等TCP/IP網絡中，通過用戶友好的名稱查找計算機和服務。當用戶在應用程序中輸入DNS名稱時，DNS服務可以將此名稱解析為與之相關的其他信息。從上述實例我們不難深刻地體會到，DNS服務器是非常關鍵的互聯網基礎設施，高效管理及使用DNS服務器是網絡管理員的一個非常重要的問題。本專題將詳細介紹如何通過相關配置和技術來高效管理Linux下的DNS服務。

一、DNS服務簡介

1．基本原理

DNS（Domain Name System，域名系統）用于命名組織到域層次結構中的計算機和網絡服務。DNS命名用于Internet等TCP/IP網絡中，通過用戶友好的名稱查找計算機和服務。當用戶在應用程序中輸入DNS名稱時，DNS服務可以將此名稱解析為與之相關的其他信息，如IP地址。因為，用戶在上網時輸入的網址，是通過域名解析系解析找到相對應的IP地址，這樣才能上網。其實，域名的最終指向是IP。

值得一提的是，在引入DNS之前，網絡中的主機是將容易記憶的域名映射到IP地址并將它保存在一個共享的靜態文件hosts（該文件路徑為/etc/hosts）中，再由hosts文件來實現網絡中域名的管理。最初Internet非常小，僅使用這個集中管理的文件就可以通過FTP為連入Internet的站點和主機提供域名的發布和下載。每個Internet站點將定期地更新其主機文件的副本，并且發布主機文件的更新版本來反映網絡的變化。但是，當Internet上的計算機迅速增加時，通過一個中心授權機構為所有Internet主機管理一個主機文件的工作將無法進行。文件會隨著時間的推移而增大，這樣按當前和更新的形式維持文件以及將文件分配至所有站點將變得非常困難。

域名系統為一個分布式數據庫，它使本地負責控制整個分布式數據庫的部分段，每一段中的數據通過客戶，服務器模式在整個網絡上均可存取，通過采用復制技術和緩存技術使得整個數據庫可靠的同時，又擁有良好的性能。域名服務器包含數據庫的部分段的信息，并可提供被稱之為解析器的客戶來訪問。DNS的數據庫結構形成一個倒立的樹狀結構，根的名字用空字符串""來表示，但在文本中用“.”來書寫。樹的每一個節點都表示整個分布式數據庫中的一個分區（域），每個域可再進一步劃分成子分區（域），每個域都有一個標簽（label），標明了它與父域的關系。域也有一個域名（domain name），給出它在整個分布式數據庫中的位置。在DNS中，域名全稱是一個從該域到根的標簽序列，以“.”分隔這些標簽。該標簽最多可包含63個字符。樹中每一節點的完整域名為從該節點到根之間路徑上的標簽序列。如果根域在節點的域名中出現，該名字看起來就象以點結尾（實際上是以點和空標簽作結尾）。這些以點結尾的域名被稱之為絕對域名（Absolute Domain Name）。不以點結尾的域名被稱之為相對域名。域（Domains）即為樹狀域名空間中的一棵子樹，域的域名同該子樹根節點的域名一樣。也就是說，域的名字就是該域中最高層節點的名字。圖1給出了DNS分層結構的圖示：  

圖1  DNS域名空間的分層結構

DNS基于C/S（Client/Server，客戶機/服務器）模式，因而分為Client和Server兩種角色。Client扮演詢問的角色，也就是向Server詢問一個Domain Name，而Server必須要回答此Domain Name所對應的真正IP地址。而當地的DNS先會查自己的資料庫。如果自己的資料庫沒有，則會往該DNS上所設的的其他DNS進行求助詢問，依此得到答案之后，將收到的答案存起來，并回答客戶。

DNS服務器會根據不同的授權區（Zone），記錄所屬該網域下的各名稱資料，這個資料包括網域下的次網域名稱及主機名稱。在每一個名稱服務器中都有一個高速緩存區（Cache），這個高速緩存區的主要目的是將該名稱服務器所查詢出來的名稱及相對的IP地址記錄在高速緩存區中，這樣當下一次還有另外一個客戶端到次服務器上去查詢相同的名稱時，服務器就不用在到別臺主機上去尋找，而直接可以從緩存區中找到該名稱記錄資料，傳回給客戶端，以加速客戶端對名稱查詢的速度。

舉個例子，當DNS客戶端向指定的DNS服務器查詢網Internet上的某一臺主機名稱時，DNS服務器會在該資料庫中找尋用戶所指定的名稱。如果沒有，該服務器會先在自己的高速緩存區中查詢有無該條紀錄，如果找到該條名稱記錄后，會從DNS服務器直接將所對應到的IP地址傳回給客戶端；如果DNS務器在資料記錄查不到且高速緩存區中也沒有時，服務器才會向別的DNS服務器查詢所要的名稱。例如，本地的DNS服務器會向最接近（比如屬于同一個IP地址段或者同一個ISP）的DNS服務器去要求幫忙找尋該名稱的IP地址.在另一臺服務器上也有相同的動作的查詢，當查詢到后會回復原本要求查詢的服務器，該DNS服務器在接收到另一臺DNS服務器查詢的結果后，先將所查詢到的主機名稱及對應IP地址記錄到高速緩存區中，最后在將所查詢到的結果回復給客戶端。這樣就成功地完成了一次標準的DNS查詢-應答過程。

2．DNS系統的組成

DNS系統基于客戶機/服務器模式，從概念上說他主要由三個部分組成：

（1）域名空間：域名空間中的記錄標識一組主機并提供他們的有關信息。域中的每一個節點都有它的有關信息的數據庫。查詢命令試圖從這個數據庫中提取適當的信息。簡單地說，域名空間是所有不同類型信息的列表，這些信息是域名、IP地址、郵件別名和那些在DNS系統中能查到的內容。

（2）域名服務器：保持并維護域名空間中的數據的程序。每個域名服務器含有一個域名空間子集的完整信息，并保存其它有關部分的信息。一個域名服務器擁有它控制范圍的完整信息。控制的信息按區進行劃分，區可以分布在不同的域名服務器上，以便為每個區提供服務。每個域名服務器都知道所有負責其他區的域名服務器。如果來了一個請求，它請求給定域名服務器負責的那個區的信息，那么這個域名服務器只是簡單地返回信息。但是，如果請求是不同區的信息，那么這個域名服務器就要與控制該區的相應服務器聯系。

（3）解析器：解析器是簡單的程序或子程序庫，它從服務器中提取信息以響應對域名空間內主機的查詢。

DNS是一個很復雜的概念，下表列出了常用的DNS術語。? 

◆域：代表網絡一部分的邏輯實體或組織。? 

◆域名：主機名的一部分，它代表包含這個主機的域。它可以和域交換使用。? 

◆主機：網絡上的一臺計算機。? 

◆節點：網絡上的一臺計算機。? 

◆域名服務器：提供DNS服務的計算機，它將DNS名字轉化為IP地址。? 

◆解析：把一個域名轉化為與其相應的IP地址的過程。? 

◆解析器：從域名服務器中提取DNS信息的程序或庫子程序。? 

◆反向解析：將給出的IP地址轉化為其相應的DNS名字。? 

◆欺騙：使網絡看上去好象具有不同的IP地址或域名的行為。

3．DNS服務器的類型

DNS域名服務器是用來存儲主機-域名映射信息的，這些服務器具體又可以分為3類：

（1）主DNS服務器（primary name server）：它是特定域所有信息的權威性信息源。它從域管理員構造的本地磁盤文件中加載域信息，該文件（區文件）包含著該服務器具有管理權的一部分域結構的最精確信息。主服務器是一種權威性服務器，因為它以絕對的權威去回答對其管轄域的任何查詢。

（2）輔助DNS服務器（secondary name server）：它可從主服務器中復制一整套域信息。區文件是從主服務器中復制出來的，并作為本地磁盤文件存儲在輔助服務器中。這種復制稱為“區文件復制”。在輔助域名服務器中有一個所有域信息的完整拷貝，可以有權威地回答對該域的查詢。因此，輔助域名服務器也稱作權威性服務器。配置輔助域名服務器不需要生成本地區文件，因為可以從主服務器中下載該區文件。

（3）高速緩存服務器（caching-only server）：可運行域名服務器軟件，但是沒有域名數據庫軟件。它從某個遠程服務器取得每次域名服務器查詢的結果，一旦取得一個，就將它放在高速緩存中，以后查詢相同的信息時就用它予以回答。高速緩存服務器不是權威性服務器，因為它提供的所有信息都是間接信息。對于高速緩存服務器只需要配置一個高速緩存文件，但最常見的配置還包括一個回送文件，這或許是最常見的域名服務器配置。 #p#

二、DNS服務管理中存在的問題和面臨的威脅

1．DNS設計中存在的問題

在系統設計方面，DNS的設計受到當時條件限制，因而存在許多設計缺陷問題。

（1）單點故障。DNS采用層次化的樹形結構，由樹葉走向樹根就可以形成—個全域名（Fully Qualified Domain Name，FQDN），DNS服務器作為該FQDN唯一對外的域名數據庫和對內部提供遞歸域名查詢的系統，因而其安全和穩定就存在單點故障風險。

（2）無認證機制。DNS沒有提供認證機制，查詢者在收到應答時無法確認應答信息的真假，就容易導致DNS欺騙。假設當提交給某個域名服務器的域名解析請求的數據包被黑客截獲，然后黑客將一個虛假的IP地址作為應答信息返回給請求者，那么原始請求者就會把這個虛假的IP地址作為它所要請求的域名而進行連接，顯然它被欺騙到了別處而連接不上原本想要連接的那個域名，這樣就導致了DNS欺騙。如圖2所示。  

圖2  DNS欺騙原理示意

（4）訪問量和維護量巨大以及遠距離集中式數據庫。單個名字服務器不得不處理所有DNS查詢消息，并保存所有因特網主機的記錄，數據庫會相當巨大，需要為每臺新增的主機頻繁更新，而且單臺名字服務器主機不可能在所有請求查詢的客戶主機附近，就可能導致相當大的延遲。

（5）BIND（Berkeley Intemet Name Domain）的漏洞：BIND是域名軟件，它在提供高效服務的同時也存在許多的安全性漏洞。現已證明在BIND版本4和8上存在缺陷，攻擊者利用這些缺陷能成功地進行DNs欺騙攻擊，這些漏洞可以被利用取得系統最高權限。構成嚴重威脅的漏洞主要有兩種：一種是緩沖區溢出漏洞，嚴重的可以使攻擊者在DNS服務器上執行任意指令，如BIND SIG Cached RR Ovemow DoS（CAN.2002-1219)在BIND 4和BIND 8中存在一個遠程緩沖溢出缺陷，該缺陷使得攻擊者可以在DNS服務器上運行任意指令。另一種是DoS漏洞，受攻擊后DNS服務器不能提供正常服務，而且其所轄的子網無法正常工作。

2．DNS面臨的網絡威脅

（1）內部攻擊：攻擊者在非法或合法地控制一臺DNS服務器后，可以直接操作域名數據庫，修改指定域名所對應的IP為自己所控制的主機IP，當客戶發出對指定域名的查詢請求后，將得到偽造的IP地址。

（2）序列號攻擊：DNS協議格式中定義了用來匹配請求數據包和響應數據報序列ID，欺騙者利用序列號偽裝成DNS服務器向客戶端發送DNS響應數據包，在DNS服務器發送的真實DNS響應數據報之前到達客戶端，從而將客戶端帶到攻擊者所希望的網站，進行DNS欺騙。

（3）信息插入攻擊：攻擊者可以在DNS應答報文中隨意添加某些信息，指示權威域名服務器的域名及IP，那么在被影響的域名服務器上查詢該域的請求都會被轉向攻擊者所指定的域名服務器上去，從而威脅到網絡數據的完整性。

（4）緩存（cache）中毒：DNS使用超高速緩存，即當一個名字服務器收到有關域名和IP的映射信息時，它會將該信息存放在高速緩存中。當再次遇到相同的映射請求，能直接使用緩存中的結果，這種映射表是動態更新的，刷新也是有時限的，這樣假冒者如果在下次更新之前成功地修改了DNS服務器上的映射緩存，就可以進行DNS欺騙或者DoS（Denial of Service）拒絕服務攻擊了。

（5）信息泄漏：BIND的缺省設置允許任何人進行區傳送，區傳送可能會造成信息泄漏，區傳送一般用于主服務器和輔服務器之間的數據同步，輔服務器可以從主服務器獲取最新區數據文件的副本，也就可以獲得整個授權區域內的所有主機信息。一旦這些信息泄漏，攻擊者就可以根據它輕松地推測主服務器的網絡結構，并從這些信息中判斷其功能或發現那些防范措施較弱的機器。

（6）不安全的動態更新：隨著動態主機配置協議（DHCP）的出現，客戶計算機由DHCP服務器動態分配IP地址，使原來手工更新其A記錄和PTR記錄變得很難管理。因此在RFC2136中提出了DNS動態更新，使得DNS客戶端在IP地址或名稱出現更改的任何時候都可利用DNS服務器來注冊和動態更新其資源記錄。盡管DNS動態更新協議規定只有經過授權的主機才能動態更新服務器的zone file，但是攻擊者還是可以利用IP欺騙偽裝成DNS服務器信任的主機對區數據進行添加、刪除和替換。 #p#

三、安裝DNS的最新版本

Linux下架設DNS服務器通常是使用BIND程序來實現的。BIND是Berkeley Internet Name Domain Service的簡寫，它是一款實現DNS服務器的開放源碼軟件。BIND原本是美國DARPA資助伯克里大學（Berkeley）開設的一個研究生課題，后來經過多年的變化發展，已經成為世界上使用最為廣泛的DNS服務器軟件，目前Internet上絕大多數的DNS服務器都是用BIND來架設的。

BIND經歷了第4版、第8版和最新的第9版，第9版修正了以前版本的許多錯誤，并提升了執行時的效能。BIND能夠運行在當前大多數的操作系統系統平臺之上。目前BIND軟件由因特網軟件聯合會（Internet Software Consortium，ISC）這個非贏利性機構負責開發和維護。ISC的官方網站（http://www.isc.org/，如圖3所示）包含了最新的錯誤修復和更新，目前BIND的最新版本為9.6。

圖3  BIND下載網站主頁

為了保證DNS的安全，強烈建議采用BIND的最新版本進行安裝使用，因為最新的版本是在以前版本的基礎上進行修改和完善，能從根本上解決一些安全隱患。從上述網站上下載Linux下的最新版本為bind-9.6.1b1.tar.gz，該安裝程序為源碼安裝方式。安裝步驟如下所示：

（1）解壓縮下載的源碼安裝包

#tar zxvf bind-9.6.1b1.tar.gz 

（2）切換到解壓目錄，使用configure命令生成Makefile文件

#cd bind-9.6.1b1
#./configure --prefix=/usr/local/bind
--sysconfdir=/etc/bind --localstatedir=/var
--with-libtool --enable-threads

命令中的configure是編譯前對源代碼進行針對具體操作系統的編譯參數配置，有很多選項可以選擇：? 

◆--prefix：指定安裝目錄；? 

◆--sysconfdir：設置named.conf配置文件放置的目錄；? 

◆--localstatdir：設置run/named.pid放置的目錄；? 

◆--with-libtool：將BIND的庫文件編譯為動態共享庫文件，這個選項默認是未選擇的；? 

◆--enable-threads：如果用戶系統有多個CPU，那么可以使用這個選項

（3）編譯和安裝相關模塊。需要注意：下面的編譯和安裝，安裝時需要有root權限

#make
#make install

#p#

四、正確配置DNS相關文件

（1）幾個重要的DNS服務器配置文件類型

在使用DNS服務器之前，需要對與之相關的配置文件進行安全配置，因而首先需要了解這些基本文件，表1詳細給出了幾種主要的與DNS有關的文件以及詳細描述：

表1  DNS相關配置文件介紹

（2）named.conf主配置文件

在使用named.conf進行配置時，需要了解如下常用的配置語句，如表2所示。

表2  named.conf主配文件配置語句說明

根據在實際應用中的廣泛程度和重要性，下面我們著重對option語句和zone聲明的使用進行介紹。

1．使用option語句

option語句的使用語法為：

option語句的使用語法為：
option {
  
配置子句1；  
 
配置子句2；
};

在上述語法中，其配置子句常用的主要有如下兩類：? 

◆directory：該子句后接目錄路徑，主要用于定義服務器區配置文件的工作目錄，如/home等；? 

◆forwarders：該子句后接IP地址，定義轉發器；

2．使用zone聲明

區聲明是主配置文件中非常常用而且是最重要的部分，它一般要說明域名、服務器類型以及域信息源三個重要部分。它的語法為：

zone “zone_name” IN {
  
type 子句；  
 
file  子句；
  
其他子句；
};

那么，圍繞上述三個重要部分，區聲明語句有如下兩類子句：? 

◆type：其主要有如下三種，master（說明一個區為主域名服務器）、slave（說明一個區為輔助域名服務器）和hint（說明一個區為啟動時初始化高速緩存的域名服務器）。? 

◆file：后接文件路徑，主要說明一個區的域信息源的路徑。

3．使用ACL（訪問控制列表）

訪問控制列表（ACL，Access Control List）就是一個被命名的地址匹配列表。使用訪問控制列表可以使配置簡單而清晰，一次定義之后可以在多處使用，不會使配置文件因為大量的IP地址而變得混亂。

要定義訪問控制列表，可以在BIND的主配置文件/etc/named.conf中使用acl語句來實現。acl語句的語法為：

acl  acl_name { 
address_match_list;
};

BIND里默認預定義了4個名稱的地址匹配列表，他們可以直接使用，分別為：?   

◆Any：表示所有主機；? 

◆Localhost：表示本機；? 

◆Localnets：表示本地網絡上的所有主機；? 

◆None：表示不匹配任何主機。

需要注意的是：acl是named.conf中的頂級語句，不能將其嵌入其他的語句。要使用用戶自己定義的訪問控制列表，必須在使用之前定義。因為可以在options語句里使用訪問控制列表，所以定義訪問控制列表的acl語句應該位于options語句之前。

另外，為了便于維護管理員定義的訪問控制列表，可以將所有定義acl的語句存放在單獨的文件/etc/named.conf.acls中，然后在主配置文件/etc /named.conf中如下語句：

include "/etc/named.conf.options";

之前添加如下的配置行

include "/etc/named.conf.acls"; 

定義了ACL之后，可以在如下的子句中使用：? 

◆allow-query  options,zone：指定哪主機或網絡可以查詢本服務器或區，默認的是允許所有主機進行查詢。 

◆allow-transfer  options,zone：指定哪些主機允許和本地服務器進行域傳輸，默認值是允許和所有主機進行域傳輸。  ? 

◆allow-recursion  options：指定哪些主機可以進行遞歸查詢。如果沒有設定，缺省是允許所有主機進行遞歸查詢的。注意禁止一臺主機的遞歸查詢，并不能阻止這臺主機查詢已經存在于服務器緩存中的數據。 ? 

◆allow-update  zone：指定哪些主機允許為主域名服務器提交動態DNS更新。默認為拒絕任何主機進行更新。 ? 

◆blackhole  options：指定不接收來自哪些主機的查詢請求和地址解析。默認值是none。

上面列出的一些配置子句既可以出現在全局配置options語句里，又可以出現在zone聲明語句里，當在兩處同時出現時，zone聲明語句中的配置將會覆蓋全局配置options語句中的配置。

（3）區文件

區文件定義了一個區的域名信息，通常也稱域名數據庫文件。每個區文件都是由若干個資源記錄（RR，resource records）和區文件指令所組成。

1．資源記錄

每個區域文件都是由SOA RR開始，同時包括NS RR。對于正向解析文件還包括A RR、MX RR、CNAME RR等等；而對于反向解析文件還包括PTR RR。

RR具有基本的格式。標準資源記錄的基本格式是：

[name]      [ttl]     IN     type     redata

各個自字節之間由空格或制表符分隔。表3描述了這些字段的含義：

表3  標準資源紀錄中的字段

2．區文件指令

表4列出了可以在區文件中使用的4個區文件指令。

表4   區文件指令

為了方便讀者對DNS服務器配置文件的使用有個詳細的了解，本節將針對一個實際的配置文件例子來進行講解。該配置文件如下所示。我們虛構了一個域cmpbook.com來舉例說明主服務器的配置，下面是定義cmpbook.com域的主服務器的named.conf文件：

// generated by named-bootconf.pl
options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
// a caching only nameserver config
//
zone "." {
type hint;
file "named.ca";
};
zone "cmpbook.com"{
type master;
file "cmpbook.com";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "132.211.in-addr.arpa"{
type master;
file "named.rev";
};

上例中第一個master告訴我們這是cmpbook.com域的主服務器。該域的數據是從named.hosts文件中加載的。在我們這個例子中，我們將文件名named.hosts作為區文件名。第三個master語句指向能將IP地址211.132.0.0映射為主機名的文件。它假定本地服務器是反向域132.211.in-addr.arpa的主服務器，該域的數據從文件named.rev中加載。

除了定義上述的主文件外，還需要定義如下的區文件（/var/named/cmpbook.com）：

$TTL 86400
$ORIGIN cmpbook.com.
@   
1D IN SOA @ root (     42  ; serial (d. adams)     
3H  ; refresh     15M  ; retry     1W  ; expiry
 
 
 
 
 
1D )  ; minimum
@ IN NS @   @ IN A  127.0.0.1   
www IN A 211.132.211.80
 
 
 
 
 
 
 
ftp IN A 211.132.211.68
 
 
 
 
web IN CNAME www

（5）使用Dlint工具進行DNS配置文件檢查

Dlint是一個專門檢查DNS配置文件開放源代碼的軟件，用戶可以從網站http://www.domtools.com上自行下載安裝，目前該網站上的最新版本為Dlint1.4.1。需要注意：使用該軟件前要求系統安裝支持Perl語言和Dig命令（BIND中一個軟件包）的相關軟件包。

Dlint軟件的安裝步驟如下所示，系統會將Dlint安裝在/usr/bin/目錄下：

（1）解壓縮軟件包

#tar dlint1.4.1.tar.gz

（2）切換到解壓縮的目錄下，執行安裝命令

#cd dlint1.4.1
#make

Dlint主要針對DNS配置文件進行如下檢查：? 

◆檢查配置文件是否存在拼寫錯誤；? 

◆檢查配置文件中是否有A（Address）記錄的主機名稱都有配套的PTR（反向解析記錄的簡稱）記錄。如果有A記錄的主機名稱沒有PTR，則配置文件不能通過。另外，Dlint可以在用戶配置文件中為A記錄查找丟失的PTR記錄；? 

◆記錄in-addr.arpa區的每一條PTR記錄是否有對應的A記錄存在，并以遞歸的方式檢查子區，查找它們的配置問題；

如下顯示了使用Dlint工具進行DNS配置文件檢查的運行結果：

#dlint localhost.localhost
;; dlint version 1.4.1, Copyright (C) 1998 Paul A. Balyoz <pab@domtools.com>
;;     Dlint comes with ABSOLUTELY NO WARRANTY.;
;;    This is free software, and you are welcome to redistribute it
;;     under certain conditions.  Type 'man dlint' for details.
;; command line: /usr/local/bin/dlint localhost.localhost
;; flags: normal-domain recursive.
;; using dig version 9.2.1
;; run starting: 涓? 4鏈?15 07:08:18 CST 2009
;; ============================================================
;; Now linting localhost.localhost
ERROR: no name servers found for domain localhost.localhost       
That domain is probably not a zone.  Remove the leftmost portion of the name and try again.
;; ============================================================
;; dlint of localhost.localhost run ending with errors.
;; run ending: 涓? 4鏈?15 07:08:18 CST 2009

（6）使用命令檢驗DNS功能

1．nslookup命令

nslookup命令是用來驗證DNS功能以及故障的一種非常簡便有效的工具，通過該命令可以對用戶搭建的DNS服務器或者是公用的服務器的功能進行有效驗證。該命令不但可以在Linux下使用，而且也可以在Windows系列操作系統中使用。如果該命令能夠成功返回信息，也就是能夠通過域名從DNS服務器得到需要解析的IP地址信息，或者通過提供IP地址信息得到域名信息。那么，就表明該DNS是正常運行的。

如下例子給出使用nslookup命令向DNS查詢www.sohu.com域名IP地址的應用場景，驗證表明DNS功能正常：

 2．dig命令

dig（域信息搜索器）命令是一個用于詢問DNS域名服務器的靈活的工具。它執行DNS搜索，顯示從受請求的域名服務器返回的答復。多數DNS管理員利用dig作為DNS問題的故障診斷，因為它靈活性好、易用、輸出清晰。雖然通常情況下dig使用命令行參數，但它也可以按批處理模式從文件讀取搜索請求。不同于早期版本，dig的BIND9實現允許從命令行發出多個查詢。除非被告知請求特定域名服務器，dig將嘗試/etc/resolv.conf中列舉的所有服務器。當未指定任何命令行參數或選項時，dig將對“.”（根）執行NS查詢。

值得一提的是：dig命令比nslookup命令獲取的信息更加詳細和全面，因此在Linux下建議用戶采用該命令替代nslookup命令進行查詢和驗證DNS的功能（nslookup命令運行中也提供了“Note: nslookup is deprecated and may be removed from future releases.Consider using the `dig' or `host' programs instead.”字樣進行提示）。

另外，鑒于dig命令的強大功能，它提供了幾十個參數選項供用戶使用，具體情況可以使用man命令進行查閱，這不是本專題的重點內容，下面僅僅給出2個例子來進行簡單演示和說明：

（1）運行dig命令獲得根DNS信息

#dig
 ; <<>> DiG 9.2.1 <<>>
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41868
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
 
;; QUESTION SECTION:
;.                              IN      NS
 ;; ANSWER SECTION:
.                       290515  IN      NS      K.ROOT-SERVERS.NET.
.                       290515  IN      NS      J.ROOT-SERVERS.NET.
.                       290515  IN      NS      D.ROOT-SERVERS.NET.
.                       290515  IN      NS      M.ROOT-SERVERS.NET.
.                       290515  IN      NS      C.ROOT-SERVERS.NET.
.                       290515  IN      NS      G.ROOT-SERVERS.NET.
.                       290515  IN      NS      A.ROOT-SERVERS.NET.
.                       290515  IN      NS      E.ROOT-SERVERS.NET.
.                       290515  IN      NS      H.ROOT-SERVERS.NET.
.                       290515  IN      NS      F.ROOT-SERVERS.NET.
.                       290515  IN      NS      L.ROOT-SERVERS.NET.
.                       290515  IN      NS      B.ROOT-SERVERS.NET.
.                       290515  IN      NS      I.ROOT-SERVERS.NET. 
;; ADDITIONAL SECTION:
D.ROOT-SERVERS.NET.     109756  IN      A       128.8.10.90
E.ROOT-SERVERS.NET.     109756  IN      A       192.203.230.10
F.ROOT-SERVERS.NET.     282557  IN      A       192.5.5.241
F.ROOT-SERVERS.NET.     282557  IN      AAAA    2001:500:2f::f
G.ROOT-SERVERS.NET.     109756  IN      A       192.112.36.4
H.ROOT-SERVERS.NET.     539017  IN      A       128.63.2.53
H.ROOT-SERVERS.NET.     541758  IN      AAAA    2001:500:1::803f:235
I.ROOT-SERVERS.NET.     109756  IN      A       192.36.148.17
J.ROOT-SERVERS.NET.     452944  IN      A       192.58.128.30
J.ROOT-SERVERS.NET.     455358  IN      AAAA    2001:503:c27::2:30
K.ROOT-SERVERS.NET.     103767  IN      A       193.0.14.129
L.ROOT-SERVERS.NET.     103467  IN      A       199.7.83.42
L.ROOT-SERVERS.NET.     103467  IN      AAAA    2001:500:3::42
M.ROOT-SERVERS.NET.     109072  IN      A       202.12.27.33
 
;; Query time: 50 msec
;; SERVER: 10.2.13.18#53(10.2.13.18)
;; WHEN: Wed Apr 15 06:39:20 2009
;; MSG SIZE  rcvd: 500

（2）正向解析域名www.google.com

#dig www.google.com
 
; <<>> DiG 9.2.1 <<>> www.google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53325
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 7, ADDITIONAL: 7
 ;; QUESTION SECTION:
;www.google.com.                        IN      A ;; ANSWER SECTION:
www.google.com.         600893  IN      CNAME   www.l.google.com.
www.l.google.com.       292     IN      CNAME   www-china.l.google.com.
www-china.l.google.com. 81      IN      A       72.14.235.99
www-china.l.google.com. 81      IN      A       72.14.235.104
www-china.l.google.com. 81      IN      A       72.14.235.147 ;; AUTHORITY SECTION:
l.google.com.           78559   IN      NS      a.l.google.com.
l.google.com.           78559   IN      NS      b.l.google.com.
l.google.com.           78559   IN      NS      d.l.google.com.
l.google.com.           78559   IN      NS      f.l.google.com.
l.google.com.           78559   IN      NS      c.l.google.com.
l.google.com.           78559   IN      NS      e.l.google.com.
l.google.com.           78559   IN      NS      g.l.google.com. ;; ADDITIONAL SECTION:
g.l.google.com.         66906   IN      A       74.125.95.9
a.l.google.com.         559     IN      A       209.85.139.9
b.l.google.com.         79061   IN      A       74.125.45.9
c.l.google.com.         64857   IN      A       64.233.161.9
d.l.google.com.         72926   IN      A       74.125.77.9
e.l.google.com.         65021   IN      A       209.85.137.9
f.l.google.com.         64805   IN      A       72.14.235.9
 
;; Query time: 21 msec
;; SERVER: 10.2.13.18#53(10.2.13.18)
;; WHEN: Wed Apr 15 06:28:57 2009
;; MSG SIZE  rcvd: 348

#p#

五、配置輔助域名服務器進行冗余備份

輔助服務器可從主服務器中復制一整套域信息。區文件是從主服務器中復制出來的，并作為本地磁盤文件存儲在輔助服務器中。這種復制稱為“區文件復制”。在輔助域名服務器中有一個所有域信息的完整拷貝，可以有權威地回答對該域的查詢。因此，輔助域名服務器也稱作權威性服務器。配置輔助域名服務器不需要生成本地區文件，因為可以從主服務器中下載該區文件。

輔助服務器的配置與主服務器的配置不同，它使用slave語句代替master語句。slave語句指向用作域信息源的遠程服務器，以替代本地磁盤文件。下面的named.conf文件可以配置cmpbook.com域的輔助服務器：

// generated by named-bootconf.pl
options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
//
// a caching only nameserver config
//
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "cmpbook.com"{
type slave;
file "named.hosts";
masters {211.132.10.3;};
};
zone "132.211.in-addr.arpa"{
type slave;
file "named.rev";
masters {211.132.10.3;};
};
cache . named.ca
secondary vbrew.com 211.132.10.3 named.hosts
secondary 132.211.in-addr.arpa 211.132.10.3 named.rev
primary 0.0.127.in-addr.arpa named.local

第一個slave語句是使這個服務器成為vbrew.com的輔助服務器。它告訴named從IP地址為211.132.10.3的服務器中下載cmpbook.com的信息，并將其數據保存在/var/named/named.hosts文件中。如果該文件不存在，named就創造一個，并從遠程服務器中取得區數據，然后將這些數據寫入新創建的文件中。如果存在該文件，named就要檢查遠程服務器，以了解該遠程服務器的數據是否不同于該文件中的數據，如果數據有變化，它就下載更新后的數據，用新數據覆蓋該文件的內容；如果數據沒有變化，named就加載磁盤文件的內容，不必做麻煩的區轉移工作。將一個數據庫拷貝到本地磁盤文件中，就不必每次引導主機時都要轉移區文件；只有當數據修改時，才進行這種區文件的轉移工作。該配置文件中的下一行表示該本地服務器也是反向域132.211.in-addr.arpa的一個輔助服務器，而且該域的數據也從211.132.10.3中下載。該反向域的數據存儲在named.rev中。 #p#

六、配置高速緩存服務器緩解DNS訪問壓力

高速緩存服務器可運行域名服務器軟件，但是沒有域名數據庫軟件。它從某個遠程服務器取得每次域名服務器查詢的結果，一旦取得一個，就將它放在高速緩存中，以后查詢相同的信息時就用它予以回答。高速緩存服務器不是權威性服務器，因為它提供的所有信息都是間接信息。對于高速緩存服務器只需要配置一個高速緩存文件，但最常見的配置還包括一個回送文件，這或許是最常見的域名服務器配置。

配置高速緩存域名服務器是很簡單的。必須有named.conf和named.ca文件，通常也要用到named.local文件。下面是用于高速緩存服務器的named.conf文件的例子：

// generated by named-bootconf.pl
options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
// a caching only nameserver config
//
// a caching only nameserver config
//
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";

directory這一行告訴named到哪里去找尋文件。所有其后命名的文件都將是相對于此目錄的。該文件告訴named去維持一個域名服務器響應的高速緩存，并利用named.ca文件的內容去初始化該高速緩存。該高速緩存初始化文件的名字可以是任何名字，但一般使用/var/named/named.ca。值得注意的是：如上的示例并不是表明在該文件中僅僅使用一個hint語句就能完成高速緩存配置，事實上是幾乎每一種服務器的配置都要用到cache語句。在一些個別情況下，如果在配置中沒有出現master和slave語句，則可以認為它就是一個高速緩存配置。

但是，在我們這個例子中卻有一個master語句。事實上，幾乎在每一個高速緩存的配置文件中都有這一個語句，它將本地服務器定義為它自己的回送域的主服務器，并假定該域的信息存儲在named.local文件中。這個回送域是一個in-addr.arpa域（in-addr.arpa域用于指定逆向解析，或IP地址到DNS名字解析），它將地址127.0.0.1映射為名字localhost。轉換自己的回送地址對于大多數人都是有意義的，因為大多數的named.conf文件都包含這一項。

在大多數高速緩存服務器的配置文件中，這種directory、master和hint語句是唯一使用的語句，但也可以增加其他的語句，forwarders和slave等語句都可以使用。

七、配置DNS負載均衡

DNS負載均衡技術是在DNS服務器中為同一個主機名配置多個IP地址，在應答DNS查詢時，DNS服務器對每個查詢將以DNS文件中主機記錄的IP地址按順序返回不同的解析結果，將客戶端的訪問引導到不同的機器上去，使得不同的客戶端訪問不同的服務器，從而達到負載均衡的目的。

根據我們在上面介紹的區文件的相關知識可以滿足DNS負載均衡的要求，我們通過下面的例子來進行介紹。

現假設有三臺服務器來應對www.cmpbook.com的請求。在采用Linux系統上實現起來比較簡單，只需在該域區文件的數據記錄中添加類似下面的資源記錄即可：

www1  IN  A  210.113.1.1
www2  IN  A  210.113.1.2
www3  IN  A  210.113.1.3
www   IN  CNAME  www1
www   IN  CNAME  www2
www   IN  CNAME  www3

上述六條資源記錄的具體含義為：在DNS服務器中為www.cmpbook.com設定了三臺服務器響應客戶的訪問請求。這三臺服務器分別為www1、www2和www3，而他們均為www服務器的別名。因此，在訪問www服務器時，DNS服務器將依次循環地將訪問請求均衡到三臺服務器中去，以達到負載均衡的目的。

【51CTO.COM 獨家特稿，轉載請注明出處及作者！】