• 2007年09月06日

    Dns.Resolve方法解析

    分类:

    1.         DNS(英文单词的全称是:Domain Name System,域名系统),DNS是因特网的一项核心服务,它作为可以将域名和IP地址相互映射的一个分布式数据库,能够使人更方便的访问互联网,而不用去记住能够被机器直接读取的IP地址。

    2.         DNS解析的原理

    第一步:客户机提出域名解析请求,并将该请求发送给本地的域名服务器。

    第二步:当本地的域名服务器收到请求后,就先查询本地的缓存,如果有该纪录项,则本地的域名服务器就直接把查询的结果返回。

    第三步:如果本地的缓存中没有该纪录,则本地域名服务器就直接把请求发给根域名服务器,然后根域名服务器再返回给本地域名服务器一个所查询域(根的子域)的主域名服务器的地址。

    第四步:本地服务器再向上一步返回的域名服务器发送请求,然后接受请求的服务器查询自己的缓存,如果没有该纪录,则返回相关的下级的域名服务器的地址。

    第五步:重复第四步,直到找到正确的纪录。

    第六步:本地域名服务器把返回的结果保存到缓存,以备下一次使用,同时还将结果返回给客户机。

      举一个例子来详细说明解析域名的过程.假设我们的客户机如果想要访问站点:www.linejet.com, 此客户机本地的域名服务器是dns.company.com , 一个根域名服务器是NS.INTER.NET , 所要访问的网站的域名服务器是dns.linejet.com,域名解析的过程如下所示:

      (1)客户机发出请求解析域名www.linejet.com的报文

      (2)本地的域名服务器收到请求后, 查询本地缓存, 假设没有该纪录, 则本地域名服务器dns.company.com则向根域名服务器NS.INTER.NET发出请求解析域名www.linejet.com

      (3)根域名服务器NS.INTER.NET收到请求后查询本地记录得到如下结果:linejet.com NS dns.linejet.com(表示linejet.com域中的域名服务器为:dns.linejet.com,同时给出dns.linejet.com的地址,并将结果返回给域名服务器dns.company.com

      (4)域名服务器dns.company.com收到回应后,再发出请求解析域名www.linejet.com的报文。

      (5)域名服务器 dns.linejet.com收到请求后,开始查询本地的记录,找到如下一条记录:www.linejet.com A 211.120.3.12 (表示linejet.com域中域名服务器dns.linejet.comIP地址为:211.120.3.12,并将结果返回给客户本地域名服务器dns.company.com

      (6)客户机本地域名服务器将返回的结果保存到本地缓存,同时将结果返回给客户机。

    这样就完成了一次域名解析过程。

     

    3.         FileMonProcess Monitor(适用于Windows Vista及以上Windows操作系统)可以发现Windows当前的DNS Cache存放在“%windir%\Prefetch\IPCONFIG.EXE-*.pf”内,用文本编辑器以Western European(Windows)编码格式能完整打开这个文件,但内容却是方块等不能识别的字符。幸运的是,Window提供了ipconfig.exe这个工具,用命令ipconfig /displaydns就能查看IPCONFIG.EXE-*.pf,缓存包括从本地主机文件(hosts)中预加载的项目以及最新获得的有关系统所解析的名称查询的任何资源记录;当需要刷新和重置本机DNS缓存时,可以使用命令ipconfig /flushdns,此命令能从本机缓存中去除否定性缓存项目和任何其他动态添加的项目。

     

    4.         Dns.Resolve方法

    [C#]

    public static IPHostEntry Resolve (

        string hostName

    )

    从此函数原型可以看出,传入的参数只有一个需要解析的域名,而没有显示能查询的DNS Server。众所周知,DNS解析需要一个能提供DNS查询服务的DNS Server才能完成。那么,这个未被指定的DNS Server到底来自哪呢?下面用实验来找出DNS Server的来源。(注意:实验的机器必须保持干净,不能安装防火墙之类的客户端,因为防火墙的设置会覆盖系统设置)

    首先写一个程序调用Dns.Resolve方法,准备用Microsoft Network Monitor抓本机网络包;运行该程序,同时Network Monitor开始Start Capture(F10),得到下图

    从图中可以看到,此方法发送DNS查询请求给157.60.74.5这个IP。这个IP来自于系统预设的DNS Sever,用命令ipconfig /all得到下图:

     

    如果该程序成功返回查询域名的IP地址,此时在CMD下用命令ipconfig /displaydns就看到此域名已经加入本机的DNS Cache。在成功的结果下,若再次请求解析该域名,从Network Monitor中会发现没有本机DNS的包再被发出。

    下面换一个不能被本机DNS Server解析的域名,在Network Monitor得到下图:

    从“Destination”栏可以看到,先发送广播包,然后发送给第一个WINS Server,最后发送给第二个WINS Server

     

    5.         从上面的实验可以得到如下结论:APIDns.Resolve执行顺序为

    1)         查找本机DNS cache

    2)         向本机DNS Server发送DNS Query命令,若成功把该域名加入本机DNS Cache。(如果dnsproxy Enable,这步会读取dnsproxy)

    3)         先发送广播包,再按WINS Server的顺序发送请求。

     

    6.         意义:对性能测试软件来说,细分图里面都会有一项DNS解析时间,而该时间正是通过计算Dns.Resolve的运行时间得出的。通过分析,可以比较深刻地了解Windows下这项结果的真实表述。

     

    【资源】

    DNS related RFCs

    Intro to Name Resolution


    历史上的今天:

    套接字编程 2008年09月06日
    IDR_MAINFRAME资源 2008年09月06日
    Borland复活Turbo品牌 2006年09月06日

    收藏到:Del.icio.us




    评论

  • 更正:第6点的结论是错误的,请看倌不要被误导。