DNS服务器工作原理

amwdnuff

DNS服务器工作原理
分布的信息
　　解决方案就是采用DNS服务器系统。与主机表不一样，DNS服务器不依赖一个大型映射文件，DNS服务器只包含有限的信息，因为他们知道到哪里能找到他们想知道的域的细节。当DNS服务器得到对某个主机的请求，而该请求的主机又并不在其缓冲内，那么DNS服务器只是知道了这件事然后去询问知道答案的“某计算机”。这台计算机是一种授权服务器，负责维护DNS信息。如果某台服务器在被询问到其域内的某个地址时它可以确定地指出该地址存在，那么这台服务器就是所谓的授权服务器。
　　
　　如果接触的服务器并不包含有关的域名信息，该服务器就会将请求传递给接触链路上更高级别的授权服务器，这样就形成了一系列查询直到最后找到需要的信息。实际上，这意味着请求可以被任意数量的服务器处理，在Internet上这种来来回回的行为每时每刻都在发生。最早发出请求的服务器将缓冲信息以满足未来的需求而无须向授权服务器再发请求。DNS服务器的管理员为这些信息设置了超时限制以避免缓冲中充满了名字请求的旧数据。
　　
　　DNS转换不会花费太多的时间，但它确实增加了你的请求到达远端计算机的时间。你可以自己做个快速测试（虽然很简单）：首先用域名，比如www.microsoft.com来访问对应的Web站点，然后用IP地址198.105.232.4再实验一下。如果你要这么做，则请务必关闭你的浏览器然后再重新打开以初始化新的会话；否则你不过是载入了页面的缓冲版本（记住装载页面的延迟原因可能来自许多因素，所以对结果要有所保留）。
　　
　　DNS服务的最常用软件是Berkeley Internet Name Domain，也就是BIND，它源自U.C. Berkeley但现在则由Internet Software Consortium.负责。其最新版本4.9.3包含了标准的 Unix版本和附加的Windows NT 端口。BIND提供了解析器和名字服务器软件，解析器做实际的查询工作而名字服务器则提供响应。BIND将名字服务器分成三个部分：主服务器包含了有关一个域的全部数据；次服务器则有效地从主服务器拷贝DNS数据库；唯缓冲服务器通过缓冲查询来建立例外的DNS数据库。只有主服务器和次服务器才被当作涉及特定域的授权服务器。
　　
　　要理解 DNS 服务器怎么操作就有必要理解域名层次本身。在这一层次的顶部是根域。这一域上的信息驻留在从整个Internet中所选的一些根服务器上。在根域下面是顶级域，也就是国家代码或机构代码。国家代码的例子有SG （新加坡）和CA （加拿大）等。而机构代码则包括众所周知的COM（商业机构）、EDU（教育机关）、GOV（政府机构）和NET（网络机构）等（注意在美国以外的顶级域通常是国家编码，但是基于美国的地点通常省略国家编码）。在顶级域下面是次级域（whitehouse.gov、microsoft.com、inforamp.net 等诸如此类），然后是第 3级域，等等等等向下以此类推。
　　
　　如果你想在美国建立域名，那么你必须联系网络信息中心NIC。在它同意你的请求以前，你首先要保证你想要的名字还没被使用，其次要保证目前至少有 2台服务器可以提供新域名的服务。当 NIC 最后同意请求时，它将承认你的次级域，并将指向该名字的指针放到顶级域所在的服务器内。例如，如果你请求域名mybiz.com，那么你必须首先让Internet上的2 台名字服务器提供信息服务（你的 ISP的服务器能做到这一点），然后NIC 将把 mybiz 放到COM 域服务器系统内，其指针将指向那2台特定服务器。
　　
　　一旦设置了适当的主域，你就可以增加所希望的任何数量的子域。你可能想要命名你的计算机为sales.mybiz.com，而另一台则被叫做techsupport.mybiz.com等等。这些工作可就不需要 NIC 的同意了，而且，事实上NIC也不管这事。但是，如果你想要任何人都能实际地访问你的子域，那么你最好将有关子域的信息尽快地放到上级域内。在特定的情况下，关于sales.mybiz.com 和 techsupport.mybiz.com 的IP信息必须放在mybiz.com服务器上。这一层次中的每台服务器都包含了一个DNS数据库，其入口被称作NS记录，每条这样的记录包含了域或子域的名字，此外还加上作为域或者子域服务器的主机的名字。在我们的例子中，我们将告诉根服务器它能在我们的 DNS 服务器上找到mybiz.com及其全部子域的信息，而这些信息则位于details.mybiz.com这台计算机上。
　　
　　现在我们来看看这一切是如何运作的。某所大学的某人在指向你的最新子域的网页上看见了一个链接 techsupport.mybiz.com。然后她点击该链接，于是她的本地DNS 服务器（很可能位于这所大学的某台计算机上）开始工作。首先，服务器搜索它自己的 DNS数据库以转换信息，但是，因为它以前从来没遇见过 techsupport.mybiz.com，所以服务器没有该域存在的记录而且不能解析IP地址。不过，它的 DNS 数据库包含了一个根服务器的地址（所有的 DNS 服务器必须设置该索引）。于是本地 DNS 服务器就到Internet上查询该根服务器。根服务器在其DNS 数据库里查找COM 顶级域，然后它用NS 记录回复该大学的 DNS 服务器，告诉它可以从details.mybiz.com 处查询到mybiz.com 的信息。大学的服务器就这样做了，而且从 details.mybiz.com那里知道了techsupport.mybiz.com 的对应IP 地址。在这一过程中最根本的阶段是，大学的DNS 服务器缓冲了该 NS 记录，结果下次该大学的任何人在需要涉及到mybiz.com、details.mybiz.com 、ortechsupport.mybiz.com等对应的IP地址转换时，相关信息在本地即可获得。
　　
　　正如其他的Internet协议一样，DNS由几个Internet的RFC（请求评论）规范（最初是RFC 882、883和973）。不过要理解DNS 服务器的工作原理最好的标准还是RFC 1035。你可以在Internet上的好几个地方找到RFC 1035，比如在http://www.crynwr.com/crynwr/rfc1035/ 就有一个不错的HTML 版本。正如你可能想到的那样，RFC具有相当的技术性，你不大可能会对超出DNS 服务器一般操作的细节感兴趣。但是如果你想做个服务器管理员，那么就记住 RFC吧。

chuanyuan

感谢分享~谢谢

nmgwp

谢谢楼主分享！

zh_ligang

这段时间就这个闹的

amwdnuff

DNS服务器工作原理
分布的信息
　　解决方案就是采用DNS服务器系统。与主机表不一样，DNS服务器不依赖一个大型映射文件，DNS服务器只包含有限的信息，因为他们知道到哪里能找到他们想知道的域的细节。当DNS服务器得到对某个主机的请求，而该请求的主机又并不在其缓冲内，那么DNS服务器只是知道了这件事然后去询问知道答案的“某计算机”。这台计算机是一种授权服务器，负责维护DNS信息。如果某台服务器在被询问到其域内的某个地址时它可以确定地指出该地址存在，那么这台服务器就是所谓的授权服务器。
　　
　　如果接触的服务器并不包含有关的域名信息，该服务器就会将请求传递给接触链路上更高级别的授权服务器，这样就形成了一系列查询直到最后找到需要的信息。实际上，这意味着请求可以被任意数量的服务器处理，在Internet上这种来来回回的行为每时每刻都在发生。最早发出请求的服务器将缓冲信息以满足未来的需求而无须向授权服务器再发请求。DNS服务器的管理员为这些信息设置了超时限制以避免缓冲中充满了名字请求的旧数据。
　　
　　DNS转换不会花费太多的时间，但它确实增加了你的请求到达远端计算机的时间。你可以自己做个快速测试（虽然很简单）：首先用域名，比如www.microsoft.com来访问对应的Web站点，然后用IP地址198.105.232.4再实验一下。如果你要这么做，则请务必关闭你的浏览器然后再重新打开以初始化新的会话；否则你不过是载入了页面的缓冲版本（记住装载页面的延迟原因可能来自许多因素，所以对结果要有所保留）。
　　
　　DNS服务的最常用软件是Berkeley Internet Name Domain，也就是BIND，它源自U.C. Berkeley但现在则由Internet Software Consortium.负责。其最新版本4.9.3包含了标准的 Unix版本和附加的Windows NT 端口。BIND提供了解析器和名字服务器软件，解析器做实际的查询工作而名字服务器则提供响应。BIND将名字服务器分成三个部分：主服务器包含了有关一个域的全部数据；次服务器则有效地从主服务器拷贝DNS数据库；唯缓冲服务器通过缓冲查询来建立例外的DNS数据库。只有主服务器和次服务器才被当作涉及特定域的授权服务器。
　　
　　要理解 DNS 服务器怎么操作就有必要理解域名层次本身。在这一层次的顶部是根域。这一域上的信息驻留在从整个Internet中所选的一些根服务器上。在根域下面是顶级域，也就是国家代码或机构代码。国家代码的例子有SG （新加坡）和CA （加拿大）等。而机构代码则包括众所周知的COM（商业机构）、EDU（教育机关）、GOV（政府机构）和NET（网络机构）等（注意在美国以外的顶级域通常是国家编码，但是基于美国的地点通常省略国家编码）。在顶级域下面是次级域（whitehouse.gov、microsoft.com、inforamp.net 等诸如此类），然后是第 3级域，等等等等向下以此类推。
　　
　　如果你想在美国建立域名，那么你必须联系网络信息中心NIC。在它同意你的请求以前，你首先要保证你想要的名字还没被使用，其次要保证目前至少有 2台服务器可以提供新域名的服务。当 NIC 最后同意请求时，它将承认你的次级域，并将指向该名字的指针放到顶级域所在的服务器内。例如，如果你请求域名mybiz.com，那么你必须首先让Internet上的2 台名字服务器提供信息服务（你的 ISP的服务器能做到这一点），然后NIC 将把 mybiz 放到COM 域服务器系统内，其指针将指向那2台特定服务器。
　　
　　一旦设置了适当的主域，你就可以增加所希望的任何数量的子域。你可能想要命名你的计算机为sales.mybiz.com，而另一台则被叫做techsupport.mybiz.com等等。这些工作可就不需要 NIC 的同意了，而且，事实上NIC也不管这事。但是，如果你想要任何人都能实际地访问你的子域，那么你最好将有关子域的信息尽快地放到上级域内。在特定的情况下，关于sales.mybiz.com 和 techsupport.mybiz.com 的IP信息必须放在mybiz.com服务器上。这一层次中的每台服务器都包含了一个DNS数据库，其入口被称作NS记录，每条这样的记录包含了域或子域的名字，此外还加上作为域或者子域服务器的主机的名字。在我们的例子中，我们将告诉根服务器它能在我们的 DNS 服务器上找到mybiz.com及其全部子域的信息，而这些信息则位于details.mybiz.com这台计算机上。
　　
　　现在我们来看看这一切是如何运作的。某所大学的某人在指向你的最新子域的网页上看见了一个链接 techsupport.mybiz.com。然后她点击该链接，于是她的本地DNS 服务器（很可能位于这所大学的某台计算机上）开始工作。首先，服务器搜索它自己的 DNS数据库以转换信息，但是，因为它以前从来没遇见过 techsupport.mybiz.com，所以服务器没有该域存在的记录而且不能解析IP地址。不过，它的 DNS 数据库包含了一个根服务器的地址（所有的 DNS 服务器必须设置该索引）。于是本地 DNS 服务器就到Internet上查询该根服务器。根服务器在其DNS 数据库里查找COM 顶级域，然后它用NS 记录回复该大学的 DNS 服务器，告诉它可以从details.mybiz.com 处查询到mybiz.com 的信息。大学的服务器就这样做了，而且从 details.mybiz.com那里知道了techsupport.mybiz.com 的对应IP 地址。在这一过程中最根本的阶段是，大学的DNS 服务器缓冲了该 NS 记录，结果下次该大学的任何人在需要涉及到mybiz.com、details.mybiz.com 、ortechsupport.mybiz.com等对应的IP地址转换时，相关信息在本地即可获得。
　　
　　正如其他的Internet协议一样，DNS由几个Internet的RFC（请求评论）规范（最初是RFC 882、883和973）。不过要理解DNS 服务器的工作原理最好的标准还是RFC 1035。你可以在Internet上的好几个地方找到RFC 1035，比如在http://www.crynwr.com/crynwr/rfc1035/ 就有一个不错的HTML 版本。正如你可能想到的那样，RFC具有相当的技术性，你不大可能会对超出DNS 服务器一般操作的细节感兴趣。但是如果你想做个服务器管理员，那么就记住 RFC吧。

amwdnuff

DNS服务器工作原理
分布的信息
　　解决方案就是采用DNS服务器系统。与主机表不一样，DNS服务器不依赖一个大型映射文件，DNS服务器只包含有限的信息，因为他们知道到哪里能找到他们想知道的域的细节。当DNS服务器得到对某个主机的请求，而该请求的主机又并不在其缓冲内，那么DNS服务器只是知道了这件事然后去询问知道答案的“某计算机”。这台计算机是一种授权服务器，负责维护DNS信息。如果某台服务器在被询问到其域内的某个地址时它可以确定地指出该地址存在，那么这台服务器就是所谓的授权服务器。
　　
　　如果接触的服务器并不包含有关的域名信息，该服务器就会将请求传递给接触链路上更高级别的授权服务器，这样就形成了一系列查询直到最后找到需要的信息。实际上，这意味着请求可以被任意数量的服务器处理，在Internet上这种来来回回的行为每时每刻都在发生。最早发出请求的服务器将缓冲信息以满足未来的需求而无须向授权服务器再发请求。DNS服务器的管理员为这些信息设置了超时限制以避免缓冲中充满了名字请求的旧数据。
　　
　　DNS转换不会花费太多的时间，但它确实增加了你的请求到达远端计算机的时间。你可以自己做个快速测试（虽然很简单）：首先用域名，比如www.microsoft.com来访问对应的Web站点，然后用IP地址198.105.232.4再实验一下。如果你要这么做，则请务必关闭你的浏览器然后再重新打开以初始化新的会话；否则你不过是载入了页面的缓冲版本（记住装载页面的延迟原因可能来自许多因素，所以对结果要有所保留）。
　　
　　DNS服务的最常用软件是Berkeley Internet Name Domain，也就是BIND，它源自U.C. Berkeley但现在则由Internet Software Consortium.负责。其最新版本4.9.3包含了标准的 Unix版本和附加的Windows NT 端口。BIND提供了解析器和名字服务器软件，解析器做实际的查询工作而名字服务器则提供响应。BIND将名字服务器分成三个部分：主服务器包含了有关一个域的全部数据；次服务器则有效地从主服务器拷贝DNS数据库；唯缓冲服务器通过缓冲查询来建立例外的DNS数据库。只有主服务器和次服务器才被当作涉及特定域的授权服务器。
　　
　　要理解 DNS 服务器怎么操作就有必要理解域名层次本身。在这一层次的顶部是根域。这一域上的信息驻留在从整个Internet中所选的一些根服务器上。在根域下面是顶级域，也就是国家代码或机构代码。国家代码的例子有SG （新加坡）和CA （加拿大）等。而机构代码则包括众所周知的COM（商业机构）、EDU（教育机关）、GOV（政府机构）和NET（网络机构）等（注意在美国以外的顶级域通常是国家编码，但是基于美国的地点通常省略国家编码）。在顶级域下面是次级域（whitehouse.gov、microsoft.com、inforamp.net 等诸如此类），然后是第 3级域，等等等等向下以此类推。
　　
　　如果你想在美国建立域名，那么你必须联系网络信息中心NIC。在它同意你的请求以前，你首先要保证你想要的名字还没被使用，其次要保证目前至少有 2台服务器可以提供新域名的服务。当 NIC 最后同意请求时，它将承认你的次级域，并将指向该名字的指针放到顶级域所在的服务器内。例如，如果你请求域名mybiz.com，那么你必须首先让Internet上的2 台名字服务器提供信息服务（你的 ISP的服务器能做到这一点），然后NIC 将把 mybiz 放到COM 域服务器系统内，其指针将指向那2台特定服务器。
　　
　　一旦设置了适当的主域，你就可以增加所希望的任何数量的子域。你可能想要命名你的计算机为sales.mybiz.com，而另一台则被叫做techsupport.mybiz.com等等。这些工作可就不需要 NIC 的同意了，而且，事实上NIC也不管这事。但是，如果你想要任何人都能实际地访问你的子域，那么你最好将有关子域的信息尽快地放到上级域内。在特定的情况下，关于sales.mybiz.com 和 techsupport.mybiz.com 的IP信息必须放在mybiz.com服务器上。这一层次中的每台服务器都包含了一个DNS数据库，其入口被称作NS记录，每条这样的记录包含了域或子域的名字，此外还加上作为域或者子域服务器的主机的名字。在我们的例子中，我们将告诉根服务器它能在我们的 DNS 服务器上找到mybiz.com及其全部子域的信息，而这些信息则位于details.mybiz.com这台计算机上。
　　
　　现在我们来看看这一切是如何运作的。某所大学的某人在指向你的最新子域的网页上看见了一个链接 techsupport.mybiz.com。然后她点击该链接，于是她的本地DNS 服务器（很可能位于这所大学的某台计算机上）开始工作。首先，服务器搜索它自己的 DNS数据库以转换信息，但是，因为它以前从来没遇见过 techsupport.mybiz.com，所以服务器没有该域存在的记录而且不能解析IP地址。不过，它的 DNS 数据库包含了一个根服务器的地址（所有的 DNS 服务器必须设置该索引）。于是本地 DNS 服务器就到Internet上查询该根服务器。根服务器在其DNS 数据库里查找COM 顶级域，然后它用NS 记录回复该大学的 DNS 服务器，告诉它可以从details.mybiz.com 处查询到mybiz.com 的信息。大学的服务器就这样做了，而且从 details.mybiz.com那里知道了techsupport.mybiz.com 的对应IP 地址。在这一过程中最根本的阶段是，大学的DNS 服务器缓冲了该 NS 记录，结果下次该大学的任何人在需要涉及到mybiz.com、details.mybiz.com 、ortechsupport.mybiz.com等对应的IP地址转换时，相关信息在本地即可获得。
　　
　　正如其他的Internet协议一样，DNS由几个Internet的RFC（请求评论）规范（最初是RFC 882、883和973）。不过要理解DNS 服务器的工作原理最好的标准还是RFC 1035。你可以在Internet上的好几个地方找到RFC 1035，比如在http://www.crynwr.com/crynwr/rfc1035/ 就有一个不错的HTML 版本。正如你可能想到的那样，RFC具有相当的技术性，你不大可能会对超出DNS 服务器一般操作的细节感兴趣。但是如果你想做个服务器管理员，那么就记住 RFC吧。