这个问题最初是在这里问的： 为什么DNS区域文件需要NSlogging？
总结一下：“当我去注册商并购买example.com时，我会告诉我的注册商，我的域名服务器是ns1.example.org和ns2.example.org”。
但请有人澄清以下内容：
注册后，.comregistry现在会有一个logging，告诉parsing器需要访问ns1.example.org或ns2.example.org以查找example.com的IP地址。 IP地址位于ns1.example.org上的区域文件中的Alogging中，并在ns2.example.org上具有相同的副本。
但是，在这个文件中，还必须有2个NSlogging，其中列出了ns1.example.org和ns2.example.org作为名称服务器。 但由于我们已经在这些服务器之一，这似乎是重复的信息。
原来给这个问题的答案说，区域文件中列出的域名服务器是“权威的”。 如果名称服务器不匹配，那么授权的名称服务器将优先。 这一切都很好，但parsing器使用.comregistry中列出的名称服务器到达名称服务器，如果名称服务器不匹配，则parsing器将在错误的名称服务器上查找区域文件，能够find它。
或者是.comregistry从区域文件nslogging中提取名称服务器信息的情况？ （但是，我想如果你更改nslogging的区域文件， 而不告诉registry，那么它将无法知道在哪里看。）
谢谢
让我们稍微分解一下。
TLD区域中的NSlogging（例如example.com NS ... in com ）是委托logging。
TLD区域中的A和AAAAlogging（例如， ns1.example.com A ... in com ）是胶水logging。
区域本身的NSlogging（即example.com NS ... ）是权限logging。
区域本身的A和AAAAlogging（ example.com ns1.example.com A ... ）是简单和简单的地址logging。
当（recursion）parsing器启动时，没有caching区域的数据，只有根区域caching（用于引导名称parsing过程），它将首先进入. 然后com. 。 com服务器将回应一个权威部分的回应 ，基本上说：“我不知道，但在这里找一个知道的人”，与服务器相同. 做关于com 。 此查询响应不具有权威性，并且不包含填充答案部分。 它也可能包含一个所谓的附加部分，它给出了特定服务器知道的任何主机名的地址映射（或者来自粘合logging，或者在recursionparsing器的情况下，来自先前的caching数据）。 parsing器将采取此授权响应，必要时parsingNSlogging的主机名，并继续查询授权给哪个DNS服务器。 如果您拥有深层次的委托层次，此过程可能会重复执行多次，但最终会导致使用“权威答案”标志设置的查询响应。
需要注意的一点是，parsing器（通常希望）不会试图分解主机名来解决问题，而只是将其全部发送到它所知道的“最好的”服务器上。 由于Internet上的平均权威名称服务器对绝大多数有效的DNS名称是非权威的，因此响应将是指向其他某个DNS服务器的非权威性委托响应。
现在，服务器不必在委托中被命名，或者权威机构logging任何区域的权威性。 考虑一下私人主服务器的情况; 在这种情况下，存在一个权威的DNS服务器，只有该区域的从属DNS服务器的pipe理员才知道。 如果DNS服务器通过某种机制认为它对所涉及的区域具有全面和准确的了解，那么DNS服务器对于该区域是权威的。 例如，如果在SOAlogging中定义为到期时间的时间限制内无法访问configuration的主服务器，则正常授权的DNS服务器可能会变为非权威性的。
只有权威的答案应被视为正确的查询答复; 其他的一切都是代表团，或者是某种错误。 对非权威服务器的委派被称为“跛脚”委派，并且意味着parsing器必须回溯一步并尝试其他一些指定的DNS服务器。 如果代理中不存在权威的可访问名称服务器，则名称parsing失败（否则，它将比正常情况慢）。
这是非常重要的，因为非权威数据不能被caching 。 怎么可能，因为非权威的服务器没有完整的画面？ 所以权威的服务器必须自己能够回答“谁应该是权威的，为了什么？”的问题。 这是区内NSlogging提供的信息。
有很多边缘情况下，这实际上可以造成严重的不同，主要集中在单个区域内的多个主机名称标签（可能相当常见，例如，对于大dynamicIP范围，反向DNS区域）或名称服务器列表父母区和问题区（这很可能是一个错误，但也可以有意地完成）。
你可以用dig和它的+norec （不要求recursion）和@服务器说明符特性来看看它是如何工作的。 接下来是实际parsingDNS服务器如何工作的说明。 查询从unix.stackexchange.com开始的a.root-servers.net的Alogging：
$ dig unix.stackexchange.com. A @a.root-servers.net. +norec
仔细查看flags以及每节计数。 qr是查询响应， aa是权威答案。 注意你只能委托给com服务器。 手动跟随该委派（实际上，recursionparsing器将使用附加部分的IP地址（如果提供的话），或者如果在委托响应中没有提供IP，则启动一个命名名称服务器的单独名称parsing，但是跳过这一部分，并简单回溯到操作系统的正常parsing器）：
$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec
现在你看到， ns1.serverfault.com被委托给（其他人） ns1.serverfault.com ，你还没有得到一个权威的答案。 再次跟随代表团：
$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;unix.stackexchange.com. IN A ;; ANSWER SECTION: unix.stackexchange.com. 300 IN A 198.252.206.16
答对了！ 我们得到了答案，因为aa标志已经设置好了，恰好包含了我们希望find的IP地址。 顺便说一下，值得注意的是，至less在写这篇文章的时候，委托和列出的机构名称服务器列表是不同的，表明两者不需要相同。 上面我所举例说明的基本上是任何parsing器所做的工作，除非任何实际的parsing器也会caching响应，所以它不必每次都打到根服务器。
从上面的示例中可以看出，委托和粘贴logging的用途与区域本身的权限和地址logging不同。
caching，parsing名称服务器通常也会对返回的数据进行一些健全性检查，以防止caching中毒。 例如，它可能会拒绝caching命名com的权威服务器的答案，而不是由父区域命名为com删除命令的源。 细节取决于服务器，但意图是尽可能caching，而不打开谷仓门，允许互联网上的随机名称服务器覆盖任何非官方的“pipe辖权”的代表团logging。
.comregistry是“胶水logging”，它将您的域名服务器的位置作为IP地址。 parsing器无法知道您的DNS服务器的“身份”，因此它使用NSlogging来确保号码匹配。
DNS请求 – > .comregistry（ip是xxxx） – > DNS（NS xxxx）匹配，parsing。
如果他们不匹配或存在，那么这是一个非权威的答案。