主页 / server / 问题 / 652237
Accepted
Bozho
Asked: 2014-12-13 13:47:25 +0800 CST

DNS A 记录可以拥有的最大 IP 数是多少？

  • 772

我有一个奇怪的想法——让多个人/组织托管同一个应用程序，并让他们的所有节点都可以通过一个域名访问。这是为了拥有一个真正分布式的社交网络，其中不牺牲可用性（即用户不必记住不同的提供者网址，然后当一个提供者出现故障时，切换到另一个提供者）

为此，我认为可以使用具有多个 IP 的 DNS 记录。

那么，一条 DNS A 记录可以保存多少个 IP？这个答案说它大约是 30，但那里的用例不同。对于上述情况，我不在乎给定的 ISP 是否只缓存 30 个，只要另一个 ISP 缓存另外 30 个，依此类推。

domain-name-system

9 个回答

  1. Best Answer

    免责声明：没有冒犯，但这是一个非常糟糕的主意。我不建议任何人在现实生活中这样做。

    但是如果你给一个无聊的 IT 人一个实验室，有趣的事情就会发生！

    在本实验中，我使用了在 Server 2012 R2 上运行的 Microsoft DNS 服务器。由于在 Active Directory 中托管 DNS 区域的复杂性，我创建了一个名为 testing.com 的新主要区域，它不是AD 集成的。

    使用此脚本：

    $Count = 1
for ($x = 1; $x -lt 256; $x++)
{
    for ($y = 1; $y -lt 256; $y++)
    {
        for ($z = 1; $z -lt 256; $z++)
        {
            Write-Host "1.$x.$y.$z`t( $Count )"
            $Count++
            dnscmd . /RecordAdd testing.com testing A 1.$x.$y.$z
        }
    }
}

    我继续为 name 创建 65025 个主机记录，没有错误，testing.testing.com.每个 IPv4 地址都从 1.1.1.1 到 1.1.255.255。

    然后，我想确保我可以无错误地突破 65536（2^16 位）的 A 记录总数，并且我可以，所以我假设我可能一直到 16581375（1.1.1.1 到 1.255 .255.255,) 但我不想坐在这里看这个脚本运行一整夜。

    记录太多

    因此，我认为可以肯定地说，对于您可以在服务器上为具有不同 IP 的同名区域添加的 A 记录的数量没有实际限制。

    但从客户的角度来看，它真的会起作用吗？

    以下是 Wireshark 从我的客户那里得到的信息：

    两个查询 （在新的浏览器选项卡中打开图像以获得完整大小。）

    nslookup

    TCP查询

    如您所见，当我从客户端使用 nslookup 或 ping 时，它会自动发出两个查询 - 一个 UDP 和一个 TCP。正如你已经知道的，我最多可以塞进一个 UDP 数据报是 512 字节，所以一旦超过这个限制（比如 20-30 个 IP 地址），就必须改用 TCP。但即使使用 TCP，我也只获得了 testing.testing.com 的 A 记录的一小部分。每个 TCP 查询返回 1000 条记录。A 记录列表随着每个连续查询正确旋转 1，就像您期望循环 DNS 的工作方式一样。循环遍历所有这些需要数百万次查询。

    我不知道这将如何帮助您建立可大规模扩展、有弹性的社交媒体网络，但您的答案仍然存在。

    编辑：在您的后续评论中，您问为什么我认为这通常是一个坏主意。

    • 假设我是一个普通的互联网用户，我想连接到您的服务。我在网络浏览器中输入 www.bozho.biz。我计算机上的 DNS 客户端返回 1000 条记录。好吧，运气不好，列表中的前 30 条记录没有响应，因为 A 记录的列表没有保持最新，或者可能是大规模中断影响了大部分 Internet。假设我的网络浏览器在继续尝试下一个之前，每个 IP 有 5 秒的超时时间。所以现在我坐在这里盯着一个旋转的沙漏 2 分半钟等待你的网站加载。是不是没有人有时间。我只是假设我的网络浏览器或我用来访问您的服务的任何应用程序甚至会尝试超过前 4 或 5 个 IP 地址。它可能不会。

    • 如果您使用自动清理并允许对 DNS 区域进行未经验证或匿名的更新，以期使 A 记录列表保持最新……想象一下那将是多么不安全！即使您设计了一些系统，其中客户端需要事先从您那里获得的客户端 TLS 证书来更新区域，地球上任何地方的受感染客户端都会启动僵尸网络并破坏您的服务。如果没有众包，传统 DNS 本身就非常不安全。

    • 巨大的带宽使用和浪费。如果每个 DNS 查询都需要 32 KB 或更多的带宽，那根本无法很好地扩展。

    • DNS 循环不能替代适当的负载平衡。它无法从一个节点宕机或在中间变得不可用中恢复。如果他们连接的节点出现故障，您是否会指示您的用户执行 ipconfig/flushdns？GSLB 和 Anycast 之类的东西已经解决了这类问题。

    • 等等。

    • 88

  2. 要回答前面提到的问题（“一条 DNS A 记录可以保存多少个 IP？”），答案很简单：一条A记录​​只保存一个地址。但是，同一名称可以有多个A记录。

    • 18

  3. 每个 IPv4 地址在回复中将占用 16 个字节。每个 IPv6 地址在回复中将占用 28 个字节。

    强烈建议您确保回复适合 512 字节。这将允许大约 25 个 IPv4 地址和 14 个 IPv6 地址（考虑到您还需要数据包中的一些其他信息）。确切的限制取决于您的域名长度。

    如果您同时拥有 25 个 IPv4 地址和 14 个 IPv6 地址，那么您指望客户端在单独的查询中请求 IPv4 和 IPv6 地址。如果客户在单个查询中要求两种类型的地址（这种情况很少见），那么您将不得不降低。

    如果回复大小超过 512 字节，如果客户端和服务器支持 EDNS，它仍然可以通过 UDP 工作。如果没有 EDNS，客户端将收到截断的回复，并且必须通过 TCP 重试。这将通信从 1 次增加到 4 次往返。但更糟糕的是，有时会出现配置错误，阻止基于 TCP 的 DNS 工作。

    即使您可以将超过 14 个地址压缩到回复中而不会导致 DNS 层出现问题，它也不太可能非常有用。客户端在放弃一个地址并继续下一个地址之前使用的超时通常很重要。

    甚至一次都必须等待超时会导致糟糕的用户体验。如果客户端必须经过 14 个地址才能获得响应，则用户将不得不等待 13 次超时。

    • 10

  4. 你所描述的并不是一个特别新的想法。正如其他答案已经涵盖的那样，您在一个回复中可以拥有多少 A 记录是有限的，但这并没有说明总共可能有多少 A 记录。

    例如，您可以实现一个 DNS 服务器，它使用随机 IP 回答对 A 记录的任何查询。查询足够多的时间，这将导致 4294967296 个唯一的 A 记录：每个 IPv4 地址一个。

    正如我所说，这不是一个新想法。事实上，这部分是 Akamai 的工作原理（可能还有很多其他 CDN）。您为任何 Akamai 域获得的 A 记录由他们的黑魔法 DNS 服务器确定。我敢打赌，您得到的答案取决于动态负载平衡和地理问题。

    例如，我选择了 a338.g.akamaitech.net。如果我现在在我的计算机上查看它，它使用 Comcast 分配的 DHCP 名称服务器：

    $ host a338.g.akamaitech.net
a338.g.akamaitech.net has address 23.3.98.65
a338.g.akamaitech.net has address 23.3.98.89

    如果我问 Google 的 DNS 怎么办？

    $ host a338.g.akamaitech.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

a338.g.akamaitech.net has address 23.3.96.152
a338.g.akamaitech.net has address 23.3.96.120

    我敢打赌，如果你尝试一下，我敢打赌你会得到不同的答案。Akamai 有多少台边缘服务器为任何特定资源提供服务？不止两个，我敢打赌。

    • 6

  5. 其他人已经提到它作为一个细节，但从实际的角度来看，硬限制是 512 字节的 UDP 数据包大小限制。虽然可以在检测到截断时切换到 TCP，但实际上许多/大多数客户端不会这样做（并且可以说他们不应该这样做；它会给大多数应用程序带来糟糕的用户体验，我只期望区域传输或其他支持 TCP 的专用查找）。因此，您正在查看 IPv4（A 记录）的大约 30 个地址的限制，而 IPv6（AAAA）的地址则要少一些，因为它们更大。域名的长度会减少这一点，并将进一步限制数量。

    • 2

  6. 简短的回答：大约 25 个 A 记录适合 UDP 数据包。除此之外，DNS 将切换到 TCP，而且速度不会那么快。对于不使用能够选择“最近”IP 的 DNS 解析器的客户端，您也会遇到问题。此外，对于 wifi 和移动设备，“最近”通常不会是正确的服务器。

    更长的答案：

    不要那样做。更好的方法是为指向相应服务器的每个用户设置单独的 CNAME 记录。假设您有两台服务器，server-f用于server-rIMAP。配置每个人的 IMAP 客户端，服务器名称为 USERNAME.imap.example.com，其中“USERNAME”替换为他们的电子邮件用户名。现在，您可以在服务器之间移动人员，而无需重新配置他们的电子邮件客户端。

    server-f.example.com. IN A 10.10.10.10 server-r.example.com. IN A 10.20.20.20 wilma.imap.example.com. IN CNAME server-f.example.com. fred.imap.example.com. IN CNAME server-f.example.com. betty.imap.example.com. IN CNAME server-r.example.com. barney.imap.example.com. IN CNAME server-r.example.com.

    但是，如果您这样做，我强烈建议您从用户数据库中自动生成 DNS 记录。您要确保在创建和删除帐户时也创建和删除 DNS 记录。否则你最终会陷入混乱和混乱。

    我在拥有数以千计用户的公司中看到了这种做法，而且由于事情是自动化的，它的世界非常好。

    • 1

  7. 为什么 512 字节作为 UDP 有效负载的幻数？

    如果您回到（接近）开头并查看 RFC-791，它是 IP 版本 4 的协议标准，您会发现此文本

    所有主机都必须准备好接受最多 576 个八位字节的数据报，无论它们是完整还是分段到达）。

    所以 20 个字节用于 TCP 标头，20 个字节用于 UDP 标头，剩下 536 个字节用于 DNS 响应。DNS 协议标头的 12 个字节留下 524 个字节。然后你需要为 QNAME 和其他东西留出一些空间，512 字节是一个不错的整数。

    在今天的 Internet 上，常见的 MTU 是 1500 字节，几乎每个使用 IPv4 的主机都可以支持这种大小的 IP 数据报。但这些协议早于以太网的广泛采用（至少是 IP、UDP），您所依赖的数字是 576 字节作为起点。

    EDNS 扩展机制允许与 DNS 服务器通信解析器准备接收的响应大小，因此通常会看到带有该选项的查询以反映 1500 字节的 MTU。理想情况下，您真的不想因为一堆原因而导致 IP 碎片，因此使用 UDP 传输的 DNS 响应的响应数据包大小相当保守。

    今天的历史课就这样结束了。

    • 1

  8. 正如其他人所指出的，这对于现实世界的使用来说是一个糟糕的主意。

    在现实世界中，存在不符合标准的客户端和解析器，它们无法处理无法容纳在单个 UDP 数据报中的响应，并且有防火墙将强制执行特定但不符合协议的有关 DNS 消息大小限制的想法。

    即使您可以指望在每种情况下都能获得巨大的响应（您绝对不能），但这是一个非常糟糕的主意还有另一个原因。您的 DNS 响应大小越大，它作为反射攻击的有效负载就越诱人，因为您提供了巨大的放大因子。在这种类型的拒绝服务攻击中，这在 DNS 中很常见，UDP 查询被发送到一个开放的递归解析器。UDP 查询的源地址通常很容易被欺骗，攻击者将查询源设置为其预期目标的 IP。实现了两个理想的（对攻击者而言）效果：首先——他们相对较小的发送工作（来自一个小的欺骗查询）导致相对较大的不受欢迎的流量洪流到达目标（这是放大因子），第二——攻击的实际来源对目标是隐藏的；目标只知道用作反射器的递归解析器的地址。

    • 0

  9. 关于这个主题的历史琐事的有趣点。在 90 年代，AOL 扩展了他们的 DNS 记录，使得 MX 查询将返回 >512 字节。这违反了 RFC，破坏了很多 SMTP 服务器（当时 qmail 是一种流行的服务器），并且给系统管理员带来了很多麻烦。该修复需要修补或添加静态路由。

    我不知道现在的情况如何，但是几年前，当我最后一次接触 qmail 时，补丁还在。

    http://www.gossamer-threads.com/lists/qmail/users/30503

    • 0

相关问题