☰

DNS 中的“Glue”记录是否仅由同一域的名称服务器使用？

tag-icon • tag-icon domain-name-system
DNS 中的“Glue”记录是否仅由同一域的名称服务器使用？

我有点困惑“胶水记录“用于DNS。

这文件说

如果您使用的是其他人的名称服务器（例如您的 ISP 的名称服务器），则无需担心粘合记录。只有在配置存在循环引用的自己的名称服务器时，才需要担心粘合记录。

因此，Glue记录只会出现在其具有权威性的域内的名称服务器中。例如，如果 example.com 的名称服务器为 ns1.example.com，则需要它们，如果它在另一个域上，则不需要它们。

基于这文档我使用dig命令查看域名服务器托管在另一个域中的域是否存在胶水记录。令人惊讶的是，它们也有胶水记录！我试图查看它们是否novanext.com有胶水记录，因为它们的域名服务器位于不同的域中。

更新

$ dig ns com.
;; ANSWER SECTION:
com.            85916   IN  NS  j.gtld-servers.net.
com.            85916   IN  NS  f.gtld-servers.net.
com.            85916   IN  NS  i.gtld-servers.net.
com.            85916   IN  NS  g.gtld-servers.net.
....

接下来获取novanext.com域的“粘合”记录。

$ dig ns novanext.com @g.gtld-servers.net.

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ns novanext.com @g.gtld-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55040
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 6
;; WARNING: recursion requested but not available

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

;; AUTHORITY SECTION:
novanext.com.       172800  IN  NS  ns2.net4india.com.
novanext.com.       172800  IN  NS  ns1.net4india.com.

;; ADDITIONAL SECTION:
ns2.net4india.com.  172800  IN  A   202.71.131.12
ns2.net4india.com.  172800  IN  A   202.71.131.13
ns2.net4india.com.  172800  IN  A   202.71.131.241
ns1.net4india.com.  172800  IN  A   202.71.128.222
ns1.net4india.com.  172800  IN  A   202.71.128.37
ns1.net4india.com.  172800  IN  A   202.71.129.33

;; Query time: 279 msec

这怎么可能？我在 Google 上搜索了很多，但还是没能找到答案。任何帮助我都会很感激。

答案1

因此，Glue 记录仅存在于其具有权威性的域内的名称服务器中。例如，如果 example.com 的名称服务器为 ns1.example.com，则需要它们，如果它位于另一个域中，则不需要它们。

遗憾的是，这是一个错误的结论。没有什么可以阻止你提供并非绝对必要的粘合记录。假设我为 运营名称服务器example.com，并且我想委托sub.example.com给ns1.contoso.com。

定义委托很简单：

sub.example.com. IN NS ns1.contoso.com.

这本身就足够了，但我还可以为其定义一个粘合记录：

ns1.contoso.com. IN A 203.0.113.1

这会导致我的域名服务器被纳入作为胶水203.0.113.1的引荐ns1.contoso.com。我的域名服务器不是负责任的对于 contoso.com，互联网上没有正常的名称服务器会将该粘合记录存储在缓存中。

他们将要假设我希望203.0.113.1查询ns1.contoso.com当前不在缓存中。这很好……直到 contoso.com 的管理员更改了的 IP 地址ns1.contoso.com。我的胶水会出错，在许多情况下，这种推荐会中断。

答案2

您应该小心不要将粘合记录与附加部分记录混淆。虽然粘合记录确实放在附加部分中，但并非所有附加记录都是粘合记录。

在示例中novanext.com，您会看到ns1和的附加记录ns2.net4india.com。发生这种情况是因为 .com 区域恰好有这些名称服务器的 A 记录，但严格来说，这不是胶水。它包含在附加部分中作为优化，以节省第二次查找。

请注意，胶水数据不被视为权威数据。如果您尝试查询 .com 名称服务器以获取胶水记录，您将得到一个引荐，并且您不会在答案部分获得胶水记录。这就是上述评论中的情况。有一个主机/胶水记录，misserendipity.com但您无法通过直接查询来查看它，因为您获得的是引荐。可能这个主机/胶水记录不再是严格必要的，但由于它在那里，因此它包含在引用它的引荐中。dns.technorail.comdns.technorail.com

.com 和 .net 并不总是这样运作的。在使用 DNSSEC 签名之前，有必要改变它们的行为。这NANOG 帖子 解释了这一变化。

答案3

如果您向根域名服务器询问NS的记录airbnb.in，它不会知道。这不是根域名服务器的工作。根域名服务器只会将您转至注册中心的域名服务器.in。

$  dig +trace +additional -t ns airbnb.in

; <<>> DiG 9.7.3 <<>> +trace +additional -t ns airbnb.in
;; global options: +cmd
.           489327  IN  NS  g.root-servers.net.
.           489327  IN  NS  b.root-servers.net.
.           489327  IN  NS  m.root-servers.net.
.           489327  IN  NS  c.root-servers.net.
.           489327  IN  NS  d.root-servers.net.
.           489327  IN  NS  l.root-servers.net.
.           489327  IN  NS  h.root-servers.net.
.           489327  IN  NS  f.root-servers.net.
.           489327  IN  NS  k.root-servers.net.
.           489327  IN  NS  i.root-servers.net.
.           489327  IN  NS  e.root-servers.net.
.           489327  IN  NS  a.root-servers.net.
.           489327  IN  NS  j.root-servers.net.
a.root-servers.net. 30831   IN  A   198.41.0.4
a.root-servers.net. 30831   IN  AAAA    2001:503:ba3e::2:30
b.root-servers.net. 30831   IN  A   192.228.79.201
b.root-servers.net. 30831   IN  AAAA    2001:500:84::b
c.root-servers.net. 30831   IN  A   192.33.4.12
c.root-servers.net. 30831   IN  AAAA    2001:500:2::c
d.root-servers.net. 30831   IN  A   199.7.91.13
d.root-servers.net. 30831   IN  AAAA    2001:500:2d::d
e.root-servers.net. 30831   IN  A   192.203.230.10
f.root-servers.net. 30831   IN  A   192.5.5.241
f.root-servers.net. 30831   IN  AAAA    2001:500:2f::f
g.root-servers.net. 30831   IN  A   192.112.36.4
h.root-servers.net. 30831   IN  A   128.63.2.53
;; Received 496 bytes from 10.20.206.2#53(10.20.206.2) in 38 ms

in.         172800  IN  NS  a2.in.afilias-nst.info.
in.         172800  IN  NS  b1.in.afilias-nst.in.
in.         172800  IN  NS  ns7.cdns.net.
in.         172800  IN  NS  a0.in.afilias-nst.info.
in.         172800  IN  NS  a1.in.afilias-nst.in.
in.         172800  IN  NS  c0.in.afilias-nst.info.
in.         172800  IN  NS  b2.in.afilias-nst.org.
in.         172800  IN  NS  b0.in.afilias-nst.org.
a0.in.afilias-nst.info. 172800  IN  A   199.7.87.1
a1.in.afilias-nst.in.   172800  IN  A   115.249.164.142
a2.in.afilias-nst.info. 172800  IN  A   199.249.117.1
b0.in.afilias-nst.org.  172800  IN  A   199.253.56.1
b1.in.afilias-nst.in.   172800  IN  A   125.19.40.90
b2.in.afilias-nst.org.  172800  IN  A   199.249.125.1
c0.in.afilias-nst.info. 172800  IN  A   199.253.57.1
ns7.cdns.net.       172800  IN  A   194.0.1.7
a0.in.afilias-nst.info. 172800  IN  AAAA    2001:500:29::1
a1.in.afilias-nst.in.   172800  IN  AAAA    2001:4528:fff:13::142
a2.in.afilias-nst.info. 172800  IN  AAAA    2001:500:45::1
b0.in.afilias-nst.org.  172800  IN  AAAA    2001:500:50::1
b1.in.afilias-nst.in.   172800  IN  AAAA    2404:a800:2:1e::19:90
;; Received 492 bytes from 192.228.79.201#53(b.root-servers.net) in 32 ms

airbnb.in.      86400   IN  NS  ns4.markmonitor.com.
airbnb.in.      86400   IN  NS  ns7.markmonitor.com.
airbnb.in.      86400   IN  NS  ns5.markmonitor.com.
airbnb.in.      86400   IN  NS  ns3.markmonitor.com.
airbnb.in.      86400   IN  NS  ns2.markmonitor.com.
airbnb.in.      86400   IN  NS  ns1.markmonitor.com.
airbnb.in.      86400   IN  NS  ns6.markmonitor.com.
;; Received 168 bytes from 199.253.57.1#53(c0.in.afilias-nst.info) in 70 ms

airbnb.in.      86400   IN  NS  ns2.markmonitor.com.
airbnb.in.      86400   IN  NS  ns7.markmonitor.com.
airbnb.in.      86400   IN  NS  ns5.markmonitor.com.
airbnb.in.      86400   IN  NS  ns1.markmonitor.com.
airbnb.in.      86400   IN  NS  ns3.markmonitor.com.
airbnb.in.      86400   IN  NS  ns6.markmonitor.com.
airbnb.in.      86400   IN  NS  ns4.markmonitor.com.
;; Received 168 bytes from 64.124.69.50#53(ns1.markmonitor.com) in 35 ms

请注意，如果您尝试使用a1.in.afilias-nst.in或b1.in.afilias-nst.in作为 TLD 的名称服务器.in，您将需要使用胶水记录。否则，就会出现先有鸡还是先有蛋的问题。根名称服务器使用胶水记录来响应其他名称服务器（例如 ns7.cdns.net = 194.0.1.7）作为性能优化，尽管它们不是必需的。

该airbnb.in域名不需要粘合记录，因为其名称服务器都在 中.com。

答案4

对于较新的回答方式，请查看有关 DNS 术语的官方文档，即RFC 8499。

它定义粘合记录如下：

Glue records:  "...[Resource records] which are not part of the
  authoritative data [of the zone], and are address RRs for the
  [name] servers [in subzones].  These RRs are only necessary if the
  name server's name is 'below' the cut, and are only used as part
  of a referral response."  Without glue "we could be faced with the
  situation where the NS RRs tell us that in order to learn a name
  server's address, we should contact the server using the address
  we wish to learn."  (Quoted from [RFC1034], Section 4.2.1)

  A later definition is that glue "includes any record in a zone
  file that is not properly part of that zone, including nameserver
  records of delegated sub-zones (NS records), address records that
  accompany those NS records (A, AAAA, etc), and any other stray
  data that might appear."  (Quoted from [RFC2181], Section 5.4.1)

相关内容