☰

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

tag-icon • tag-icon domain-name-system
为什么 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 中解释此问题的段落的答案很感兴趣。

答案1

这个问题的解决方案是 DNS 粘合记录，具体描述如下什么是胶水记录？。

RFC 1035 第 3.3.11 节状态

“...请注意，该类别可能不会指示应该用于与主机通信的协议系列，尽管这通常是一个强烈的暗示。”

返回 IP 地址相当于说明联系主机的方法，这违反了 RFC。

答案2

Jason 提供了可以解决您所描述的问题的 DNS 机制，但我们还没有查看为什么事情就是这样做的。

假设我拥有example.com，并且我将部分网站内容外包给了一家名为康托索。他们的平台要求我们委托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 更改与我们共享这些名称服务器。这非常容易带来风险，并且是不可取的。

相关内容