可悲的是，这里的答案是“取决于”。 它所依赖的因素将随域名，拥有服务器的设置以及您自己的本地DNS设置而变化。
首先，例如，关于返回的NSlogging：完全允许将这些logging的返回顺序随机化，因此每次请求它时，顺序可能会有所不同。 另一方面，这不是由所有的DNS实现，所以你可能会得到一个静态的有序列表。 关键是你不能确定。
接下来，一些DNS实现将并行查询每个NS，并使用哪一个先回复。 其他人将击中每一个，确定最快的一些请求数量，并使用这一个。 或者它可以循环。
DNS有多个RFC，我发现其中两个更有用：
http://www.faqs.org/rfcs/rfc1912.html
http://www.faqs.org/rfcs/rfc1033.html
我意识到这是一个没有答案的东西，没有任何明确的你拿走，但鉴于上述情况，唯一真正的方法，你必须确定一个给定的领域的行为是testing。
我在客户端看到的最普遍的实现，比如全球的ISP，如下所示：
- 有人（如宽带用户）要求ISP的DNS服务器parsingfoo.example.com的Alogging。
- ISP检查自己的caching，如果该logging被caching，仍然被认为是“新鲜的”，则立即通过caching返回。 （ 这就是所有DNScaching的工作方式，这样它们就不会不必要地压缩相关站点的DNS服务器。 ）
- 如果他们没有caching该logging，或者caching被认为是“陈旧/过时”，则ISP知道它需要再次parsing最新的logging。
- 现在ISP需要知道什么名字服务器来查询最新的logging。
- ISP首先检查域的授权域名服务器的caching列表（这些域名是ns1.example.com，ns2.example.com等等）。 如果这些logging仍被认为是新鲜的，则跳到步骤8。
- 如果caching的名称服务器logging被认为已过期，或者该域名没有任何cachinglogging，则ISP将查询TLD的根名称服务器（如.comregistry，如果它是.com域）以获取example.com的最新的名称服务器名称/ IP对。 （ 您可以通过“dig @ b.gtld-servers.net example.com”自己尝试一下，看看您的TLD的根名称服务器知道您的域名 – 如果您的域名属于通常的com / net / etc顶级域名。 TLD必须查询各自的根服务器。 ）
- TLD的根名称服务器始终按照您指定的顺序返回名称服务器; 没有随机化进行。 他们还返回每个名称服务器的IP地址; 这就是所谓的“胶着”，它是什么让互联网解决如何解决一个域名服务器主机名到IP之前知道任何关于一个域的“鸡和蛋”的问题。 而且，他们中的大多数（比如最大的com / net / etc注册机构）使用了2天的caching时间，这样他们就不会不断地用“域X的域名服务器名单是什么？ 要求。 这是常识的来源，你必须等待2天，直到你可以安全地说你的新名字服务器在你编辑你的名字服务器列表之后在世界范围内是已知的。
- 当ISP知道example.com的名称服务器及其IP（如ns1.example.com，ns2.example.com，ns3.example.com）时，ISP现在从该列表中select一个随机服务器并发送查询。 （ 这是很好的，他们并不是不必要地锤击有问题的网站的所有DNS服务器，他们通过并不总是查询列出的第一个名称服务器进一步协助负载平衡。 ）
- 如果ISP在指定的超时期限内没有得到该名称服务器的响应，则会查询列表中的另一个。
- 当它有回应时，ISP现在将其存储在自己的本地caching中。 至于多久将保持caching; 由任何DNS服务器返回的每个logging还具有与其关联的“软过期”时间（以秒为单位），这是查询客户端（诸如ISP的DNS服务器）被允许在被认为是“仍然可用，但可能过时，现在应该发生一个新的查询，如果可能只是为了确保它没有改变。 在每个单独的域名服务器的“SOA”（授权开始）logging中还有一个“硬到期”的时间（你可以通过“dig @ ns1.example.com example.com -t soa”看到你的）为该服务器返回的所有logging指定一个全局“硬限制”，之后任何caching都应该删除它的cachinglogging，即使名称服务器closures，也不可能再次查找logging。 软期限通常在30分钟到5小时之间，硬期限通常在1-3周之间。
- 在完成这个详尽的工作之后，ISP终于拥有了最新的DNSlogging，并且可以将其返回给查询的宽带用户，而这个用户并不是这个幕后发生的巨大工作。
每个logging查找都会重复此过程。 但是，只有第一个查询才能完成整个工作。 名称服务器IP将被caching，随后对ISP的高速cachingDNS服务器的查询将快速跳转到步骤8。
现在，对于步骤8的随机化，它在logging级别上工作。 假设该ISP的宽带用户询问了以下logging：
每条logging将作为独立的“实体”进行处理，独立caching和查找。 所以，假设用户和ISP从来没有遇到过这个域，并且都有完全为零的cachinglogging。 查找可能如下所示：
- 通过ns1.example.com的foo.example.com，然后存储在ISPcaching中
- 通过ns3.example.com访问example.com，然后存储在ISPcaching中
- 通过ns2.example.com访问www.example.com，然后存储在ISPcaching中
- MX example.com通过ns3.example.com，然后存储在ISPcaching中
每当caching的logging软过期时，这个过程就会重复进行，所以你甚至不知道后面的logging请求会再次使用同一个服务器。
因此，确保所有 DNS服务器完全同步，绝对是最重要的目标，它可以完美地映射每台服务器上的每个 DNSlogging。 你永远不知道DNS客户端将会打哪个服务器，你不能依赖任何命令。 哪有这回事。
此外，正如Adam C所提到的，服务器级别（example.com）的DNS服务器本身可以返回NSlogging并随机化这些logging的顺序。 常规的DNS服务器非常常见的是随机化他们的NSlogging，因为糟糕的DNS实现总是select第一个返回的namserver。 但是，ROOT TLD域名服务器（前面提到过）永远不会随机化这个列表，而他们的列表在解决域名问题时是非常重要的。 这就是为什么大多数实现从名称服务器列表中select一个随机的服务器，以避免总是碰到同一个服务器并重载它。
好吧，这是你如何工作和你应该记住的DNS的入门。
- 简而言之：把所有的DNS服务器当作只是一台服务器，把它作为你生活中的最高目标，确保它们同样能够回答任何可能引起的查询。
免责声明：生活中比pipe理DNS更高的目标可能是可用的，但单独出售，使用你的想象力。 😉