☰

隱藏大师

tag-icon • tag-icon networking domain-name-system dns-zone
隱藏大师

我想了解 NS 记录和 SOA 记录之间的区别。因为 NS 记录应该存储主要权威名称服务器和次要权威名称服务器作为数据备份。并且根据 DNS 的 RFC，SOA 在 MNAME 中存储“作为此区域的原始或主要数据源的名称服务器”。为什么 SOA 记录有时与 NS 记录不同？示例：

htw-berlin.de.          460     IN      SOA     infoblox1.htw-berlin.de. net-rz.htw-berlin.de. 2009142669 10800 3600 2419200 900
htw-berlin.de.          20965   IN      NS      infobloxv.htw-berlin.de.
htw-berlin.de.          20965   IN      NS      dns-2.dfn.de.

在这种情况下：infoblox1.htw-berlin.de.!=infobloxv.htw-berlin.de.

答案1

这维基百科 SOA文章暗示了原因，但要明确一点：MNAME 指定区域的主名称服务器。

那可并且经常是公共权威名称服务器之一，也可以在 NS 记录和/或 WHOIS 记录中找到，但它也可以命名不同的 DNS 服务器。这种配置通常称为 隐藏大师。

隱藏大师

隐藏主服务器是未公布且不出现在任何NS记录中的名称服务器。换句话说，它未在互联网上公开指定为您的域的名称服务器，也不会回答来自互联网的任何查询。隐藏主服务器的目的是向一组“辅助”名称服务器提供区域传输，这些服务器是公开作为您所在领域的权威机构并回答查询。

它被认为具有一些操作和安全优势：通常“隐藏主服务器”受防火墙保护，访问受到限制，或者隐藏主服务器是您内部网络的一部分。域管理员将在那里管理 DNS 记录。隐藏主服务器的重新加载和重新启动不会影响您域的解析。而且您的 DNSSEC 私钥将得到更好的保护。

另一些人认为这样的设置有些令人困惑，而且违反了互联网标准。

https://www.inetdaemon.com/tutorials/internet/dns/configuration/hidden_​​master.shtml

（在这种情况下，我可以假设一个组织使用 Infoblox 设备/解决方案作为其内部 DNS，而不是直接使用其他设备来管理其公共 DNS，而是使用相同的内部设备管理其互联网域和公共 DNS 记录。
或者他们有一个更复杂的解决方案，如下所示：https://docs.infoblox.com/space/BloxOneDDI/290685979/BloxOne+DDI+as+the+Hidden+Primary+Master ）

答案2

NS 记录是名称服务器，即保存 DNS 区域的服务器

SOA 是授权的开始，当 DNS 区域刷新、更新并在连接到互联网时复制到世界上所有其他 DNS 服务器时，SOA 记录具有配置

例如 google.com 的 SOA 是

google.com.     10 IN SOA ns1.google.com. dns-admin.google.com. (
                595350753  ; serial
                900        ; refresh (15 minutes)
                900        ; retry (15 minutes)
                1800       ; expire (30 minutes)
                60         ; minimum (1 minute)
                )

因此，当 Google 更新 DNS 记录时，DNS 服务器需要 15 分钟的时间才能将其传达给全球 DNS 基础设施

对于 htw berlin 来说

htw-berlin.de.      21600 IN SOA infoblox1.htw-berlin.de. net-rz.htw-berlin.de. (
                2009142669 ; serial
                10800      ; refresh (3 hours)
                3600       ; retry (1 hour)
                2419200    ; expire (4 weeks)
                900        ; minimum (15 minutes)
                )

名称不同可能是 CNAME 或某些 DNS 代理

这是一个奇怪的问题，我不知道它为什么不同

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.15 <<>> ANY +additional +multiline +trace +dnssec net-rz.htw-berlin.de. @8.8.4.4
;; global options: +cmd
.           29241 IN NS a.root-servers.net.
.           29241 IN NS b.root-servers.net.
.           29241 IN NS c.root-servers.net.
.           29241 IN NS d.root-servers.net.
.           29241 IN NS e.root-servers.net.
.           29241 IN NS f.root-servers.net.
.           29241 IN NS g.root-servers.net.
.           29241 IN NS h.root-servers.net.
.           29241 IN NS i.root-servers.net.
.           29241 IN NS j.root-servers.net.
.           29241 IN NS k.root-servers.net.
.           29241 IN NS l.root-servers.net.
.           29241 IN NS m.root-servers.net.
.           29241 IN RRSIG NS 8 0 518400 (
                20240117050000 20240104040000 30903 .
                NG0lAPqTSOmSW02oV6+f62WF6tTlnlVozhdRPo40JBED
                0AViqQL348xXq5gTWrejUE0Dp0x0Pp8H5/NZMCVeYtyB
                BUxcmwLRs7IhltMNQjkOXH2yDYyXi+bup7KMSthEHDiV
                dE3e2B58mFHEumemZxPfnKOEMrpAdnb15LvFZkfqSE4L
                d4CzpXXWO/fAWtD3NnmPlAc9LX7+woKsPquK40CLQQg3
                sY9/wcoIa3Z3VTr32o9R4iBFZD5eAhCBl3gPabR7KQF1
                XR9Fnu9l0kREXt5gu8SN/a26KuhTb51bN9xiqivTJnZZ
                3YIQEts/aJehRbDDzpMh5U+eAEje8KRjYw== )
;; Received 525 bytes from 8.8.4.4#53(8.8.4.4) in 1 ms

de.         172800 IN NS a.nic.de.
de.         172800 IN NS f.nic.de.
de.         172800 IN NS l.de.net.
de.         172800 IN NS n.de.net.
de.         172800 IN NS s.de.net.
de.         172800 IN NS z.nic.de.
de.         86400 IN DS 26755 8 2 (
                F341357809A5954311CCB82ADE114C6C1D724A75C039
                5137AA3978035425E78D )
de.         86400 IN RRSIG DS 8 1 86400 (
                20240117220000 20240104210000 30903 .
                F/NZZ0AGqQkdyU9NZbFi9Gsc/zZL+XIj37gRCr7DVxsW
                d3hhXNCHKFwo9Z99StbcDKnlxAWUEdCWZnJ/pPaaV6ku
                AMScJDFMjZxq+KVscpn4iqd+70V9s+awrAWcCyJpQeKF
                xPEG3v+eCDQ1Nu4FX/yyvpwSOW6fXWSTdTIoS0gcEStY
                FiMZoAjWaMCi9e6Y4FIgUpM+s+a3G5g9QwKxKWrovknR
                pOuaCYZftu1fijC3eb5A/x1cUz9VkonQyKt9Abs4Vjrt
                pqZ8vwsD6H91dcqJQSP8gd9L3tqgb6H3Xynvf60iAMjL
                IihPFZuXuw5m0ATdY0GZ/5SQLRz4rm43YA== )
;; Received 754 bytes from 192.203.230.10#53(e.root-servers.net) in 3 ms

htw-berlin.de.      86400 IN NS infobloxv.htw-berlin.de.
htw-berlin.de.      86400 IN NS dns-2.dfn.de.
tjlb7qbojvmlf1s6gdriru7vsms1lg16.de. 7200 IN NSEC3 1 1 15 CA12B74ADB90591A (
                TJLF6JN42VL7A95RC3U0K1AOGLKQJ53O
                NS SOA RRSIG DNSKEY NSEC3PARAM )
tjlb7qbojvmlf1s6gdriru7vsms1lg16.de. 7200 IN RRSIG NSEC3 8 2 7200 (
                20240117032622 20240103015622 11943 de.
                tw3xisSs186MI0yplC9n5lXR+it6Rb48064JuklcJI7v
                GYLrHB8ZHCLhyvlJ2LDVoCs92Jc/bMedoU000WnAPrNQ
                9nd3e7YGBuXPFbENlmOznjsbZcJTK9SJTOKsc3r8IMD/
                8ll8QjauHfILb1SAgEVdEBNgpJYY6tBU7STVZCo= )
vkljdt8c5h3gkigc5hnc82m0ppf0n5to.de. 7200 IN NSEC3 1 1 15 CA12B74ADB90591A (
                VKLNAHSBEO2AUU8FLR4GF2OQ9I9R8GHH
                A RRSIG )
vkljdt8c5h3gkigc5hnc82m0ppf0n5to.de. 7200 IN RRSIG NSEC3 8 2 7200 (
                20240116055819 20240102042819 11943 de.
                mmaUzsIJTVG+p/P21jw/ZEGmt7o9bmhgxQDGSG3pg6FH
                /39hIDFnSpXQvRWDU3vXRZ7CEy0MUcmehkdoYDzOnMnz
                42srAdHUxENbbSpAFO2A7Y0zZpExBE8jaCVBt/sUuXZv
                TgiYmA0t69kZgyR6Atk9OQmc1H9gMcUww+pgUHE= )
;; Received 616 bytes from 194.0.0.53#53(a.nic.de) in 33 ms

;; Connection to 2001:638:d:b102::1#53(2001:638:d:b102::1) for net-rz.htw-berlin.de. failed: network unreachable.
htw-berlin.de.      900 IN SOA infoblox1.htw-berlin.de. net-rz.htw-berlin.de. (
                2009142669 ; serial
                10800      ; refresh (3 hours)
                3600       ; retry (1 hour)
                2419200    ; expire (4 weeks)
                900        ; minimum (15 minutes)
                )
;; Received 95 bytes from 193.174.75.54#53(dns-2.dfn.de) in 102 ms

答案3

我想说 SOA 记录的所有字段都用于指示在哪里以及如何更新应该做出。

  • SOA 的第二个字段（RNAME）是“主机管理员”的电子邮件地址 - 即负责更新的人员（最初，“主机管理员”是负责维护 ARPANET HOSTS.TXT 表的人员的职位）。

  • 因此，SOA 的第一个字段（MNAME）应该表示在哪里人们需要登录才能对区域文件进行编辑，因为传统的基于 AXFR 的区域复制意味着只有一个名称服务器实际上是“可写的”（所有其他名称服务器都是只读副本）。

  • 几乎所有剩余的 SOA 字段也只是为了处理基于 AXFR 的复制 — — MINTTL 是唯一的例外。

（可能值得注意的是，在早期，在全球分布式任播 DNS 托管广泛普及之前，并不少见让其他机构代您托管辅助名称服务器，以便在您自己的网络/AS 发生故障时提供冗余……如果您的网络很小，让其他机构也成为您的主名称服务器可能也并不罕见。因此，如果您让 Foo 大学托管您的主 DNS，让 Foobar 机构托管副本，则 SOA 字段将帮助您记住在需要进行更新时联系谁。）

正如其他答案所说，SOA 中列出的“主”服务器从 NS 中省略是相对正常的；它很可能是一个“隐藏的主服务器”，仅用作复制源，不直接提供实时数据。实际上，此字段纯粹是信息性的，复制实际上也不会使用它（源服务器是手动配置的）。

随着后来动态 DNS 更新 (DNS UPDATE) 的添加，SOA MNAME 字段实际上用于指示所有动态更新必须发送到哪个服务器。例如，如果您使用，nsupdate您会发现它并不关心 NS，但始终将更新发送到 SOA 中列出的任何名称服务器。

（例如，即使在 Active Directory 中，尽管 AD 区域通常托管在 AD DC 上，并且由于 AD 的多主复制，所有这些 DC 都是可写的，但 Windows 仍然使用域的 SOA 字段来确定单个服务器，以便发送动态更新。）

最后需要注意的是，在基于推送的 AXFR（DNS NOTIFY）被广泛实施之前，传统的复制是按计划进行的（即还通过 SOA 记录定义）——每隔 X 分钟，副本服务器就会从其源服务器（通常是“主”服务器，尽管可能存在多个层级）刷新一次。因此，即使复制计划是“每 6 小时”，也可以依赖 SOA MNAME 中列出的服务器来获取最新数据（例如，如果想要检查更新是否生效）。

答案4

我的理解要简单得多……SOA 是 Start Of Authority，即被视为对域具有权威性的名称服务器。NS 是名称服务器记录，即您要求提供该信息的机器。对于大多数人来说，SOA 可以（通常是）是名称服务器之一；但像 Google 这样的大型组织通常会使用不同的机器来保存其区域文件，而 NS 机器只是定期查询 SOA 机器以确保它们都在同一页面上。

我不知道这背后的逻辑，但我认为对于像 Google 这样负载很重的系统，当其他名称服务器需要请求更新时，不要让 SOA 主机被 NS 请求淹没是有意义的。如果 SOA 机器设置为不接受来自任何外部源的更新，这也可能是强化区域文件的一种方法。

相关内容