次探DNS

之前已经写过一次DNS的文章了,不过那时刚接触,文中还有很多不正确的地方。DNS分为客户端和服务器端,客户端称为resolver,但是不是一个应用程序,而是一个函数库。在Linux里,resolver实现在libc库中,这个话题以后研究到再写。今天主要想总结一下域名服务器的查询方法,以及nslookup的使用方法。

域名系统是按层次划分的,从根域“.”开始。它可以使得不同域的主机可以改一样的名字,只要保证一个域里的名字不重复就可以了,类似于C++和Java的命名空间的好处。然后还要引入一个“区域(zone)”的概念,它跟“域(domain)”不同,区域指的是域里的管理范围。举个例子,假设域“.sysu.edu.cn”由中大管理,然后中大把子域“cs.sysu.edu.cn”授权给计算机系管理,那么中大管理的区域实际上是除了计算机系外的主机。也就是说,中大负责给各个主机域名解析,除了计算机系的主机外。

Domain Name System
Domain Name System

域定义了层次结构,区域定义了管理范围。每个区域可以授权下级管理一个子域,从而把子域所在的区域划出自己的管理。因此,每个区域的域名服务器只包含自己区域的名字解析,不包含已授权出去的子域的解析,但是会包含授权的子域的域名服务器名字。IANA规定每个区域至少包含两台DNS服务器。

比如想查询cisco.sysu.edu.cn。首先得查根域的域名服务器,查询“cisco.sysu.edu.cn”,但是根域中没有这个名字的解析,它会返回“.cn”子域的域名服务器。然后再向该域名服务器作同样的查询,这次还是没有得到结果,服务器只是返回“.edu.cn”的域名服务器。一直重复下去。

顺便值得一提的是,执行查询任务的DNS服务器一般是catch-only的服务器。DNS服务器分两种,一种是保存区域信息,另一种专门执行查询任务。我们在操作系统一般配置的DNS服务器就是catch-only的,只作查询任务的服务器。

RIP中的路由失效

RIP中路由失效后,一般过一段时间才会标记为16跳不可达,还有一段hold down的时间,才过一段时间才会删除。以前对RIP的路由失效的初步认识是这样的,但是一直没有做实验验证过,刚刚终于用Packet Tracert验证了一次。

首先,当192.168.1.0失效后。R1要等到Invalid计时器结束才会把该路由标记为16跳不可达,查看Invalid计时器的方法是“show ip protocols”。默认情况下Invalid计时器是180秒,然后路由更新的时间是30秒,那么也就意味着允许6次更新的丢失。实际上,RIP是使用UDP作为传输层协议的,所以有可能会丢失路由更新信息。

过了180秒之后,就到了Hold down的状态,我们称这个时间点为A。Hold down指的是不接受该路由的信息,Hold down状态持续的时间由holddown计时器决定,默认也是180秒。但是我在做实验的时候,虽然路由器处在Hold down状态,却还是接受该路由的信息,不知道是Packet Tracert的问题还是确实是这样,以后有机会再用真实机器试试看。

从时间点A过一定时间就会删除该路由,有flush计时器决定。flush计时器一般会比holddown计时器长,否则就会删除路由时还没结束Hold down状态,计时器默认是240秒。

如果不想等这么长时间,可以设置RIP采用触发更新,默认情况下没有开启。开启的方法是

Router(config-if)# ip rip triggered

但是Packet Tracert没有该命令,也要在真实机器试试。