速读原著-TCP/IP(DNS示例)
第14章 DNS：域名系统
14.4 一个简单的例子
让我们从一个简单的例子来了解一个名字解析器与一个名字服务器之间的通信过程。在s u n主机上运行Te l n e t客户程序远程登录到g e m i n i主机上，并连接d a y t i m e服务器：
在这个例子中，我们引导 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显示了这三个系统的排列情况。
和以前提到的一样，名字解析器是客户程序的一部分，并且在 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连接的细节（参见封2的插图），因为它不影响我们的讨论。通过在S L I P链路上运行t c p d u m p程序来了解名字解析器与名字服务器之间的分组交换。
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显示了名字解析器与名字服务器之间的分组交换。
让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。
为什么我们的查询会得到两个回答？这是因为 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图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字节。为说明这些字节需要知道以下两点：
- 在返回的结果中包含查询问题。
- 在返回的结果中会有许多重复的域名，因此使用压缩方式。在这个例子中，域名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
我们仅仅输入了主机名 (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无关。