为什么NS记录不包含IP地址？

NS记录的目的是告诉客户端哪个域名服务器将确定域名的实际IP地址。因此，例如，以下查询告诉您，如果要获得有关facebook.com您的权威性答案，必须询问a.ns.facebook.com：

> dig ns facebook.com                                                                                                                                       19:58:27

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> ns facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32063
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;facebook.com.          IN  NS

;; ANSWER SECTION:
facebook.com.       65000   IN  NS  a.ns.facebook.com.
facebook.com.       65000   IN  NS  b.ns.facebook.com.

;; Query time: 13 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sun Mar 20 19:58:40 CET 2016
;; MSG SIZE  rcvd: 65

这看起来很酷而且有用，但是我想知道为什么该ANSWER部分包含主机名而不是权威源的IP？客户端获取权威来源的实际IP地址而不是主机名会更容易吗？

我的意思是，如果获得主机名，则必须再次进行查询以将该主机名解析为IP，然后向该新IP询问有关facebook.com其正在寻找的初始域的信息。这不是效率低下吗？

我很想回答这个问题，这使我指向解释该问题的RFC中的某些段落。

解决该问题的方法是DNS粘合记录，这在什么是粘合记录中有描述？。

RFC 1035第3.3.11节规定

“……请注意，该类可能不表示应与主机进行通信的协议族，尽管它通常是一个很强的暗示。”

返回IP地址将等同于说明可与主机联系的方法，这与RFC背道而驰。

Jason提供了可解决您所描述问题的DNS机制，但我们仍未了解为何以这种方式进行操作。

假设我拥有example.com并已将我的某些网站内容外包给一家名为Contoso的内容交付公司。他们的平台要求我们委派sub.example.com给他们的名称服务器，以便他们可以控制返回的响应。

; SOA and MX omitted from this example
$ORIGIN example.com.

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to Contoso's nameservers
sub         IN      NS            ns1.cdn.contoso.com.
sub         IN      NS            ns2.cdn.contoso.com.

; this is ours, not Contoso's
www         IN      A             198.51.100.1

正如您所指出的，我们尚未指定Contoso的名称服务器的IP地址。我们服务器所知道的只是告诉互联网“我们不管理sub.example.com，而是问Contoso”。这非常重要，因为：

• 我们没有Contoso.com。
• 我们不能期望Contoso与他们的所有客户协调其名称服务器IP的更改。如果我们的服务器提供了这些IP，那正是发生的情况。

到目前为止，一切都很好。一年过去了，Contoso对我们不为人知，它正在更改其CDN域名服务器的IP地址。由于DNS以其工作方式运行，因此他们要做的就是更新A返回的记录ns1.cdn和ns2.cdn.contoso.com.。

这给我们带来了一个重要的观点：Jason描述的粘合记录的存在是为了处理DNS中的“鸡和蛋”场景，例如google.com告诉世界其名称服务器是ns1.google.com和ns2.google.com。除非存在解决以下问题的基础，否则绝不应该创建指向您不拥有的基础结构的粘合记录：

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to ns1 and ns2.sub.example.com
sub         IN      NS            ns1.sub
sub         IN      NS            ns2.sub

; provide the IP addresses of ns1 and ns2 so that nameservers
; on the internet can find them.
;
; these IP addresses are owned by Contoso, not us, and they must
; coordinate changes to these IPs with us
ns1.sub     IN       A            203.0.113.10
ns1.sub     IN       A            203.1.113.10

这避免了鸡与蛋的情况，但也使Contoso必须与我们协调这些名称服务器的每个IP更改。这是非常容易发生风险的并且是不希望的。