TCP/IP详解 卷1:协议 学习笔记 第十四章 DNS:域名系统

本文详细阐述了DNS的作用、域名解析流程、顶级域名分类,以及DNS查询和响应机制。重点讲解了递归查询、区域划分、高速缓存和IP到域名的转换。通过实例演示了DNS查询过程和常见工具的使用,如host、dig和tcpdump。
摘要由CSDN通过智能技术生成

域名系统是一种用于TCP/IP应用程序的分布式数据库,它提供主机名和IP地址之间的转换以及有关电子邮件的选路信息。此处的分布式指在单个站点上不能拥有所有信息,每个站点(如大学中的系、公司)保留它自己的信息数据库,并运行一个服务器程序供Internet上其他系统查询。DNS提供了允许服务器和客户程序相互通信的协议。

从应用角度看,对DNS的访问是通过一个地址解析器完成的,在Unix主机中,该解析器主要通过库函数gethostbyname(通过主机名获取主机信息)和gethostbyaddr(通过地址获取主机信息)来访问。解析器通过一个或多个名字服务器完成这种转换。解析器通常是应用程序的一部分,而不像TCP/IP协议那样是操作系统的内核。

在一个应用程序请求TCP打开一个连接或使用UDP发送一个数据报之前,必须将主机名转换为IP地址。操作系统内核中的TCP/IP协议族不知道有DNS。

DNS的命名空间和Unix文件系统相似,也有层次结构:
在这里插入图片描述
上图中每个结点有一个至多63字符长的标识,这棵树的树根是没有任何标识的特殊结点。命名标识不区分大小写。命名树上任何一个结点的域名是将从该节点到最高层的域名串联起来,中间使用一个点.分割。域名树中每个结点必须有一个唯一的域名,但域名树中的不同结点可使用相同的标识。

以点结尾的域名称为绝对域名或完全合格的域名FQDN(Full Qualified Domain Name),如sun.tuc.noao.edu.,但是大部分的应用和服务器都允许忽略最后这个点。如果一个域名以点结尾,则认为该域名是完整的。FQDN由主机名+域名组成,如baidu.com是一个域名,www是一个主机名,两者一起组成FQDN,表示百度提供页面服务的主机。然而我们输入baidu.com就可以访问www.baidu.com,这是因为站点做了301重定向。

三种顶级域名:
1.arpa是一个用作地址到名字转换的特殊域。
2.7个3字符长的普通域,也称组织域。
3.所有2字符长的域都是基于ISO3166中定义的国家代码,称为国家域或地理域。

在这里插入图片描述
DNS中,通常认为3字符长的普通域仅用于美国的组织机构,2字符长的国家域则用于每个国家,但实际不总是这样,许多非美国的组织机构也使用普通域,而一些美国的组织机构也是用.us国家域。普通域中.gov和.mil域仅限于美国。

许多国家将顶级域名作为第二级域,如.ac.uk是英国研究机构的二级域名,.co.uk是英国商业机构的二级域名。

网络信息中心NIC负责分配顶级域和委派其他指定地区的域的授权机构。

一个独立管理的DNS子树被称为一个区域,一个常见的区域是二级域,如noao.edu,许多二级域将它们的区域划分为更小的区域,如大学按不同系划分区域。

一个区域的授权机构被委派后,由它负责向该区域提供多个名字服务器,当一个新系统加入一个区域时,该区域的DNS管理者为该新系统申请一个域名和一个IP地址,并将它们加到名字服务器的数据库。

一个名字服务器负责一个或多个区域,一个区域的管理者必须为该区域提供一个主名字服务器和至少一个辅助名字服务器。主、辅名字服务器必须是独立和冗余的,以便当某个名字服务器故障时不会影响该区域的名字服务。

主、辅名字服务器的主要区别在于主名字服务器从磁盘文件中调入该区域的所有信息,而辅名字服务器从主名字服务器调入所有信息,将辅名字服务器从主服务器调入信息称为区域传送。

当新主机加入一个区域时,区域管理者将适当信息(至少包括名字和IP)加入主名字服务器上的一个磁盘文件中,然后通知主名字服务器重新调入它的配置文件。辅名字服务器定时(通常每隔3小时)向主名字服务器询问是否有新数据,如有,通过区域传送方式获得新数据。

并不是每个名字服务器都知道如何与其他名字服务器联系,但名字服务器必须知道如何同根服务器联系,即必须知道根服务器的IP,这些IP在主名字服务器的配置文件中。根服务器知道所有二级域中每个授权名字服务器的名字和IP。名字服务器需要与其他名字服务器联系来获得自己没有的主机名到IP的映射信息,因此常会有以下过程:正处理请求的名字服务器与根服务器联系,根服务器告诉它如何与另一名字服务器联系。

DNS一个基本特性是使用超高速缓存,当名字服务器收到主机名到IP的映射信息时,它会将该信息存放在高速缓存中,若以后遇到相同的映射请求,就能直接使用缓存中的结果而无需通过其他服务器查询。
在这里插入图片描述
DNS查询和响应报文由12字节长的首部和4个长度可变的字段组成。

标识字段由客户程序设置,并由服务器直接复制返回,客户程序用它来确定响应与查询是否匹配。

16bit标志字段:
在这里插入图片描述
1.QR:0表示查询报文,1表示响应报文。
2.opcode:0表示标准查询,1表示反向查询(即通过查询IP地址的PTR记录来得到该IP地址指向的域名),2表示服务器状态请求。
3.AA:表示授权回答。该字段在响应报文中有效,1表示名字服务器是权威服务器,0表示名字服务器不是权威服务器。当查询到达DNS服务器时,服务器首先确定正在查询的信息是否驻留在服务器对其有权威的区域中(即权威)。如果服务器是所查询名称或地址所属区域的权威,那么服务器将以其本地区域文件中包含的信息来响应客户端。这种类型的响应称为权威回答(AA),因为提供响应的服务器对提供的数据有权威。来自名称服务器的权威答案在DNS响应的首部中开启了AA标志。
4.TC:表示可截断的。若值为1,表示当应答总长度超过512字节并已被截断,只返回了前512字节。
5.RD:表示期望递归。该比特在查询中可能会被设置,并在响应中被返回。此标志告诉名字服务器必须处理这个查询,此查询也被称为递归查询。当名字服务器不能回答某查询时,返回一个能解答该查询的其他名字服务器列表,然后向该列表中的服务器查询,这称为迭代查询。
6.RA:表示可用递归。如果名字服务器支持递归查询,则在响应中将该bit置为1。大多名字服务器都提供递归查询,除了某些根服务器。
7.随后的3bit必须为0。
8.rcode是一个4bit的返回码字段。0表示没有差错;3表示名字差错,只有对权威域名解析服务器有意义,指出解析的域名不存在。

标志字段之后的4个16bit字段说明最后4个变长字段中包含的条目数。对于查询报文,问题数通常是1,而其他3项为0;对于应答报文,回答数(即资源记录数)至少为1,之后的授权资源记录(即其他获取到的权威名字服务器)数和额外信息(即获取到的其他权威名字服务器对应的IP地址)数可以是0或非0。
在这里插入图片描述
查询名是要查找的名字,它是一个或多个标识符的序列,每个标识符以首字节的计数值来说明随后标识符的字节长度,每个名字以最后字节为0结束,长度为0的标识符是根标识符,计数字节的值必须是0~63的数,因为标识符的最大长度仅为63,如:
在这里插入图片描述
该字段无需以32bit边界结束,即无需填充字节。

每个问题都有一个查询类型,每个响应也有一个类型,每个类型对应一个值。最常用的是查询类型是A类型,表示期望获得查询名的IP地址。PTR查询请求获取一个IP地址对应的域名。

查询类字段通常是1,指IP地址。

DNS报文中的回答字段、授权字段、额外信息字段都采用一种称为资源记录RR(Resource Record)的相同格式:
在这里插入图片描述
域名字段、类型字段、类字段(通常为1)三项与DNS的查询问题字段中的相同。

生存时间字段是客户程序保留该资源记录的秒数,通常为2天。

资源数据长度字段说明资源数据字段的长度,该字段格式依赖于类型字段的值,类型字段为1(查询类型A)时,资源数据是4字节的IP地址。

DNS过程的例子:在sun主机上运行Telnet客户程序远程登录到gemini主机上,并连接daytime服务器:
在这里插入图片描述
我们引导sun主机上的名字解析器使用位于noao.edu上的名字服务器:
在这里插入图片描述
名字解析器是客户程序的一部分,且在Telnet客户程序与daytime服务器建立TCP连接前,名字解析器要先通过名字服务器获取IP地址。

文件/etc/reslove.conf将告诉名字解析器做什么:
在这里插入图片描述
nameserver后跟名字服务器的地址,最多可说明3个名字服务器提供名字服务器的备份,以防名字服务器故障或不可达。

domain是默认域名,当要查找的域名不是一个完整的域名(不以句点结束),默认域名会加到待查找名后。
在这里插入图片描述
可见源地址是名字解析器的IP,而目的地址是名字服务器的IP,目的端口号为53,这是名字服务器的知名端口号。

第一行中冒号后的1+表示标识字段为1,+表示RD标志(期望递归)为1,默认名字解释器要求递归查询。之后的A表示查询类型为A(需要一个IP地址),之后的问号表示它是一个查询而非响应。名字解析器在待查域名后加上一个点表示它是一个绝对域名。之后括号和其中的37表示UDP数据报中的用户数据长度为37字节(12字节用于DNS查询或应答首部、21字节用于要查询的域名、4个字节用于该域名的查询类型和查询类)。

第二行显示的是从名字服务器发回的响应,1表示标识字段为1,*表示设置AA标志(权威回答)。随后的2/0/0表示在响应报文中最后3个变长字段的资源数:回答RR数为2、授权RR和附加信息RR均为0。之后tcpdump只显示了第一个回答,回答类型为A(根据域名查IP地址)。应答的UDP数据长度为69字节,因为返回的结果中包含查询问题,且返回的结果中会有重复的域名,因此使用压缩方式,压缩方式的具体说明见后文。

以上查询得到两个结果的原因为gemini是多接口主机。

名为host的公开程序可进行DNS查询,使用它可以查看多地址主机的所有IP:
在这里插入图片描述
tcpdump获取到的gemini的IP和上图中的第一个IP是相同的,这不是偶然,如果名字服务器和发出请求的主机位于相同网络(或子网),那么BIND(Berkeley Internet Name Domain Service,是现今互联网上最常使用的DNS软件)会排列结果,在相同网络的地址优先显示。

我们可以使用排名第二的IP地址(140.252.3.54)访问gemini主机,但它可能效率比较低。使用traceroute程序显示,从子网140.252.1到140.252.3的路由不经过gemini主机,而是经过连接这两个网络的另一个路由器,此时如果通过第二个IP地址访问gemini主机,所有分组均需经过额外的一跳。

还有其他一些程序能对DNS进行交互访问。nslookup是大多数DNS实现中包含的程序;dig程序(Domain Internet Groper,域名Internet搜索)是另一个查询DNS服务器的公开工具,doc(Domain Obscenity Crontrol,域名模糊控制)是一个使用dig的外壳脚本程序,它能向合适的名字服务器查询给定域的权威名字服务器是否权威,并分析返回的查询结果(有时程序获得的权威名字服务器是不正确的)。

DNS报文中出现重复域名时可以将其压缩,压缩时,它的计数字节中的最高两位被设为11(计数字节的范围是0~63,每个标识符最长63字节,见图14-6),这表示它是一个16bit指针而非8bit计数字节,指针中剩下的14bit说明该域名在DNS报文中的位置(起始位置从DNS查询和响应报文的第一个字节,即标识字段的第一个字节开始算起)。一个指针可能指向一个完整的域名,也可能只指向域名的结尾部分(当当前域名的后部分与另一域名的后部分相同时)。

以下是tcpdump程序之前输出的DNS应答如下,下图显示,此DNS响应报文被封装在UDP数据报中,返回的两个回答除了IP地址不同外,其余是一样的,每个指针值为12,表示从DNS首部开始的偏移量:
在这里插入图片描述
使用telnet后注意输出:
在这里插入图片描述
我们仅输入了gemini,但输出了FQDN(Fully Qualified Domain Name,域的全名),这是由于Telnet通过调用名字解析器(gethostbyname函数)对输入的名字进行查询,返回的结果包括IP和FQDN,Telnet使用IP与目标建立TCP连接,建立连接后,输出了FQDN。

如果输入Telnet命令后间隔很长时间才显示IP地址,这个时延是由名字解析器和名字服务器在域名到IP地址的转换引起的,如果显示Trying到显示Connect的时延是由客户与服务器建立TCP连接引起的。

DNS指针查询指给定一个IP地址,返回与该地址对应的域名。

当一个组织加入Internet,并获得DNS域名空间的授权,它们也获得了对应IP地址的in-addr.arpa域名空间的授权,如IP为33.13.252.140的sun主机,它的DNS名字为33.13.252.140.in-addr.arpa(DNS名字从DNS的底部逐步向上书写,即IP是反转的,正常的名字解析器函数,如gethostbyaddr函数,反转IP和添加in-addr.arpa域由该函数自动完成),之后节点33后跟指向FQDN的指针:
在这里插入图片描述
如果DNS树中没有arpa独立分支,则IP到域名的转换只能通过从树根开始依次尝试每个顶级域,这将花费数天或数周的时间。

当一个IP数据报到达服务器主机时,无论是UDP数据报还是TCP连接请求,服务器进程所能获得的是客户的IP地址和端口号,某些服务器需要客户的IP地址获得其在DNS中的指针记录,而有的服务器如rlogin除了需要客户IP地址来获得指针记录,还需要向DNS发出指针查询得到客户的域名,然后再对PTR查询得到的域名进行A记录查询,并检查返回的IP地址是否对应源IP地址,这是因为该服务器的配置文件.rhosts中仅包含主机名,而没有IP地址,主机需要证实该主机名是否对应源IP地址。某些厂商将该项检查加入其名字解析器例程中,特别是gethostbyaddr函数,使得无需在应用中人为地进行这项检查。

以下是调用名字解析器gethostbyaddr函数时的例子,此例中,我们使用SunOS 4.13上的名字解析库,并且我们已在/etc/resolv.conf中将名字服务器设置为noao.edu,sun主机通过SLIP链路与它相连。以下是在sun主机上调用gethostbyaddr函数获取IP地址140.252.1.29(即sun主机)对应的域名时,tcpdump在SLIP链路上收到的内容:
在这里插入图片描述
上图中第一行是预期的指针查询,第二行是预期的响应。但第三行显示了该名字解析器函数自动对第二行返回的名字发出一个IP地址查询,由于发出指针查询的sun主机有两个IP地址,因此第四行的响应包含两个回答记录,如果第四行返回的两个地址中没有与gethostbyaddr函数的输入IP匹配的地址,函数会向系统日志发送一条消息,并向应用返回差错。

以下是一部分资源记录(RR),随着时间推移,会加入更多RR:
A:一个A记录定义了一个IP地址,它存储一个32bit的二进制数。
PTR:用于指针查询。
CNAME:表示规范名字(canonical name),是一个域名的别名,可使用它向其他系统提供一个易于记忆的别名,别名和真实域名都叫域名(domain name):
在这里插入图片描述
CNAME的部分用途如下:
1.我们可以给一个域名起多个别名,如域名www.a.com有两个别名,分别为www.b.comwww.c.com。当通过别名访问时,首先会通过CNAME资源记录,把两个别名映射回域名,再通过A资源记录,把域名映射为IP地址。如果服务器的地址改变了,我们也只需要更改A记录(域名到IP地址的映射),如果我们把以上3个地址都做成A记录,那么服务器的地址改变需要更改全部3个A记录,这样比较麻烦。
2.如果我们有多个服务器,这些服务器分布在全国各个不同的位置,我们可以通过CNAME和CDN(Content Delivery Network,内容分发网络)来加速用户的访问,具体过程为:首先设置一个CNAME,将用户要输入的别名(如www.a.com)指向CDN服务商提供的一个域名(如www.a.cdn.com),当用户输入www.a.com时,DNS会将该别名映射到域名www.a.cdn.com,然后会到CDN服务商处查找该域名的A记录,能到CDN服务商处查找A记录是因为,CDN公司购买cdn.com这个一级域名时,运营商会做一个NS记录(用来指定该域名由哪个DNS服务器来进行解析),即匹配到这个cdn.com后缀的域名都会到CDN服务提供商的DNS服务器处做解析,然后CDN全局负载均衡设备根据用户IP地址、用户请求的内容URL,选择一台用户所属区域的区域负载均衡设备,告诉用户向这台设备发起请求。
CNAME可以指向一个真实域名,也可以指向另一个别名域名。
对于一个域名,不可以同时解析它的CNAME记录和A记录,这是公网规则不允许,但原理上自己可以在内网这样做。
我们在输入网址时,经常在最前面加上www主机名。如我们有一台机器同时提供网页服务和邮件服务,这台机器的域名为mutiserver.website.com,我们为了用户便于访问这两个服务,所以可以该域名提供两个别名www.website.commail.website.com。因此,如果我们直接用A记录,可以不用在浏览器输入www开头的域名就可以访问网页。
HINFO:表示主机信息,包括说明主机CPU和操作系统的两个字符串,并非所有站点都提供它们系统的HINFO记录,并且提供的信息可能也不是最新的:
在这里插入图片描述
MX:邮件交换记录,用于:(1)一个没有连到Internet的站点能将一个连到Internet的站点作为它的邮件交换器,这两个站点用一种交替的方式交换到达的邮件,通常使用的协议是UUCP(UNIX间复制协议,Unix to Unix Copy Protocol)。(2)提供一种将无法到达其目的主机的邮件传送到一个替代主机的方式。(3)允许机构提供供他人发送邮件的虚拟主机,即使这样的主机名根本不存在。(4)防火墙网关(局域网与外界交流的路由)能使用MX记录限制外界与内部系统的连接。
许多不能与Internet连接的站点通过UUCP链路与一个连接在Internet上的站点相连接,通过MX记录能使用user@host这种邮件地址向那个站点发送电子邮件,如:
在这里插入图片描述
如上图,邮件处理器被告知如果有邮件要发往user@foo.com,就将邮件送到relay1.UU.NET或relay2.UU.NET。
每个MX记录被赋予一个16bit整数值,该值被称为优先值,如果一个目的主机有多个MX记录,它们按优先值从小到大顺序使用。
MX记录可用来处理主机脱机工作或不可达的情况,邮件处理器仅在无法使用TCP与目的主机连接时才使用MX记录。
NS:域名服务器记录,它说明一个域的授权名字服务器,用来指定该域名由哪个DNS服务器来进行解析。

所有名字服务器均使用高速缓存。标准UNIX实现中,高速缓存由名字服务器而非名字解析器(属于每个应用的一部分,而应用不可能总处于工作状态)维护,此处说的名字服务器指本地名字服务器,一般指电脑上网时IPv4或者IPv6设置中填写的那个DNS,可以是手工指定的或者是DHCP自动分配的。这样任何一个使用该本地名字服务器的应用均可获得高速缓存。
在这里插入图片描述
在上图的网络环境中,如果在sun主机上运行客户程序,会通过主机noao.edu的SLIP链路访问名字服务器,现在我们改变这种设置,在sun主机上直接运行名字服务器,此时,我们使用tcpdump监视SLIP链路上的DNS通信量,将只能看到服务器因超出其高速缓存而不能处理的查询。

默认,名字解析器将在本地主机(端口号53)上寻找名字服务器,当名字解析器文件中有nameserver行时,会到nameserver行指定的地址寻找名字服务器,因此删掉nameserver行可以使名字解析器使用本地主机上的名字服务器,删掉后名字解析器文件内容如下图:
在这里插入图片描述
当使用host命令执行下列查询时:
在这里插入图片描述
下图是这个查询的tcpdump的输出:
在这里插入图片描述
关于上图中的内容:tcpdump命令使用了-w选项将抓包的原始数据放入一个文件中以供以后处理,这些数据内容是进出UDP或TCP 53号端口的所有数据,存放原始数据的过程中,tcpdump不会调用名字解析器来显示与IP地址相对应的域名。我们可以使用tcpdump的-r选项读取含有原始数据的文件并产生上图的输出显示,这个过程要花费几秒钟,因为tcpdump调用了它自己的名字解析器。

上图中,DNS首部标识字段是小整数(2和3),这是因为我们刚重启过这个名字服务器,强制清空了它的高速缓存。当名字服务器启动时,它将标识字段初始化为1。

执行host命令查找指定域名的地址时,本地名字服务器就同8个根名字服务器中的一个取得联系(上图第一行),这个向根名字服务器发出的A类型查询没有设置期望递归位(如果设置了,标识符2的后面会有一个加号),不应该向根名字服务器发出期望递归的查询,上图本地域名服务器只是为了寻找授权名字服务器的地址,用的是迭代查询。

上图第一行中,本地名字服务器先向一个根名字服务器ns.nic.ddn.mil取得联系,这是正常的A类型查询。

第二行返回的响应中没有回答资源记录,而是包含5个授权资源记录和5个附加信息资源记录,标识符2后的减号表示期望递归标识(RA)没有被设置,即使我们要求进行递归查询,这个根名字服务器也不会回答期望递归查询。

即使根名字服务器不清除期望递归标志,我们也不应该向一个根名字服务器发出期望递归的查询。

执行host查看高速缓存中的内容:
在这里插入图片描述
如上图,对于域名ftp.uu.net,根服务器给出了5个授权名字服务器,而这5个授权名字服务器的IP地址在5个附加信息资源记录中,这避免了在以后再查找其中某个名字服务器的地址时,再次与根名字服务器联系。

上图中host命令指出这个回答不是权威的,而是来自本地名字服务器的高速缓存,而非来自授权名字服务器。

再次执行host命令查找另一个域名的IP:
在这里插入图片描述
查看tcpdump的输出:
在这里插入图片描述
第一行显示我们这次换了一个根服务器,本地的名字服务器通常轮询不同的根名字服务器来获得往返时间估计,然后选择往返时间最小的根名字服务器。

第二行返回了4个授权记录和4个附加信息资源记录,4个授权资源记录供要查询的域名进行域名IP转换服务,而4个附加信息资源记录包含这4个权威名字服务器的IP地址。

第三行是向第二行返回的权威名字服务器中的一个发出查询请求,它的期望递归标志是被设置的。

第四行返回了两个回答资源记录,tcpdump指出其中第一个是CNAME资源记录,即要查询的域名ftp.ee.lbl.gov的规范名称是ee.lbl.gov,这是CNAME记录常见的用法,此站点的名字通常是ftp.ee.lbl.gov,但它可能不时地从一个主机移到另一个主机,用户只需知道ftp.ee.lbl.gov,必要时DNS会用它的规范名进行替换。此回答中可能只有CNAME记录而没有A记录,此时本地DNS服务器将发出另一个查询请求,询问ee.lbl.gov的IP地址。

DNS名字服务器无论对UDP还是TCP端口号都是53,这意味着DNS支持UDP和TCP访问,但以上tcpdump观察的例子中使用的都是UDP。

当名字解析器发出UDP查询请求,且返回响应中的TC(删减标志)被置位时,意味着响应长度超过了512字节,而仅返回了前512字节,此时名字解析器通常用TCP重发原来的查询请求,这将允许返回的响应超过512字节(UDP不会进行分段,而TCP可以将用户的数据流分为一些报文段,就能用多个报文段来传送任意长度的用户数据了)。

当一个域名的辅助名字服务器在启动时,将从该域名的主名字服务器执行域名传送。辅助服务器将定时(通常是3小时)向主服务器进行查询以便了解主服务器数据是否发生变动,如果有变动,将执行一次域名传送。域名传送将使用TCP,因为传送的数据远比一个查询或响应多得多。

既然DNS主要使用UDP,无论名字解析器还是名字服务器都必须自己处理超时和重传,不像其他常见的UDP应用(TFTP(Trivial File Transfer Protocol,简单文件传输协议)、BOOTP、SNMP(简单网络管理协议))一样大部分操作集中在局域网上,DNS查询和响应通常经过广域网,因此分组丢失率和往返时间的不确定性上更大。

当客户和服务器的高速缓存都为空时,运行rlogin程序的过程:
在这里插入图片描述
上图过程如下:
(1)客户程序启动后,调用它的名字解析器函数将我们键入的主机名转换为一个IP地址,一个A类查询请求被送往一个根服务器。
(2)由根服务器返回的响应中包含为要查询的域名服务的权威名字服务器名。
(3)客户端的名字解析器向该域名的权威名字服务器重发A类查询,这个查询的期望递归标志置为1。
(4)返回的应答中包含rlogin要连接的域名的IP地址。
(5)rlogin客户和rlogin服务器建立一个TCP连接。
(6)rlogin服务器收到来自客户的连接请求后,调用它的名字解析器发送一个PTR查询请求,此PTR查询请求的IP地址是从收到的TCP连接中取得的,由一个根名字服务器处理。
(7)根名字服务器响应中包含为in-addr.arpa域的客户服务的名字服务器。
(8)rlogin服务器上的名字解析器向in-addr.arpa域服务的名字服务器重传PTR查询。
(9)返回的PTR应答中含有客户主机的FQDN。
(10)rlogin服务器的名字解析器向客户域名的权威名字服务器发送一个A类请求,查找前一步返回的名字对应的IP地址,这可能由gethostbyaddr函数自动完成,如果不是这样,rlogin服务器就要自己完成这一步。客户域名的权威名字服务器常常就是客户IP的权威in-addr.arpa名字服务器,但这并不是必须的。
(11)从客户的名字服务器返回的响应含有客户主机的A记录,rlogin服务器将客户的TCP连接请求中的IP地址与A记录作比较。

一个DNS名字解析器总是一个客户,但一个DNS名字服务器可以既是一个客户又是一个服务器。

当DNS请求报文使用UDP时,UDP报文头中含报文长度字段,接收进程就知道报文的长度。而当使用TCP时,由于TCP首部没有标识整个TCP段长的字段,而DNS报文首部也没有长度字段,且TCP是面向字节流的,没有任何记录标识,因此DNS报文前才会有2个字节长的长度字段。

一个名字服务器可通过匿名FTP获取根名字服务器的IP地址,当根名字服务器发生变化时,名字服务器通过以下方式更新信息:当名字服务器启动时,它一般从一个磁盘文件中读出一个根服务器列表(其中可能含过时的根名字服务器),然后尝试和这些根服务器中的一个联系,发送一个NS类型查询,此查询会返回当前最新的根服务器列表,这需要至少一个磁盘文件中的根服务器项是有效的。

DNS查询过程:
1.主机先向本地域名服务器进行递归查询。
2.本地域名服务器采用迭代查询,向一个根域名服务器进行查询。
3.根域名服务器告诉本地域名服务器,下一次应该查询的顶级域名服务器的IP地址。
4.本地域名服务器向顶级域名服务器进行查询。
5.顶级域名服务器告诉本地域名服务器一个该域名的权威服务器列表,下一步向该域名的权威服务器的IP地址进行查询。
6.本地域名服务器继续向权威服务器进行查询,直到查到IP地址。
7.本地域名服务器最后把查询结果告诉主机。

上述过程中需要注意递归查询和迭代查询是不同的:
1.递归查询:一般用于主机向本地域名服务器的查询,表示主机只发一次查询就要获得结果,如果主机所询问的本地域名服务器不知道被查询的域名的IP地址,那么本地域名服务器就以DNS客户的身份,向其它根域名服务器继续发出查询请求报文(即替主机继续查询),而不是让主机自己进行下一步查询。
2.迭代查询:本地域名服务器向根域名服务器发出查询并获得权威名字服务器列表后,本地域名会进行迭代查询,即向权威名字服务器列表中的每一个进行查询,直到获得域名对应的IP地址。当根域名服务器收到本地域名服务器发出的迭代查询请求报文时,要么给出所要查询的IP地址,要么告诉本地服务器下一步应当向哪一个域名服务器进行查询。一般根域名服务器把自己知道的顶级域名服务器的IP地址告诉本地域名服务器,让本地域名服务器再向顶级域名服务器查询,顶级域名服务器在收到本地域名服务器的查询请求后,要么给出所要查询的IP地址,要么告诉本地服务器下一步应当向哪一个权威域名服务器进行查询。查询最后,知道了所要解析的IP地址或报错,然后本地域名服务器把这个结果返回给发起查询的主机。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值