my-manageable-zone.com

my-manageable-zone.com

my-manageable-zone.com

假设您有一个 DNS 服务器,其公共 IP 地址为205.251.197.174,并且您计划将其作为 的权威区域my-manageable-zone.com。基本上,在准备将 DNS 服务器变为名称服务器时,您有两种选择:

  • 自托管:您可以在同一区域下创建 A 记录子域名;或者
  • 外包:您可以从其他区域创建 A 记录子域

自托管

我的 DNS 服务器内的记录集

记录 记录类型 价值
ns-1.my-manageable-zone.com. A 205.251.197.174
my-manageable-zone.com. 国家标准 ns-1.my-manageable-zone.com.

外包

在其他 DNS 服务器内设置的记录

记录 记录类型 价值
ns-1.some-other-zone.com. A 205.251.197.174

我的 DNS 服务器内的记录集

记录 记录类型 价值
my-manageable-zone.com. 国家标准 ns-1.some-other-zone.com.

真实世界

我在网上查找了人们关于名称服务器的做法。基本上,我在命令行中尝试了类似以下操作:

dig +short NS google.com
dig +short NS nsa.gov
dig +short NS cloudflare.com
dig +short NS mit.edu

结果

google.com 国家安全局网站 cloudflare.com 麻省理工学院
ns2.google.com. a11-66.akam.net. ns3.cloudflare.com. use5.akam.net.
ns1.google.com. a24-65.akam.net. ns4.cloudflare.com. use2.akam.net.
ns3.google.com. a1-107.akam.net. ns5.cloudflare.com. asia2.akam.net.
... ... ... ...

在现实世界中,自托管和外包实际上是一个健康的结合。实施自托管或外包时要注意什么?

更新

我承认我错了。我所说的“自托管”实际上是指辖区内每当我说“外包”的时候,实际上意味着管辖范围外

答案1

实施自托管或外包时要注意什么?

如果您认真对待自己的域名,则不应依赖任何单个 DNS 提供商,而应选择 2 个。您不能随意选择它们并希望它们能够正常工作,这需要两者之间进行充分协调,但完全支持 DNSSEC 也是可能的。

无论你选择哪个 DNS 提供商,总有一天你会遇到问题。如果你的域名(以及域名上的服务)真的很重要,你应该使用多个 DNS 提供商。

您没有使用正确的术语来描述您的描述。欢迎您阅读有关 DNS 术语的 RFC 8499。您会发现您描述的是辖区内的名称服务器(ns.example.com是的名称服务器example.com)或完全外部的名称服务器。

您似乎更关心命名,或至少我是这么理解您的问题的,而不是真正提供服务的地方,因为这几乎是正交的:无论您的名称服务器是否在管辖范围内,从技术上讲,它们都可以在您的控制和维护之下。

在任何情况下,你都不会找到任何一条唯一的建议,两者都有优势。不过,我强烈建议不要选择“辖区内”的情况,除非你完全理解 DNS 及其工作原理,特别是当它与注册平面相交时,因为对于辖区内名称服务器,你需要通过域名注册商在注册处维护粘合,不幸的是,这往往是一个痛点。

如果您使用外部名称服务器,关于命名(还有其他注意事项:它们不应托管在同一个数据中心,不应全部位于同一个 AS 后面 - 除非使用任播 - 或同一个 IP 块等),您应该确保名称服务器使用多个注册表中的名称(因此,如果您采用com并且net两个 TLD 都在同一个注册表中,则不仅有多个 TLD)。

所有大型的 DNS 提供商都会向其客户提供该选项,并且最重要的是,不同区域或不同客户端的名称服务器集可能有所不同,以实现更好的隔离并可能提供不同级别的服务。

此外,一旦您这样做,您就会创建一种传递依赖关系。您的域的安全级别与用于命名您域名的域名服务器的域名的安全级别相关。

例如,如果您想执行 DNSSEC,那么在您的区域中这样做是可以的,但是如果您区域的权威名称服务器本身位于未启用 DNSSEC 的区域,则会降低您区域的实际安全性。

答案2

通过支付订阅费,外包应提供冗余并降低采购和维护 DNS 服务器的间接成本。我没有亲自与他们打过交道,所以我不能代表提供这些服务的公司发言,但如果您需要更新记录,您可以按照他们的时间完成更新。通过拥有自己的服务,您可以完全控制构建子域并在您选择时将其上线。这更多的是一个谁拥有域的 SOA 和初始响应的问题。我有一个,他们汇总了我们的 SOA 和关键外部记录,这很好,直到我们必须升级我们的 Exchange 服务器。此时,我们被搁置在一个停止点,直到他们更新域的 MX 记录。所以实际上您可以选择其中任何一个,只是如果您外包,您必须在进行面向公众的服务器的升级和更换或添加新的面向公众的功能时进行相应的计划。成本和资源更重要吗?或者您对不断变化的环境的响应速度?

相关内容