主页 / server / 问题 / 1002788
Accepted
Gacek
Asked: 2020-02-13 06:03:22 +0800 CST

域可以没有分配IP地址（A记录）并且可以存在子域吗？

  • 772

我有一个在子域上运行的专用服务器。我想将子域配置为 DNS。基本上，我使用 example.com 作为我的主要公司域。我会，可能有不止一台专用服务器，并希望它们成为s1，s2等等。

我通过 NS 条目重定向server.example.com到另一个 DNS 提供商
server.example.com NS ns1.hostingcompany.example.com
server.example.com NS ns2.hostingcompany.example.com

我在那里设置了以下条目：

servers.example.com     NS  ns1.hostingcompany.example.com.
servers.example.com     NS  ns2.hostingcompany.example.com.

s1.servers.example.com  NS  ns1s1.servers.example.com.
s1.servers.example.com  NS  ns2s1.servers.example.com.
ns1s1.servers.example.com   A   192.0.2.1
ns2s1.servers.example.com   A   192.0.2.2
s1.servers.example.com  A   192.0.2.1

但是，servers.example.com没有A记录。我跳过了它，因为我只想将它用作分组DNS 条目。

一切似乎都正常，除了我在公司的本地绑定服务器。它不识别s1.servers.example.com任何子域。当我切换到谷歌 DNS 时，它似乎工作正常。

问题是，如果这个设置是正确的并且会起作用吗？

注意：也许我不明白 NS 条目是如何工作的，据我所知，当域条目中存在 NS 服务器时，指向其他 DNS 服务器时，它被认为是“不要问我，问另一个服务器”并且 A 记录不是在这个链条中需要。

domain-name-system dns-hosting

3 个回答

  1. 除非我严重错误，否则我在这里看到两个问题。

    第一个是微不足道的。在您发布问题几个小时后，我正在写这个答案。这意味着新的 DNS 配置可能尚未传播到整个 DNS 系统。根据域配置中的各种 TTL 条目，这可能需要一天时间。此过程中的一个典型阶段是一些 DNS 服务器已经提供新信息，而另一些则提供旧信息。

    第二个是你的配置。我不明白为什么您有以下条目：

    s1.servers.example.com  NS  ns1s1.servers.example.com.
s1.servers.example.com  NS  ns2s1.servers.example.com.
ns1s1.servers.example.com   A   192.0.2.1
ns2s1.servers.example.com   A   192.0.2.2

    据我了解您的问题，s1.servers.example.com不是子域，而只是主机。但是您将其视为子域，因为您明确地将其委托给名称服务器。这是非常不寻常的，您可能应该离开那四行。基本结构应该是这样的：

    • 告诉世界哪些名称服务器负责/权威地解析名称servers.example.com空间中的所有名称。您已经通过在代码框中发布的前两行完成了此操作。

    • 然后只需将所有主机的条目（A 记录）添加到这些名称服务器的配置中。除非这些名称服务器相互复制，否则您应该将各自的条目添加到它们中。s1您已经在第二个代码框中发布的最后一行完成了此操作。

    应该没有什么可做的了。就个人而言，我会为自己添加一个额外的条目servers.example.com，也许只是将其指向s1.servers.example.com，因为经验表明人们会尝试使用该主机名并且如果无法解析它会担心。

    • 1
  2. Best Answer

    记录通常不是强制性的，但最好有它至少在子域的情况下提示如何到达它（你需要知道处理example.com的ns1.sub.example.com在哪里- 你知道什么是第一个鸡或蛋吗？/如果你还不知道 example.com，你不能要求 ns1.sub.example.com :-)）。

    必须有 SOA ( Start Of zone A uthority )记录，并且至少有 NS (Name Server) 记录是很常见的。从技术上讲，与其他子域相关的委派需要 NS，因为该区域的“重要”NS 记录位于上层区域（如果您要求 NS，您最终会直接在该区域上询问，但要达到它，您正在使用 NS从上部区域）。

    想象一下，假设这种结构（example.com、example.net 和 192.0.2.0/24 用于文档目的，其余部分在 DNS 系统中是真实的 - 当然简化为众多记录之一......）：

    . (e.g. a.root-servers.net. - 198.41.0.4 ):
  . IN SOA ...
  . IN NS a.root-servers.net.
  a.root-servers.net. IN A 198.41.0.4 ( <= this is HINT - how to reach it)
  ...
  com. IN NS a.gtld-servers.net.
  a.gtld-servers.net. IN A 192.5.6.30  ( <= this is HINT - how to reach it)
  a.gtld-servers.net. IN AAAA 2001:503:a83e::2:30 ( <= this is HINT - how to reach it)
  ...

com. (e.g. a.gtld-servers.net. - 192.5.6.30 ) :
  com. IN SOA ...
  com. IN NS a.gtld-servers.net.
  ...
  example.com. IN NS ns1.example.com.
  ns1.example.com. IN A 192.0.2.10  ( <= this is HINT)
  ...

example.com ( ns1.example.com. - 192.0.2.10 ) :
 example.com. IN SOA ...
 example.com. IN NS ns1.example.com.
 ns1.example.com. IN A 192.0.2.10
 ...
 www.example.com. IN A 192.0.2.20
 sub.example.com. IN NS ns1.sub.example.com.
 ns1.sub.example.com. IN A 192.0.2.30 ( <= HINT to where to find NS server)
 ...
 sub2.example.com. IN NS ns1.example.net. ( no HINT needed as it point out to other zone)
 ...

    在此示例中，直接在区域和上部区域中的 NS 委托（例如 example.com）有一致的信息。

     example.com. IN NS ns1.example.com.
 ns1.example.com. IN A 192.0.2.10

    如果它会有所不同，这不是问题，但是对于寻找权威服务器，将使用来自上层区域（com.）的服务器，但在常规递归的情况下，将直接返回来自区域的记录......所以除了可以显示技术上使用的内容。如果您将区域迁移到其他 DNS 服务器，这可能是一个问题 - 直到以前的 DNS 服务器启动之前一切正常并且看起来不错，但是一旦关闭电源，区域就无法访问......

    “上层”区域通过注册商（通常是一些 Web 表单）维护，但该区域（您的区域）直接维护在您指向 NS 记录的任何位置（注册商服务器、第三方服务器或您自己的 DNS 服务器）。

    要查看上部区域中的记录，您可以使用此命令（在 example.com so com. 的 DNS 服务器的情况下）：

    dig +norec NS example.com @a.gtld-servers.net.

    要获取区域 example.com 的内容，您可以使用（例如询问公共 google DNS 服务器）：

    dig NS example.com @8.8.8.8

    如果委派在一般情况下工作但不是在本地工作，我猜你已经为 example.com 本地定义了 DNS 区域（例如，获取内部 IP 而不是公共 IP），所以即使你已经为子域进行了 NS 委派，你的本地 DNS 区域实例example.com 对此一无所知 - 您还需要在此处添加它。

    在它旁边，您不需要为每个子域提供额外的 NS 委托。如果您不需要额外的子域 DNS 服务器，即使“主”DNS 服务器也可以处理它。

    这是 example.com 的区域的有效内容

    example.com IN SOA ...
example.com. IN NS ns1.example.com.
ns1.example.com. IN A 192.0.2.10
...
www.example.com. IN A 192.0.2.20
s1.servers.example.com. IN A 192.0.2.30
s2.servers.example.com. IN A 192.0.2.40
s3.servers.example.com. IN A 192.0.2.50
...

    如果您需要委派，只需服务器“级别”就足够了：

    example.com :
 example.com IN SOA ...
 example.com. IN NS ns1.example.com.
 ns1.example.com. IN A 192.0.2.10
 ...
 www.example.com. IN A 192.0.2.20
 servers.example.com. IN NS ns1.servers.example.com.
 ns1.servers.example.com. IN A 192.0.2.15
 ...

servers.example.com ( ns1.servers.example.com. - 192.0.2.15 ) :
 servers.example.com. IN SOA ...
 servers.example.com. IN NS ns1.servers.example.com.
 ns1.servers.example.com. IN A 192.0.2.15
 ...
 s1.servers.example.com. IN A 192.0.2.30
 s2.servers.example.com. IN A 192.0.2.40
 s3.servers.example.com. IN A 192.0.2.50
 ...

    因此，如果您不需要直接在 s1.servers.example.com 上用于某些特殊目的的额外 DNS 服务器，则问题中的这条记录实际上并不需要：

    s1.servers.example.com  NS  ns1s1.servers.example.com.
    • 1

  3. 您的配置是正确的，除了：

    s1.servers.example.com  A   192.0.2.1

    由于您将域委派s1.servers.example.com给其他名称服务器，因此定义此条目是他们的工作。一个例外构成了必须在父区域中的粘合记录。您可以使用它们为委派的名称服务器提供更合理的名称：

    s1.servers.example.com  NS  ns1.s1.servers.example.com.
s1.servers.example.com  NS  ns2.s1.servers.example.com.
ns1.s1.servers.example.com   A   192.0.2.1
ns2.s1.servers.example.com   A   192.0.2.2
    • 1

相关问题