常見的資源記錄類型及應用示例

 本文出自 「王達博客」 博客，轉載請與做者聯繫！

做者已受權本博客轉載

如下內容摘自筆者編著的《網管員必讀——網絡組建》（第2版）一書。

 

7.6.2   主要資源記錄類型及應用示例

建立區域以後，須要向該區域添加其餘的資源記錄。要添加的最經常使用資源記錄（RR）包括如下幾種。

n         主機（A）：用於將DNS域名映射到計算機使用的IP地址。

n         別名（CNAME）：用於將DNS域名的別名映射到另外一個主要的或規範的名稱。

n         郵件交換器（MX）：用於將DNS域名映射爲交換或轉發郵件的計算機的名稱。

n         指針（PTR）：用於映射基於指向其正向DNS域名的計算機的IP地址的反向DNS域名。

n         服務位置（SRV）：用於將DNS域名映射到指定的DNS主機列表，該DNS主機提供諸如Active Directory域控制器之類的特定服務。

下面分別對以上5種主要資源記錄的做用和基本配置方法進行簡單介紹。

1．主機（A）資源記錄（ARR）

ARR就是主機地址（A）資源記錄。它負責將DNS域名映射到Internet協議（IP）版本4的32位地址中。語法格式爲：owner class ttl A IP_v4_address（其中的ttl字段值省略）。

例如：GRFW-S1. grfwgz.local. IN A 192.168.0.1（注意，域主機FQDN後面的句號（.）不能少，下同）。

主機（A）資源記錄在區域中使用，以將計算機（或主機）的DNS域名與它們的IP地址相關聯，並能按多種方法添加到區域中。

n         使用DNS控制檯，您能夠手動爲靜態TCP/IP客戶端建立A資源記錄。

方法是在DNS控制檯相應正向查找區域中單擊鼠標右鍵，在彈出菜單中選擇【新建主機】命令，便可打開如圖7-38所示的對話框。在這裏能夠配置相應主機名稱和IP地址。

 

圖7-38  「新建主機」對話框 

其中的「建立相關的指針（PTR）記錄」複選項用來指定是否在反向查找區域中建立該主機的指針（PTR）資源記錄。這種操做容許DNS客戶端將主機IP地址解析爲其相關的名稱。若是選擇該選項，則DNS控制檯使用上面爲主機名和IP地址指定的信息在現有的反向查找區域中構造一個相關的PTR資源記錄。但要注意，爲了建立指針（PTR）資源記錄，反向查找區域必須已經存在於In-addr.arpa域中的DNS服務器上，不然要先建立該反向查找區域。

若是選擇了「容許全部通過身份驗證的用戶用相同的全部者名稱來更新DNS記錄」複選項，則指定任何通過驗證的客戶端均可以更新該資源記錄。該選項應用於使用當前記錄指定的名稱建立的任何其餘資源記錄，其顯示在DNS控制檯的「名稱」列中。該選項將ACL應用到資源記錄中，它能夠在資源記錄的安全設置中被修改。該設置只適用於存儲在Active Directory中的區域的資源記錄。

n         當IP配置更改時，Windows客戶端和服務器使用DHCP客戶端服務在DNS內動態註冊和更新本身的A資源記錄。

n         若是運行較早版本的Microsoft操做系統，且啓用DHCP的客戶端從有資格的DHCP服務器獲取它們的IP租約，則可經過代理來註冊和更新其A資源記錄（目前只有Windows 2000和Windows Server 2003 DHCP Server服務支持該功能）。

並不是全部計算機都須要主機（A）資源記錄，可是在網絡上共享資源的計算機須要該記錄。共享資源並須要用其DNS域名進行識別的任何計算機，都須要使用A資源記錄來提供對計算機IP地址的DNS名稱解析。 區域內須要的大多數ARR能夠包含其餘共享資源的工做站或服務器、其餘DNS服務器、郵件服務器和Web服務器。這些資源記錄由區域數據庫中的大部分資源記錄構成。

2．別名（CNAME）資源記錄（CNAMERR）

CNAMERR是規範名（CNAME）資源記錄。將owner字段中的別名或備用的DNS域名映射到canonical_name字段中指定的標準或主要DNS域名。此數據中所使用的標準或主要DNS域名是必需的，而且必須解析爲名稱空間中有效的DNS域名。

語法格式爲：owner ttl class CNAME canonical_name

例如：aliasname.example.microsoft.com. CNAME truename.example.microsoft.com。

別名（CNAME）資源記錄容許您使用多個名稱指向單個主機，使得某些任務更容易執行。例如，在同一臺計算機上維護FTP服務器和Web服務器，就能夠經過使用映射爲DNS主機名（如GRFW-S1）的CNAMERR，爲主持這些服務的服務器計算機的服務器名稱（ftp、www）。

添加CNAMERR的方法與添加ARR的方法差很少，但它不只能夠在正向查找區域中建立，還能夠在反向查找區域中建立。在相應查找區域中單擊鼠標右鍵，在彈出菜單中選擇【新建別名】命令，打開如圖7-39所示的對話框。在其中分別輸入對應記錄的別名和目標主機的徹底合格域名便可。對話框中的複選項功能和配置方法與前面介紹的ARR記錄中的對應複選項功能同樣。

 

圖7-39  「新建資源記錄」對話框的「別名（CNAME）」選項卡

建議在下列狀況中使用CNAMERR。

n         在同一區域的ARR中指定的主機須要被從新命名時。

n         當用於像www這樣的已知服務器的通用名稱須要解析一組提供相同服務的單獨計算機（每一個都有單獨的ARR）時。例如，一組冗餘Web服務器。

在區域中使用現有ARR爲計算機從新命名時，您能夠暫時使用CNAMERR讓用戶和程序使用寬限週期，以便從指定舊的計算機名轉換到使用新名稱。爲此，須要進行以下操做。

（1）對於計算機的新DNS域名，新的ARR將被添加到該區域中。

（2）對於舊的DNS域名，將添加指向新ARR的CNAMERR。

（3）從區域中刪除舊DNS域名（若是合適的話，還有與之相關的PTRRR）的原始ARR。

使用CNAMERR爲計算機定義別名或從新命名時，對記錄從DNS刪除以前記錄在區域中使用的時間設置暫時的限制。若是您忘記刪除CNAMERR而之後刪除了與其關聯的ARR，那麼CNAMERR有可能會嘗試解析網上再也不使用的名稱的查詢，從而浪費了服務器資源。

CNAMERR最廣泛的用法是向多臺計算機或Web服務器使用的一個IP地址提供永久的DNS域別名，用於基於服務的名稱（如[url]www.example.microsoft.com[/url]）的通用名稱解析。下例顯示瞭如何使用CNAMERR的基本語法。

alias_name IN CNAME primary_canonical_name

下面再舉一例進行說明。在以下示例中，須要使用名爲host-a.example.microsoft.com的計算機同時充當名爲「[url]www.example.microsoft.com[/url]」的Web服務器和名爲「ftp.example.microsoft.com」的FTP服務器。要實現命名該計算機的預期目的，可在example.microsoft.com區域中添加和使用下列CNAME項。

host-a          IN     A              10.0.0 .20

ftp              IN     CNAME      host-a

www          IN     CNAME     host-a

若是您後來決定將FTP服務器移至獨立於host-a上的Web服務器的另外一臺計算機，只要爲ftp.example.microsoft.com改變區域中的CNAMERR並向主持FTP服務器的新計算機的區域添加其餘的ARR便可。在以上示例的基礎上，若是新計算機被命名爲host-b.example.microsoft.com，則新的和修改的A和CNAMERR記錄以下。

host-a         IN     A              10.0.0 .20

host-b        IN     A              10.0.0 .21

ftp           IN     CNAME      host-b

www         IN     CNAME      host-a

3．郵件交換器（MX）資源記錄（MXRR）

MXRR是郵件交換器（MX）資源記錄。如mail_exchanger_host中指定的那樣，它爲郵件交換器主機提供郵件路由，以便將郵件發送給owner字段中指定的域名。2位數的首選參數值表示在指定了多個交換器主機狀況下的首選順序。每一個交換機主機都必須在有效區域中有一個相應的主機（A）地址資源記錄。

語法格式爲：owner ttl class MX preference mail_exchanger_host

例如：example.microsoft.com. MX 10 mailserver1.example.microsoft.com。

郵件交換器（MX）資源記錄由電子郵件應用程序使用，用以根據在目標地址中使用的DNS域名爲電子郵件接收者定位郵件服務器。例如，對名稱example.microsoft.com的DNS查詢可能會用於尋找MXRR，容許電子郵件應用程序將郵件轉發或交換到電子郵件地址爲 user@example.microsoft.com的用戶。

添加MXRR的方法與前面的ARR的添加方法相似，也是在相應的正向查找區域上單擊鼠標右鍵，在彈出菜單中選擇【新建郵件交換器】命令，打開如圖7-40所示的對話框。在「主機或子域」文本框中輸入擔當郵件服務器的主機名。若是將其保留爲空，則郵件交換器名與父域名相同。若是須要在此處添加包含句點（.）的名稱以指明額外域等級的名稱，則首先在DNS控制檯中分別地添加其餘域，而後添加做爲單一部分名稱的新MX記錄。一般不用填寫這一欄，使它與父域名同樣。

 

圖7-40 「新建資源記錄」對話框的「郵件交換器（MX）」選項卡 

要在「郵件服務器的徹底合格的域名（FQDN）」文本框中輸入郵件服務器的徹底合格名，在「徹底合格的域名」文本框中會自動顯示對應的域名。還須要在「郵件服務器優先級」文本框中輸入一個指定值，值越小優先級別越高，越優先執行。

MXRR爲處理域的郵件的計算機顯示DNS域名。若是存在多個MXRR，則DNS客戶端服務會嘗試按照從最低值（最高優先級）到最高值（最低優先級）的優先級順序與郵件服務器聯繫。如下是使用MXRR的基本語法的示例。

mail_domain_name IN MX preferencemailserver_host

一樣舉一個示例進行說明。現假設想經過使用在example.microsoft.com區域下顯示的MXRR，發送到 user@example.microsoft.com的郵件首先發往 user@mailserver0.example. microsoft.com（若是可能）。若是該服務器不可用，則解析程序客戶端使用user@mailserver1. example.microsoft.com。這樣需添加如下MXRR。

@  IN  MX  1  mailserver0

@  IN  MX  2  mailserver1

在以上記錄中的at符號（@）的使用代表發件人的DNS域名和區域的源名稱（example.microsoft.com）相同。

4．指針（PTR）資源記錄（PTRRR）

PTRRR是指針（PTR）資源記錄。正如targeted_domain_name中所指定的那樣，它可從owner中的名稱指向DNS名稱空間中的另外一位置。常常在諸如in-addr.arpa域樹的特殊域中使用，以提供地址—名稱映射的反向查找。在大多數狀況下，每一個記錄提供指向另外一DNS域名位置的信息，如正向查找區域中的相應主機（A）地址資源記錄。有關詳細信息，請參閱RFC 1035。

語法格式爲：owner ttl class PTR targeted_domain_name。

例如： 1.0.0 .10.in-addr.arpa. PTR host.example.microsoft.com。

指針（PTR）RR用於支持基於在in-addr.arpa域中建立和確立的區域的反向查找過程。這些記錄用於經過IP地址定位計算機併爲該計算機將信息解析爲DNS域名。

PTRRR能以多種方法添加到區域中，以下所述。

n         能夠爲使用DNS的靜態TCP/IP客戶端手動建立PTRRR，既能夠做爲一個單獨的過程，也能夠做爲建立ARR過程的一部分。

方法是在相應反向查找區域上單擊鼠標右鍵，在彈出菜單中選擇【新建指針】命令，打開如圖7-41所示的對話框。

 

圖7-41 「新建資源記錄」對話框的「指針（PTR）」選項卡

在這個對話框的「主機名」文本框中須要指定相應指針的主機（A）資源記錄的徹底合格的域名。對於FQDN，尾隨的句點（.）用來證實名稱是徹底合格的。指定的主機是用作應答基於由該指針（PTR）資源記錄指定的地址信息的反向查找的數據。

n         IP配置更改時，計算機可使用DHCP客戶端服務動態註冊和更新它們在DNS中的PTRRR。

n         若是啓用了DHCP的全部其餘客戶端從有資格的服務器中得到了IP租約，則能經過DHCP服務器註冊和更新它們的PTRRR。Windows 2000和Windows Server 2003 DHCP Server服務提供該功能。

指針（PTR）資源記錄僅用於在反向查找區域中支持反向查找。

5．服務位置（SRV）資源記錄（SRVRR）

SRVRR是服務定位器（SRV）資源記錄。容許使用單個DNS查詢操做定位提供相似的基於TCP/IP服務的多個服務器。該記錄使您可爲按照DNS域名首選項排列的已知服務器端口和傳輸協議類型維護服務器的列表。例如，在Windows Server 2003 DNS中，它提供了經過389號TCP端口定位使用輕型目錄訪問協議（LDAP）服務的域控制器的方法。

在SRV資源記錄中使用的每一個專用字段的目的以下。

n         服務：所需服務的符號名。對於一些你們都知道的服務，保留的通用符號名（如「_telnet」或「_smtp」）在RFC 1700中定義。若是某個已知的服務名稱沒有在RFC 1700中定義，則可以使用本地或用戶首選名稱。一些普遍使用的TCP/IP服務，特別是郵局協議（POP），沒有單獨的通用符號名稱。若是RFC 1700爲本字段中指定的服務指派名稱，則RFC定義的名稱是可合法使用的惟一名稱。只有本地定義的服務才能在本地命名。

n         協議：指明傳輸協議類型。儘管可以使用在RFC 1700中命名的任何傳輸協議，但這通常爲TCP或UDP。

n         名稱：該資源記錄所引用的DNS域名。SRV資源記錄在其餘DNS記錄類型中是惟一的，在DNS記錄類型中，它不用於執行搜索或查詢。

n         優先權：爲「目標」字段中指定的主機設置首選項。查詢SRV資源記錄的DNS客戶端嘗試聯繫在此列出的最低編號首選項的第一臺可訪問的主機。儘管目標主機具備相同規定的首選項值，但它們仍可隨機進行嘗試。首選項值的範圍爲0～65 535。

n         權重：除「首選項」外，它可用於提供負載平衡機制，在「目標」字段中指定多個服務器並設爲相同的優先級。在這些相同優先級中選擇目標服務器主機時，這個值可用於設置附加的優先級，用於肯定在應答SRV查詢中使用的目標主機的準確順序或選擇平衡。使用非零值時，相同優先級的服務器根據該值的權重按比例地進行嘗試。值的範圍是1～65 535。若是不須要進行加載平衡，則使用該字段中的0值以使該記錄更易於閱讀。

n         端口：位於提供「服務」字段中所指明服務的「目標」主機上的服務器端口。儘管如RFC 1700中所指定的那樣，編號一般是公開指派的服務端口號，但端口編號的範圍仍是0～65 535。未被指派的端口可根據須要使用。

n         目標：爲提供要申請的服務類型的主機指定DNS域名。所使用的每一個主機名都必須在DNS名稱空間中有相應的主機地址（A）資源記錄。可在該字段中使用單個句點（.），以便權威性地指出該DNS域名中沒有在SRV資源記錄中所指定的待申請服務。

語法格式爲：service.protocol.name ttl class SRV preference weight port target

例如：_ldap._tcp._msdcs SRV 0 0 389 dc1.example.microsoft.com。

要定位Active Directory域控制器，須要知道服務位置（SRV）RR。在默認狀況下，Active Directory安裝嚮導根據首選或備用DNS服務器列表嘗試定位DNS服務器，這些服務器是在任何TCP/IP客戶端屬性中爲任何活動的網絡鏈接配置的。若是聯繫了能夠接受SRVRR（以及有關在DNS中將Active Directory註冊爲一項服務的其餘RR）動態更新的DNS服務器，則配置過程就完成了。

若是在安裝過程當中沒法找到能夠接受用於命名Active Directory的DNS域名更新的DNS服務器，該向導可在本地安裝DNS服務器，並使用支持Active Directory域的區域自動配置它。例如，若是您爲樹林中的第一個域選擇的Active Directory域是example.microsoft.com，那麼在DNS域名example.microsoft.com上確立的區域將被添加並配置爲與運行在新域控制器上的DNS服務器一同使用。

不管是否在本地安裝DNS服務器服務，在Active Directory安裝過程當中將寫入和建立文件（Netlogon.dns），該過程包含支持Active Directory使用所需的SRVRR和其餘RR。該文件在systemroot\System32\Config文件夾中建立。

若是您打算使用符合下列描述之一的DNS服務器，則應使用Netlogon.dns中的記錄手動配置該服務器上的主要區域以支持Active Directory。

n         操做DNS服務器的計算機正在另外一個平臺上（如UNIX）運行，而且不能接受或識別動態更新。

n         該計算機上的DNS服務器不是與Windows Server 2003家族一塊兒提供的DNS服務器服務，它對於Active Directory域的DNS域名對應的主要區域具備權威性。

如同Internet草案「指定服務（DN×××V）位置的DNSRR」中所定義的那樣，DNS服務器支持SRVRR，但不支持動態更新。例如，Windows NT Server 4.0提供的DNS服務器服務在更新到Service Pack4或更高版本時符合該描述。