了解 DNS 查找机制

Posted

技术标签:

【中文标题】了解 DNS 查找机制【英文标题】:Understanding the DNS lookup mechanism 【发布时间】:2012-08-06 21:50:11 【问题描述】:

导致我尝试取消选择此过程的具体查询是:

如果父域 example.com 已被解析,DNS 查找子域(例如 assets.example.com)会更快吗?

根据我的(天真)理解,将域名转换为 IP 地址的basic process 非常简单。十三个根服务器的地址,知道如何解析***域,如comnet,在网络硬件中硬编码。在查找example.com 的情况下,我们的本地DNS 服务器,可能是我们的路由器,询问这些根服务器之一在哪里可以找到com 的***名称服务器。然后它会询问生成的名称服务器是否知道如何解析example。如果是,我们就完成了,如果不是,我们将被传递到另一台服务器。此过程中的每个名称服务器都可能正在缓存,因此有一段时间我们的本地路由器现在将知道在哪里寻找comexample,而com 服务器将知道在哪里寻找example

不过,我真的不明白。

我知道还有其他中间 DNS 服务器,例如 ISP 提供的那些。他们在什么时候被询问? 如果com TLD 域名服务器不知道如何解析example,它如何确定要检查的其他域名服务器?或者这只是意味着example.com 无法解析? 当我注册一个域并配置名称服务器时,我是否实际上是在为该 TLD 的名称服务器使用的数据库中为我的特定 TLD 的子域编辑一组 NS 记录?

Wikipedia 解释说,一些 DNS 服务器将缓存与递归查询实现结合起来,这允许它们提供缓存命中并可靠地解决缓存未命中问题。我不明白这些服务器是如何被查询的,或者解析算法是如何工作的。

回顾我最初的问题,假设 A 记录都在同一个名称服务器上,我可能会选择“否”。这准确吗?

【问题讨论】:

【参考方案1】:

首先,误解:

根提示(13 台根服务器的名称和 IP 地址)几乎从未“硬编码在网络硬件中”。网络硬件(如路由器)有时可能有一个内置的 DNS 解析器,如果它碰巧也有一个 DHCP 服务器,但如果有,它通常只是一个转发解析器,将查询传递给上游名称服务器(从 ISP 获得) 如果它不知道答案。 ISP 提供的域名服务器通常不充当“中间 DNS 服务器”。您可以使用自己的名称服务器(例如公司名称服务器,或者您在计算机上安装了 BIND),也可以使用 ISP 提供的名称服务器。在任何一种情况下,您选择的任何名称服务器都会从头到尾处理递归解析过程。上述转发名称服务器除外。 如果com TLD 名称服务器不知道如何解析example,则无法确定要检查的其他名称服务器。 本身就是要检查的名称服务器。它要么知道example,要么知道example 不存在。

您的问题的答案是肯定的。如果名称服务器已经解析了example.com(并且该结果在其缓存中仍然有效),那么它将能够更快地解析assets.example.com

递归解析过程就像你描述的那样:首先找出.(根)的名称服务器,然后找出com的名称服务器,等等......只有递归解析器实际上并不询问对于 .comexample.com 的名称服务器。它实际上每次都要求assets.example.com。根服务器不会给它这个问题的答案(他们对assets.example.com 一无所知),但他们至少可以为com 提供对名称服务器的引用。同样,com 的名称服务器不会回答问题(他们也不知道),但他们可以提供对 example.com 的名称服务器的推荐。 example.com 的名称服务器可能知道也可能不知道问题的答案,具体取决于 assets.example.com 是进一步委托给其他名称服务器还是在与 example.com 相同的区域中提供。因此,递归解析器将收到最终答案或另一个推荐。

【讨论】:

所以性能优势源于客户端已经知道知道如何解析 example.com 的名称服务器,所以它可以直接去询问 assets.example.com?跨度>

以上是关于了解 DNS 查找机制的主要内容,如果未能解决你的问题,请参考以下文章

DNS 缓存机制原理

实验:DNS反向解析

DNS服务的配置与管理---配置正向查找区域

浏览器缓存机制

linux[基础]-33-[dns服务器]-[正反向域名解析]-[01]

android 怎么做数据缓存