----------------------- Page 1-----------------------
下载
第14章 DNS：域名系统
14.1 引言
域名系统（D N S ）是一种用于T C P / I P应用程序的分布式数据库，它提供主机名字和 I P地
址之间的转换及有关电子邮件的选路信息。这里提到的分布式是指在 I n t e r n e t上的单个站点不
能拥有所有的信息。每个站点（如大学中的系、校园、公司或公司中的部门）保留它自己的
信息数据库，并运行一个服务器程序供 I n t e r n e t上的其他系统（客户程序）查询。 D N S提供了
允许服务器和客户程序相互通信的协议。
从应用的角度上看，对D N S 的访问是通过一个地址解析器（r e s o l v e r ）来完成的。在U n i x
主机中，该解析器主要是通过两个库函数 g e t h o s t b y n a m e(3) 和g e t h o s t b y a d d r( 3 )来访问
的，它们在编译应用程序时与应用程序连接在一起。前者接收主机名字返回 I P地址，而后者
接收I P地址来寻找主机名字。解析器通过一个或多个名字服务器来完成这种相互转换。
图4 - 2 中指出了解析器通常是应用程序的一部分。解析器并不像 T C P / I P协议那样是操作系
统的内核。该图指出的另一个基本概念就是：在一个应用程序请求 T C P打开一个连接或使用
U D P发送一个数据报之前。心须将一个主机名转换为一个 I P地址。操作系统内核中的 T C P / I P
协议族对于D N S一点都不知道。
本章我们将了解地址解析器如何使用 T C P / I P协议（主要是U D P ）与名字服务器通信。我
们不介绍运行名字服务器或有关可选参数的细节，这些技术细节的内容可以覆盖整整一本书。
（见[Albitz and Liu 1992]标准U n i x解析器和名字服务器介绍）。
RFC 1034 [Mockapetris 1987a] 说明了D N S 的概念和功能，RFC 1035 [Mockapetris 1987b]
详细说明了DNS 的规范和实现。D N S最常用的版本（包括解析器和名字服务器）是 B I N D—
伯克利I n t e r n e t域名服务器。该服务器称作 n a m e d 。[ D a n z i g、O b r a c z k a和Kumar 1992] 分析了
DNS 在广域网中产生的通信量。
14.2 DNS 基础
D N S 的名字空间和U n i x 的文件系统相似，也具有层次结构。图 14-1 显示了这种层次的组
织形式。
每个结点（图 1 4 - 1中的圆圈）有一个至多6 3个字符长的标识。这颗树的树根是没有任何
标识的特殊结点。命名标识中一律不区分大写和小写。命名树上任何一个结点的域名就是将
从该结点到最高层的域名串连起来，中间使用一个点“.”分隔这些域名（注意这和 U n i x文件
系统路径的形成不同，文件路径是由树根依次向下的形成的）。域名树中的每个结点必须有一
个唯一的域名，但域名树中的不同结点可使用相同的标识。
以点“. ”结尾的域名称为绝对域名或完全合格的域名 F Q D N （Full Qualified Domain
N a m e ），例如s u n . t u c . n o a o . e d u .。如果一个域名不以点结尾，则认为该域名是不完全的。
如何使域名完整依赖于使用的 D N S软件。如果不完整的域名由两个或两个以上的标号组成，
----------------------- Page 2-----------------------
第14章 DNS ：域名系统使用143
下载
则认为它是完整的；或者在该域名的右边加入一个局部后缀。例如域名 s u n通过加上局部后
缀. t u c . n o a o . e d u .成为完整的。
未命名树根
顶级域
第二级域 阿拉伯联合 津巴布韦
酋长国
普通域 国家域
图14-1 DNS的层次组织
顶级域名被分为三个部分：
1) a r p a是一个用作地址到名字转换的特殊域（我们将在 1 4 . 5节介绍）。
2) 7个3字符长的普通域。有些书也将这些域称为组织域。
3) 所有2字符长的域均是基于I S O 3 1 6 6 中定义的国家代码，这些域被称为国家域，或地理
域。 域 描 述
图1 4 - 2列出了7个普通域的正式划分。 商业组织
在D N S 中，通常认为3字符长的普通域仅 教育机构
其他美国政府部门
用于美国的组织机构， 2字符长的国家域则用 国际组织
美国军事网点
于每个国家，但情况并不总是这样。许多非美
网络
国的组织机构仍然使用普通域，而一些美国的 其他组织
组织机构也使用 . u s的国家域（ RFC 1480
[Cooper and Postel 1993] 详细描述了. u s域）。 图14-2 3字符长的普通域
普通域中只有 . g o v和. m i l域局限于美国。
许多国家将它们的二级域组织成类似于普通域的结构：例如， . a c . u k是英国研究机构的
二级域名， . c o . u k则是英国商业机构的二级域名。
D N S 的一个没在如图1 4 - 1中表示出来的重要特征是D N S 中域名的授权。没有哪个机构来
管理域名树中的每个标识，相反，只有一个机构，即网络信息中心 N I C负责分配顶级域和委派
其他指定地区域的授权机构。
----------------------- Page 3-----------------------
144使用TCP/IP详解，卷1：协议
下载
一个独立管理的 D N S 子树称为一个区域 ( z o n e ) 。一个常见的区域是一个二级域，如
n o a o . e d u。许多二级域将它们的区域划分成更小的区域。例如，大学可能根据不同的系来
划分区域，公司可能根据不同的部门来划分区域。
如果你熟悉U n i x 的文件系统，会注意到D N S树中区域的划分同一个逻辑U n i x文件
系统到物理磁盘分区的划分很相似。正如无法确定图 1 4 - 1中区域的具体位置，我们也
不知道一个Unix文件系统中的目录位于哪个磁盘分区。
一旦一个区域的授权机构被委派后，由它负责向该区域提供多个名字服务器。当一个新
系统加入到一个区域中时，该区域的 D N S管理者为该新系统申请一个域名和一个 I P地址，并
将它们加到名字服务器的数据库中。这就是授权机构存在的必要性。例如，在一个小规模的
大学，一个人就能完成每次新系统的加入。但对一个规模较大的大学来说，这一工作必须被
专门委派的机构（可能是系）来完成，因为一个人已无法维持这一工作。
一个名字服务器负责一个或多个区域。一个区域的管理者必须为该区域提供一个主名字
服务器和至少一个辅助名字服务器。主、辅名字服务器必须是独立和冗余的，以便当某个名
字服务器发生故障时不会影响该区域的名字服务。
主、辅名字服务器的主要区别在于主名字服务器从磁盘文件中调入该区域的所有信息，
而辅名字服务器则从主服务器调入所有信息。我们将辅名字服务器从主服务器调入信息称为
区域传送。
当一个新主机加入一个区域时，区域管理者将适当的信息（最少包括名字和 I P地址）加
入到运行在主名字服务器上的一个磁盘文件中，然后通知主名字服务器重新调入它的配置文
件。辅名字服务器定时（通常是每隔 3小时）向主名字服务器询问是否有新数据。如果有新数
据，则通过区域传送方式获得新数据。
当一个名字服务器没有请求的信息时，它将如何处理？它必须与其他的名字服务器联系。
（这正是D N S 的分布特性）。然而，并不是每个名字服务器都知道如何同其他名字服务器联系。
相反，每个名字服务器必须知道如何同根的名字服务器联系。 1 9 9 3年4月时有8个根名字服务
器，所有的主名字服务器都必须知道根服务器的 I P地址（这些I P地址在主名字服务器的配置
文件中，主服务器必须知道根服务器的 I P地址，而不是它们的域名）。根服务器则知道所有二
级域中的每个授权名字服务器的名字和位置（即 I P地址）。这意味着这样一个反复的过程：正
在处理请求的名字服务器与根服务器联系，根服务器告诉它与另一个名字服务器联系。在本
章的后面我们将通过一些例子来详细了解这一过程。
你可以通过匿名的F T P获取当前的根服务器清单。具体是从f t p . r s . i n t e r n i c . n e t
或nic.ddn.mil 获取文件n e t i n f o / r o o t - s e r v e r s . t x t。
D N S 的一个基本特性是使用超高速缓存。即当一个名字服务器收到有关映射的信息（主
机名字到I P地址）时，它会将该信息存放在高速缓存中。这样若以后遇到相同的映射请求，
就能直接使用缓存中的结果而无需通过其他服务器查询。 1 4 . 7节显示了一个使用高速缓存的
例子。
14.3 DNS的报文格式
D N S定义了一个用于查询和响应的报文格式。图 1 4 - 3显示这个报文的总体格式。
----------------------- Page 4-----------------------
第14章 DNS ：域名系统使用145
下载
标识 标志
问题数 资源记录数 12字节
授权资源记录数 额外资源记录数
查询问题
回答
(资源记录数可变)
授权
(资源记录数可变)
额外信息
(资源记录数可变)
图14-3 DNS查询和响应的一般格式
这个报文由1 2字节长的首部和4个长度可变的字段组成。
标识字段由客户程序设置并由服务器返回结果。客户程序通过它来确定响应与查询是否
匹配。
16 bit的标志字段被划分为若干子字段，如图1 4 - 4所示。
图14-4 DNS报文首部中的标志字段
我们从最左位开始依次介绍各子字段：
* QR 是1 bit字段：0表示查询报文，1表示响应报文。
* o p c o d e是一个4 bit字段：通常值为0 （标准查询），其他值为1 （反向查询）和2 （服务器
状态请求）。
* A A是1 bit标志，表示“授权回答 (authoritative answer) ”。该名字服务器是授权于该域
的。
* T C是1 bit字段，表示“可截断的 ( t r u n c a t e d )”。使用U D P 时，它表示当应答的总长度超
过5 1 2字节时，只返回前5 1 2个字节。
* R D是1 bit字段表示“期望递归（recursion desired ）”。该比特能在一个查询中设置，并
在响应中返回。这个标志告诉名字服务器必须处理这个查询，也称为一个递归查询。如
果该位为0，且被请求的名字服务器没有一个授权回答，它就返回一个能解答该查询的
其他名字服务器列表，这称为迭代查询。在后面的例子中，我们将看到这两种类型查询
的例子。
* R A是1 bit字段，表示“可用递归”。如果名字服务器支持递归查询，则在响应中将该比
特设置为1。在后面的例子中可看到大多数名字服务器都提供递归查询，除了某些根服
务器。
----------------------- Page 5-----------------------
146使用TCP/IP详解，卷1：协议
下载
* 随后的3 bit字段必须为0 。
* r c o d e是一个4 bit 的返回码字段。通常的值为0 （没有差错）和3 （名字差错）。名字差错
只有从一个授权名字服务器上返回，它表示在查询中制定的域名不存在。
随后的4个16 bit字段说明最后 4个变长字段中包含的条目数。对于查询报文，问题
( q u e s t i o n )数通常是1，而其他3项则均为0 。类似地，对于应答报文，回答数至少是 1，剩下的
两项可以是0或非0 。
14.3.1 DNS查询报文中的问题部分
问题部分中每个问题的格式如图1 4 - 5所示，通常只有一个问题。
0 15 16 31
查询名
查询类型 查询类
图14-5 DNS查询报文中问题部分的格式
查询名是要查找的名字，它是一个或多个标识符的序列。每个标识符以首字节的计数值
来说明随后标识符的字节长度，每个名字以最后字节为 0结束，长度为0的标识符是根标识符。
计数字节的值必须是0 ~ 6 3 的数，因为标识符的最大长度仅为 6 3 （在本节的后面我们将看到计
数字节的最高两比特为1，即值1 9 2 ~ 2 5 5，将用于压缩格式）。不像我们已经看到的许多其他报
文格式，该字段无需以整32 bit边界结束，即无需填充字节。
图1 4 - 6显示了如何存储域名g e m i n i . t u c . n o a o . e d u。
计数 计数 计数 计数 计数
图14-6 域名g e m i n i . t u c . n o a o . e d u 的表示
每个问题有一个查询类型，而每个响应（也称一个资源记录，我们下面将谈到）也有一
个类型。大约有2 0个不同的类型值，其中的一些目前已经过时。图 1 4 - 7显示了其中的一些值。
查询类型是类型的一个超集( s u p e r s e t )：图中显示的类型值中只有两个能用于查询类型。
名 字 数 值 描 述 类型? 查询
类型
IP地址
名字服务器
规范名称
指针记录
主机信息
邮件交换记录
对区域转换的请求
或 对所有记录的请求
图14-7 DNS问题和响应的类型值和查询类型值
----------------------- Page 6-----------------------
第14章 DNS ：域名系统使用147
下载
最常用的查询类型是A类型，表示期望获得查询名的I P地址。一个P T R查询则请求获得一
个I P地址对应的域名。这是一个指针查询，我们将在 1 4 . 5节介绍。其他的查询类型将在 1 4 . 6节
介绍。
查询类通常是1，指互联网地址（某些站点也支持其他非I P地址）。
14.3.2 DNS响应报文中的资源记录部分
D N S报文中最后的三个字段，回答字段、授权字段和附加信息字段，均采用一种称为资
源记录R R （Resource Record ）的相同格式。图1 4 - 8显示了资源记录的格式。
域名
类型 类
生存时间
资源数据长度
资源数据
图14-8 DNS资源记录格式
域名是记录中资源数据对应的名字。它的格式和前面介绍的查询名字段格式（图 1 4 - 6）
相同。
类型说明 R R 的类型码。它的值和前面介绍的查询类型值是一样的。类通常为 1，指
I n t e r n e t数据。
生存时间字段是客户程序保留该资源记录的秒数。资源记录通常的生存时间值为 2天。
资源数据长度说明资源数据的数量。该数据的格式依赖于类型字段的值。对于类型 1 （A
记录）资源数据是4字节的I P地址。
现在已经介绍了D N S查询和响应的基本格式，我们将使用 t c p d u m p程序来观察具体的交
换过程。
14.4 一个简单的例子
让我们从一个简单的例子来了解一个名字解析器与一个名字服务器之间的通信过程。在
s u n主机上运行Te l n e t客户程序远程登录到g e m i n i主机上，并连接d a y t i m e服务器：
前3行的输出是从Telnet客户
这是从daytime服务器的输出
这是从Telnet客户的输出
在这个例子中，我们引导 s u n主机（运行Te l n e t客户程序）上的名字解析器来使用位于
n o a o . e d u （1 4 0 . 2 5 2 . 1 . 5 4）的名字服务器。图1 4 - 9显示了这三个系统的排列情况。
----------------------- Page 7-----------------------
148使用TCP/IP详解，卷1：协议
下载
和以前提到的一样，名字解析器是客户程序 名字服 daytime
的一部分，并且在Te l n e t客户程序与d a y t i m e服务 务器 服务器
器建立T C P连接之前，名字解析器就能通过名字
服务器获取I P地址。
在这个图中，省略了 s u n主机与1 4 0 . 2 5 2 . 1以
太网的连接实际上是一个 S L I P连接的细节（参见
Telnet
封2 的插图），因为它不影响我们的讨论。通过在 客户
S L I P链路上运行t c p d u m p程序来了解名字解析器
与名字服务器之间的分组交换。 图14-9 用于简单DNS例子的系统
s u n主机上的文件/ e t c / r e s o l v . c o n f将告诉名字解析器作什么：
sun % cat /etc/resolv.conf
nameserver 140.252.1.54
domain tuc.noao.edu
第1行给出名字服务器—主机n o a o . e d u的I P地址。最多可说明3个名字服务器行来提供
足够的后备以防名字服务器故障或不可达。域名行说明默认域名。如果要查找的域名不是一个
完全合格的域名（没有以句点结束），那末默认的域名. t u c . n o a o . e d u将加到待查名后。
图1 4 - 1 0显示了名字解析器与名字服务器之间的分组交换。
图14-10 向名字服务器查询主机名g e m i n i . t u c . n o a o . e d u 的输出
让t c p d u m p程序不再显示每个 I P数据报的源地址和目的地址。相反，它显示客户
（r e s o l v e r ）的I P地址1 4 0 . 2 5 2 . 1 . 2 9和名字服务器的I P地址1 4 0 . 2 5 2 . 1 . 5 4。客户的临时端口号为
1 4 4 7，而名字服务器则使用熟知端口5 3。如果让t c p d u m p程序显示名字而不是I P地址，它可
能会和同一个名字服务器联系（作指示查询），以致产生混乱的输出结果。
第1行中冒号后的字段（1 +）表示标识字段为1，加号“+ ”表示R D标志（期望递归）为1。
默认情况下，名字解析器要求递归查询方式。
下一个字段为A ?，表示查询类型为A （我们需要一个I P地址），该问号指明它是一个查询
（不是一个响应）。待查名字显示在后面：g e m i n i . t u c . n o a o . e d u .。名字解析器在待查名
字后加上句点号指明它是一个绝对字段名。
在U D P数据报中的用户数据长度显示为 3 7字节：1 2字节为固定长度的报文首部（图 1 4 -
3 ）；2 1字节为查询名字（图1 4 - 6），以及用于查询类型和查询类的4个字节。在D N S报文中无
需填充数据。
t c p d u m p程序的第2行显示的是从名字服务器发回的响应。 1 *是标识字段，星号表示设置
A A标志（授权回答）（该服务器是n o a o . e d u域的主域名服务器，其回答在该域内是可相信的。）
输出结果2 / 0 / 0表示在响应报文中最后 3个变长字段的资源记录数：回答 R R数为2 ，授权
RR 和附加信息R R数均为0 。t c p d u m p仅显示第一个回答，回答类型为 A （I P地址），值为
1 4 0 . 2 5 2 . 1 . 11。
----------------------- Page 8-----------------------
第14章 DNS ：域名系统使用149
下载
为什么我们的查询会得到两个回答？这是因为 g e m i n i是多接口主机，因此得到两个I P地
址。事实上，另一个有用的D N S工具是一个称为h o s t的公开程序，它能将查询传递给名字服
务器，并显示返回的结果。如果使用这个程序，就能看到这个多地址主机的两个 I P地址：
sun % host gemini
gemini.tuc.noao.edu A 1 4 0 . 2 5 2 . 1 . 1 1
g e m i n i . t u c . n o a o . e d u A 1 4 0 . 2 5 2 . 3 . 5 4
图1 4 - 1 0中的第一个回答与h o s t命令的第一行输出均是在同一子网（ 1 4 0 . 2 5 2 . 1）的I P地
址。这不是偶然的。如果名字服务器和发出请求的主机位于相同的网络（或子网），那么
B I N D会排列显示的结果以便在相同网络的地址优先显示。
我们还可以使用其他的地址来访问g e m i n i主机，但它可能不太有效。在这个例子
中，使用t r a c e r o u t e显示出从子网1 4 0 . 2 5 2 . 1到1 4 0 . 2 5 2 . 3的正常路由不经过g e m i n i主机，
而是经过连接这两个网络的另一个路由器。因此在这种情况下，如果通过其他的I P地址
（1 4 0 . 2 5 2 . 3 . 5 4）来访问g e m i n i主机，所有分组均需经过额外的一跳。我们将在2 5 . 9节重
新回到这个例子来探讨替换路由，那时可使用S N M P来查看一个路由器的路由表。
还有其他一些程序能很容易地对D N S进行交互访问。n s l o o k u p是大多数D N S实现
中包含的程序。[Albitz and Liu 1992]的第10章详细介绍了该程序的使用方法。dig ( “域
名I n t e r n e t搜索(Domain Internet Groper) ”)程序是另一个查询D N S服务器的公开工具。
doc ( “域名模糊控制(Domain Obscenity Control) ”)是一个使用d i g的外壳脚本程序，它
能向合适的名字服务器发送查询来诊断含义不清的域名，并对返回的查询结果进行简
单的分析。附录F有如何获得这些程序的详细介绍。
在这个例子中要说明的最后一个问题是在查询结果中的 U D P数据长度：6 9字节。为说明
这些字节需要知道以下两点：
1) 在返回的结果中包含查询问题。
2) 在返回的结果中会有许多重复的域名，因此使用压缩方式。在这个例子中，域名
g e m i n i . t u c . n o a o . e d u出现了三次。
压缩方法很简单，当一个域名中的标识符是压缩的，它的单计数字节（范围由 0～6 3 ）中
的最高两位将被设置为11。这表示它是一个16 bit指针而不再是8 bit 的计数字节。指针中的剩
下14 bit说明在该D N S报文中标识符所在的位置（起始位置由标识字段的第一字节起算）。我
们明确说明只要一个标识符是压缩的，就可以使用这种指针，而不一定非要一个完整的域名
压缩时才能使用。因为一个指针可能指向一个完整的域名，也可能只指向域名的结尾部分
（这是因为给定域名的结尾标识符是相同的）。
图1 4 - 11显示了对应于图1 4 - 1 0的第2行的D N S应答的格式。我们也显示了 I P首部和U D P首
部来重申D N S报文被封装在U D P数据报中。还明确显示了在问题部分的域名中各标识符的计
数字节。返回的两个回答除了返回的 I P地址不同外，其余都是一样的。在这个例子中，每个
回答中的指针值为1 2，表示从D N S首部开始的偏移量。
在这个例子中最后要注意的是使用t e l n e t命令后输出的第2行，这里重复一下：
sun % telnet gemini daytime 我们只键入g e m i n i
Trying 140.252.1.11 ...
Connected to gemini.tuc.noao.edu. 但T e l n e t客户输出F Q D N
----------------------- Page 9-----------------------
150使用TCP/IP详解，卷1：协议
下载
IP数据报
UDP数据报
DNS报文
UDP DNS 问题 回答#1(RR) 回答#2(RR)
IP首部
首部 首部 (图14-5) (图14-8) (图14-8)
20字节 8字节 12字节 25字节 字节 字节
类型 类 指针类型 类 长度
域名 地址
21字节
图14-11 对应于图14-10中第2行DNS应答的格式
我们仅仅输入了主机名(g e m i n i)而不是F Q D N，但Te l n e t客户程序部输出了F Q D N 。这是
由于Te l n e t程序通过调用名字解析器（g e t h o s t b y n a m e）对输入的名字进行查询，返回的结
果包括I P地址和F Q D N。Te l n e t程序就输出它试图与之建立T C P连接的I P地址，当连接建立后，
它就输出F Q D N 。
如果在输入Te l n e t命令后间隔很长时间才显示I P地址，这个时延是由名字解析器和名字服
务器在由域名到I P地址的解析所引起的。而显示Trying 到显示Connected to的时延则是
由客户与服务器建立T C P连接所引起的，与D N S无关。
14.5 指针查询
D N S 中一直难于理解的部分就是指针查询方式，即给定一个 I P地址，返回与该地址对应
的域名。
首先回到图1 4 - 1，查看一下顶级域a r p a，及它下面的i n - a d d r域。当一个组织加入I n t e r n e t，
并获得D N S域名空间的授权，如n o a o . e d u，则它们也获得了对应I P地址的i n - a d d r . a r p a域名
空间的授权。在n o a o . e d u这个例子中，它是网络号为1 4 0 . 2 5 2的B类网络。在D N S树中结点i n -
a d d r . a r p a的下一级必须是该I P地址的第一字节（例中为1 4 0），再下一级为该I P地址的下一个
字节（2 5 2 ），依此类推。但应牢记的是D N S名字是由D N S树的底部逐步向上书写的。这意味着
对于I P地址为1 4 0 . 2 5 2 . 1 3 . 3 3的s u n主机，它的D N S名字为3 3 . 1 3 . 2 5 2 . 1 4 0 . i n - a d d r . a r p a。
必须写出4字节的I P地址，因为授权的代表是基于网络号：A类地址是第一字节，B类地址
是第一、二字节，C类地址则是第一、二、三字节。I P地址的第一字节一定位于i n - a d d r的下
一级，但F Q D N却是自树底往上书写的。如果F Q D N 由顶往下书写，则这个I P地址的D N S名字将
是a r p a . i n - a d d r . 1 4 0 . 2 5 2 . 1 3 . 3 3，而它所对应的域名将是e d u . n o a o . t u c . s u n。
如果D N S树中没有独立的分支来处理这种地址—名字的转换，将无法进行这种反向转换，
除非从树根开始依次尝试每个顶级域。毫不夸张地说，这将需要数天或数周的时间。虽然反
写I P地址和特殊的域名会造成某些混乱，但 i n - a d d r解决方案仍是一种最有效的方式。
只有在使用h o s t程序或t c p d u m p程序直接同D N S打交道时，才会担心i n - a d d r域和反写I P
地址影响我们。从应用的角度上看，正常的名字解析器函数（g e t h o s t b y a d d r）将接收一个I P
地址并返回对应主机的有关信息。反转这些字节和添加i n - a d d r . a r p a域均由该函数自动完成。
----------------------- Page 10-----------------------
第14章 DNS ：域名系统使用151
下载
14.5.1 举例
使用h o s t程序完成一个指针查询，并使用t c p d u m p程序来观察这些分组。例子中的设置
和图1 4 - 9相同，在s u n主机上运行h o s t程序，名字服务器在主机 n o a o . e d u上。我们指明
s v r 4主机的I P地址：
sun % host 140.252.13.34
Name: svr4.tuc.noao.edu
Address: 140.252.13.34
既然I P地址是仅有的命令行参数， h o s t程序将自动产生指针查询。图 1 4 - 1 2显示了t c p d u m p
的输出。
图14-12 一个指针查询的t c p d u m p 输出
第1行显示标识符为 1，期望递归标志设置为 1 （加号“+ ”），查询类型为P T R （应注意：问号
“？”表示它是一个查询而不是响应）。4 4字节的数据包括1 2字节的D N S报文首部、2 8字节的
域名标识符和4字节的查询类型和查询类。
查询结果包含一个回答R R，且为授权回答比特置1 （带星号）。R R 的类型是P T R ，资源数
据中包含该域名。
从名字解析器传递给名字服务器的指针查询不再是 32 bit 的I P 地址，而是域名
3 4 . 1 3 . 2 5 2 . 1 4 0 . i n - a d d r . a r p a。
14.5.2 主机名检查
当一个I P数据报到达一个作为服务器的主机时，无论是U D P数据报还是T C P连接请求，服
务器进程所能获得的是客户的 I P地址和端口号（U D P或T C P）。某些服务器需要客户的I P地址
来获得在D N S 中的指针记录。在2 7 . 3节会看到这样的例子，从未知的I P地址使用匿名F T P访问
服务器。
其他的一些服务器如R l o g i n服务器（第2 6章）不但需要客户的I P地址来获得指针记录，还
要向D N S询问该I P地址所对应的域名，并检查返回的地址中是否有地址与收到的数据报中的
源I P地址匹配。该检查是因为 . r h o s t s文件（见2 6 . 2节）中的条目仅包含主机名，而没有 I P
地址，因此主机需要证实该主机名是否对应源 I P地址。
某些厂商将该项检查自动并入其名字解析器的例程中，特别是函数 g e t h o s t b y a d d r。
这使得任何使用名字解析器的程序均可获得这种检查，而无需在应用中人为地进行这项检查。
来看一个使用SunOS 4.13名字解析器库的例子。我们编制了一个简单的程序通过调用函数
g e t h o s t b y a d d r来完成一个指针查询。我们已在文件/ e t c / r e s o l v . c o n f中将名字服务器设
置为n o a o . e d u，s u n主机通过S L I P链路与它相连。图1 4 - 1 3显示了当调用函数g e t h o s t b y a d d r
获取与I P地址1 4 0 . 2 5 2 . 1 . 2 9 （s u n主机）对应的名字时，t c p d u m p在S L I P链路上收到的内容。
第1行是预期的指针查询，第2行是预期的响应。但第3行显示了该名字解析器函数自动对
第2行返回的名字发出一个I P地址查询。既然s u n主机有两个I P地址，第4行的响应就包括两个
----------------------- Page 11-----------------------
152使用TCP/IP详解，卷1：协议
下载
回答记录。如果这两个地址中没有与 g e t h o s t b y a d d r输入参数匹配的地址，函数会向系统
的日志发送一条报文，并向应用程序返回差错。
图14-13 调用名字解析器函数执行指针查询
14.6 资源记录
至今我们已经见到了一些不同类型的资源记录（R R）：I P地址查询为A类型，指针查询为类型
P T R。也已看到了由名字服务器返回的资源记录：回答R R、授权R R和附加信息R R。现有大约2 0种
不同类型的资源记录，下面将介绍其中的一些。另外，随着时间的推移，会加入更多类型的R R。
A 一个A记录定义了一个I P地址，它存储32 bit 的二进制数。
P T R 指针记录用于指针查询。 I P地址被看作是 i n - a d d r . a r p a域下的一个域名
（标识符串）。
C N A M E 这表示“规范名字(canonical name) ”。它用来表示一个域名（标识符串），而
有规范名字的域名通常被称为别名 ( a l i a s )。某些F T P服务器使用它向其他的系
统提供一个易于记忆的别名。
例如，g a t e d服务器（1 0 . 3节提到）可通过匿名F T P从g a t e d . c o r n e l l . e d u
获得，但这里并没有叫做g a t e d的系统，这仅是为其他系统提供的别名。其他
系统的规范名为g a t e d . c o r n e l l . e d u。
sun % host -t cname gated.cornell.edu
gated.cornell.edu CNAM COMET.CIT.CORNELL.EDU
这里使用的-t选项来指明它是特定的查询类型。
H I N F O 表示主机信息：包括说明主机 C P U和操作系统的两个字符串。并非所有的站
点均提供它们系统的H I N F O记录，并且提供的信息也可能不是最新的。
sun %host -t hinfo sun
sun.tuc.noao.edu HINFO Sun-4/25 Sun4.1.3
M X 邮件交换记录，用于以下一些场合：（1）一个没有连到I n t e r n e t的站点能将一个
连到I n t e r n e t 的站点作为它的邮件交换器。这两个站点能够用一种交替的方式交
换到达的邮件，而通常使用的协议是U U C P协议。（2 ）M X记录提供了一种将无
法到达其目的主机的邮件传送到一个替代主机的方式。（3 ）M X记录允许机构
提供供他人发送邮件的虚拟主机，如c s . u n i v e r s i t y . e d u，即使这样的主机
名根本不存在。（4 ）防火墙网关能使用M X记录来限制外界与内部系统的连接。
许多不能与I n t e r n e t连接的站点通过U U C P链路与一个连接在I n t e r n e t上的站点
如U U N E T相连接。通过M X记录能使用u s e r @ h o s t这种邮件地址向那个站点
发送电子邮件。例如，一个假想的域 f o o . c o m可能有下面的M X记录：
----------------------- Page 12-----------------------
第14章 DNS ：域名系统使用153
下载
sun %host -t mx foo.com
foo.com MX r e l a y 1 . U U . N E T
foo.com MX relay2.UU.NET
M X记录能被连接在互联网主机中的邮件处理器使用。在这个例子中，其他的
邮件处理器则被告知“如果有邮件要发往 u s e r @ f o o . c o m，就将邮件送到
r e l a y 1 . u u . n e t或r e l a y 2 . u u . n e t。”
每个M X记录被赋于一个 16 bit的整数值，该值称为优先值。如果一个目的主
机有多个M X记录，它们按优先值由小到大的顺序使用。
另一个M X记录的例子是处理主机脱机工作或不可达的情况。邮件处理器仅在
无法使用T C P与目的主机连接时才使用M X记录。作者的主系统通过 S L I P链路
与互联网相连，它在大多数时间内是脱机工作的，我们有
为了显示优先值，我们使用了-v选项（该选项也会导致其他字段的输出）。第
二个字段，8 6 4 0 0，是寿命值，单位为秒。因此该T T L值为2 4小时（2 4 ×6 0 ×
6 0 ）。第3列，I N ，是（I n t e r n e t ）类。我们看到直接传送给主机自身（第一个
M X记录）有最低的优先值0 。如果没有工作（即S L I P链路断开），会使用下一
个更高优先值（ 1 0）的邮件记录，并试图向主机 n o a o . e d u传送。如果它仍
没有成功，发送将超时并在以后重新发送。
N S 名字服务器记录。它说明一个域的授权名字服务器。它由域名表示（符号串）。
在下节将看到这些类型的例子。
这些是R R的常用类型。将在后面的例子中遇到它们。
14.7 高速缓存
为了减少I n t e r n e t上D N S 的通信量，所有的名字服务器均使用高速缓存。在标准的 U n i x实
现中，高速缓存是由名字服务器而不是由名字解析器维护的。既然名字解析器作为每个应用
的一部分，而应用又不可能总处于工作状态，因此将高速缓存放在只要系统（名字服务器）
处于工作状态就能起作用的程序中显得很重要。这样任何一个使用名字服务器的应用均可获
得高速缓存。在该站点使用这个名字服务器的任何其他主机也能共享服务器的高速缓存。
在迄今为止（图 1 4 - 9）所举例子的网络环境中，在 s u n主机上运行客户程序，通过主机
n o a o . e d u的S L I P链路访问名字服务器。现在将改变这种设置，在 s u n主机上运行名字服务
器。在这种情况下，如果使用 t c p d u m p监视在S L I P链路上的D N S通信量，将只能看到服务器
因超出其高速缓存而不能处理的查询。
在默认情况下，名字解析器将在本地主机上（ U D P端口号为5 3或T C P端口号为5 3 ）寻找
名字服务器。从名字解析器文件中删除n a m e s e r v e r行，而留下d o m a i n行：
sun % cat /etc/resolv.conf
domain tuc.noao.edu
在这个文件中缺少n a m e r s e r v e r指示将导致名字解析器使用本地主机上的名字服务器。
----------------------- Page 13-----------------------
154使用TCP/IP详解，卷1：协议
下载
使用h o s t命令执行下列查询：
sun %host ftp.uu.net
f t p . u u . n e t A 1 9 2 . 4 8 . 9 6 . 9
图1 4 - 1 4显示了这个查询的输出结果。
图14-14 执行host ftp.uu.net后的t c p d u m p 输出
这次在t c p d u m p中使用了新的选项。使用- w选项来收集进出U D P或TCP 53号端口
的所有数据。将这些原始数据记录在一个文件中供以后处理，同时防止t c p d u m p试图
调用名字解析器来显示与那个I P地址相对应的域名。执行查询后，终止t c p d u m p并使
用- r选项再次运行它。它会读取含有原始数据的文件并产生正式的输出显示（如图 1 4 -
14）。这个过程要花费几秒钟，因为t c p d u m p调用了它自己的名字解析器。
在t c p d u m p输出中要注意的第一点是标识符 ( i d e n t i f i e r )是小整数（2和3 ）。这是因为我们
关闭这个名字服务器，后又重新启动它来强制清空它的高速缓存。当名字服务器启动时，它
将标识符初始化为1。
当键入查询，查找主机f t p . u u . n e t的I P地址，该名字服务器就同8个根名字服务器中的
一个n s . n i c . d d n . m i l （第1行）取得联系。这是以前见到的正常的 A类型查询，但要注意
的是它的期望递归表示没有说明（如果该标志被设置，在标识符 2 的后边会跟着一个加号）。
在以前的例子中，经常看到名字解析器设置期望递归标志，但这里的名字服务器在与某个根
服务器联系时没有设置这个标志。这是因为不应该向根名字服务器发出期望递归的查询，它
们仅用来寻找其他授权名字服务器的地址。
第2行显示返回的响应中没有回答资源记录，而包含 5个授权资源记录和5个附加信息资源
记录。标识符2后的减号表示期望递归标志（R A ）没有被设置。即使我们要求进行递归查询，
这个根名字服务器也不会回答期望递归查询。
尽管t c p d u m p没有显示返回的1 0个资源记录，我们也能执行h o s t命令来查看高速缓存的内容：
----------------------- Page 14-----------------------
第14章 DNS ：域名系统使用155
下载
这次采用- v选项查看的不仅仅只是A记录。它显示出对于域u u . n e t有5个授权名字服务
器，而由根名字服务器返回的 5个附加信息资源记录中含有这 5个名字服务器的I P地址。这避
免了在查找其中的某个名字服务器的地址时，无需再次与根名字服务器联系。这是 D N S 中的
另一个实现优化。
h o s t命令指出这个回答不是授权的，这是因为这个回答来自名字服务器的高速缓存，而
不是来自授权名字服务器。
回到图1 4 - 1 4中的第3行，我们的名字服务器与第一个授权名字服务器（ n s . u u . n e t）询
问同一个问题：f t p . u u . n e t的I P地址？这次我们的服务器设置了期望递归标志。返回的应
答（第4行）包含一个回答资源记录。
而后我们再次执行h o s t命令，询问相同的名字：
sun % host ftp.uu.net
ftp.uu.net A 1 9 2 . 4 8 . 9 6 . 9
这时t c p d u m p没有输出，这正是我们所期望的，因为由h o s t命令返回的回答来自于名字
服务器的高速缓存。
再次执行h o s t命令，查找f t p . e e . l b l . g o v的地址：
sun % host ftp.ee.lbl.gov
f t p . e e . l b l . g o v CNAME ee.lbl.gov
e e . l b l . g o v A 128.3.112.20
图1 4 - 1 5显示了这时的t c p d u m p输出。
图14-15 对f t p . e e . l b l . g o v 主机的t c p d u m p 输出
这时第1行显示我们的服务器与另一个根名字服务器(c . n y s e r . n e t)联系。一个名
字服务器通常轮询不同的根名字服务器来获得往返时间估计，然后选择往返时间最小
的服务器。
既然我们的服务器向一个根服务器发出查询，那么期望递归标志不应被设置。正如我们
在图1 4 - 1 4中所看到的该名字服务器并不清除期望递归标志（即便这样，一个名字服务器还是
不应该向一个根名字服务器发出期望递归的查询）。
在第2行返回的响应中不包含回答资源记录，但含有4个授权记录和4个附加信息资源记录。
正如我们所猜测的那样，4个授权资源记录是供主机 f t p . e e . l b l . g o v进行域名服务的名字
服务器名，其他4个记录则是这4个服务器的I P地址。
第3行是向名字服务器n s l . l b l . g o v （第2行中返回的4个名字服务器中的第一个）发出
的查询请求。它的期望递归标志是被设置的。
第4行返回的响应和以往的响应不同。返回了两个回答资源记录， t c p d u m p指出其中的第
一个是C N A M E资源记录。f t p . e e . l b l . g o v的规范名称是e e . l b l . g o v。
----------------------- Page 15-----------------------
156使用TCP/IP详解，卷1：协议
下载
这是C N A M E记录常见的用法。L B L 的F T P站点的名字通常是以f t p开始的，但它
可能不时地从一个主机移到另一个主机。用户只需要知道f t p . e e . l b l . g o v，必要时
DNS会用它的规范名进行替换。
记得我们在运行 h o s t程序时，它显示了规范域名的 C N A M E和I P地址。这是因为响应
（图1 4 - 1 5中的第4行）中含有两个回答资源记录，第一个是 C N A M E，而第二个是A记录。如
果A记录没有随C N A M E记录返回，我们的服务器将发出另一个查询请求，询问 e e . l b l . g o v
的I P地址。这是另一个D N S 的实现优化—在一个响应中同时返回一个规范域名的 C N A M E记
录和A记录。
14.8 用UDP还是用TCP
注意到D N S名字服务器使用的熟知端口号无论对 U D P还是T C P都是5 3 。这意味着D N S均
支持U D P和T C P访问，但我们使用t c p d u m p观察的所有例子都是采用U D P 。那么这两种协议
都在什么情况下采用以及采用的理由都是什么呢？
当名字解析器发出一个查询请求，并且返回响应中的 T C （删减标志）比特被设置为1时，
它就意味着响应的长度超过了 5 1 2个字节，而仅返回前5 1 2个字节。在遇到这种情况时，名字
解析器通常使用T C P重发原来的查询请求，它将允许返回的响应超过 5 1 2个字节（回想在11 . 1 0
节讨论的U D P数据报的最大长度）。既然T C P能将用户的数据流分为一些报文段，它就能用多
个报文段来传送任意长度的用户数据。
此外，当一个域的辅助名字服务器在启动时，将从该域的主名字服务器执行区域传送。
我们也说过辅助服务器将定时（通常是 3小时）向主服务器进行查询以便了解主服务器数据是
否发生变动。如果有变动，将执行一次区域传送。区域传送将使用 T C P ，因为这里传送的数
据远比一个查询或响应多得多。
既然D N S主要使用U D P ，无论是名字解析器还是名字服务器都必须自己处理超时和重传。
此外，不像其他的使用U D P 的I n t e r n e t应用（T F T P 、B O O T P和S N M P），大部分操作集中在局
域网上，D N S查询和响应通常经过广域网。分组丢失率和往返时间的不确定性在广域网上比
局域网上更大。这样对于D N S客户程序，一个好的重传和超时程序就显得更重要了。
14.9 另一个例子
让我们通过另一个例子将已经介绍的许多 D N S特性作一个综合性回顾。先启动 Rlogin 客
户程序，然后连接到一个位于其他域的 R l o g i n服务器。图1 4 - 1 6显示了发生的分组交换过程。
下面发生的11个步骤都假定客户和服务器的高速缓存中没有任何信息。
1) 客户程序启动后，调用它的名字解析器函数将我们键入的主机名转换为一个 I P地址。
一个A类型的查询请求被送往一个根服务器。
2) 由根服务器返回的响应中包含为该服务器所在域服务的名字服务器名。
3) 客户端的名字解析器将向该服务器的名字服务器重发上述 A类型查询，这个查询通常
是将期望递归标志设置为1。
4) 返回的应答中包含R l o g i n服务器的I P地址。
5) Rlogin客户和R l o g i n服务器建立一个T C P连接（第1 8章将提供该步骤的细节）。客户和
服务器的T C P模块间将交换3个分组。
----------------------- Page 16-----------------------
第14章 DNS ：域名系统使用157
下载
Rlogin 服务器的名
服务器 字服务器
根名字
服务器
根名字
服务器
R l o g i n 客户的名
客户 字服务器
图14-16 启动Rlogin客户和服务器的分组交换过程
6) Rlogin服务器收到来自客户的连接请求后，调用它的名字解析器通过 T C P连接请求中的
I P地址获得客户主机名。这是一个 P T R查询请求，由一个根名字服务器处理。这个根名字服
务器可以不同于步骤1中客户使用的根名字服务器。
7) 这个根名字服务器的响应中含有为客户的 i n - a d d r . a r p a域的名字服务器。
8) 服务器上的名字解析器将向客户的名字服务器重传上述 P T R查询。
9) 返回的P T R应答中含有客户主机的F Q D N 。
10) 服务器的名字解析器向客户的名字服务器发送一个 A类型查询请求，查找前一步返回
的名字对应的I P地址。这可能由服务器中的g e t h o s t b y a d d r函数自动完成，正如我们在1 4 . 5
节中介绍的那样，否则 R l o g i n服务器将完成这一步。此外，客户的名字服务器常常就是客户
的i n - a d d r . a r p a名字服务器，但这不是必需的。
11) 从客户的名字服务器返回的响应含有客户主机的 A记录。R l o g i n服务器将客户的T C P
连接请求中的I P地址与A记录作比较。
高速缓存将减少这个图中交换的分组数目。
14.10 小结
D N S是任何与I n t e r n e t相连主机必不可少的一部分，同时它也广泛用于专用的互联网。层
次树是组成D N S域名空间的基本组织形式。
应用程序通过名字解析器将一个主机名转换为一个 I P地址，也可将一个 I P地址转换为与
之对应的主机名。名字解析器将向一个本地名字服务器发出查询请求，这个名字服务器可能
通过某个根名字服务器或其他名字服务器来完成这个查询。
所有的D N S查询和响应都有相同的报文格式。这个报文格式中包含查询请求和可能的回答资
源记录、授权资源记录和附加资源记录。通过许多例子了解了名字解析器的配置文件以及D N S的
优化措施：指向域名的指针（减少报文的长度）、查询结果的高速缓存、i n - a d d r . a r p a域（查
找I P地址对应的域名）以及返回的附加资源记录（避免主机重发同一查询请求）。
习题
14.1 讨论一个DNS 名字解析器和一个D N S名字服务器作为客户程序、服务器或同时作为客
----------------------- Page 17-----------------------
158使用TCP/IP详解，卷1：协议
下载
户和服务器的情况。
14.2 说明图1 4 - 1 2中构成响应的7 5个字节的含义。
14.3 在1 2 . 3节我们指出，一个既可接受点分十进制形式的 I P地址、也可接收主机名的应用程
序，应先假定输入的是I P地址，如果失败，再假定是主机名。如果改变这个测试顺序会
出现什么情况？
14.4 每个U D P数据报有一个相应的长度。一个接收U D P数据报的进程将被告知这个长度。当
名字解析器使用T C P而不是U D P来处理查询请求时，由于T C P是没有任何记录标记的字
节流，那么应用程序是如何知道有多少数据返回？注意在 D N S 的报文首部（图1 4 - 3）中
没有任何长度字段（提示：查阅RFC 1035 ）
14.5 我们说一个名字服务器必须知道根名字服务器的 I P地址，这一信息可通过匿名F T P获得。
不幸的是当根名字服务器表发生变化时，并不是所有的系统管理员都会更新他们的 D N S
配置文件（根名字服务表的确会发生变化，尽管不是经常的）你认为 D N S如何处理这个
问题？
14.6 利用习题1 . 8指明的文件来确定谁应负责维护根名字服务器。名字服务器更新的频度是
怎样的？
14.7 维护一个名字服务器和一个无状态的名字解析器高速缓存的问题分别是什么？
14.8 在图1 4 - 1 0的讨论中，我们指出名字服务器将对A类型记录进行排序以便在公共网中的地
址先出现。谁对A类型记录进行这种排序，是名字服务器还是名字解析器 ?
1194
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
