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

我有一个奇怪的主意-让多个人/组织托管同一个应用程序，并允许通过一个域名访问所有节点。举例来说，这是为了拥有一个真正分布式的社交网络，而不会牺牲可用性（例如，用户不必记住不同的提供程序URL，然后当一个提供程序出现故障时，切换到另一个）

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

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

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

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

在本实验中，我使用了在Server 2012 R2上运行的Microsoft DNS服务器。由于在Active Directory中托管DNS区域的复杂性，我创建了一个新的名为test.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
        }
    }
}

我继续创建该名称的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或ping时，它将自动发出两个查询-一个UDP和一个TCP。如您所知，我最多可以塞入UDP数据报中的是512个字节，因此一旦超过该限制（例如20-30个IP地址），则必须改用TCP。但是即使使用TCP，我也只能获得一小部分A记录用于testing.testing.com。每个TCP查询返回1000条记录。A记录的列表在每个后续查询中都会正确旋转1，就像您希望轮询DNS正常工作一样。要遍历所有这些查询，将需要数百万次查询。

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

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

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

• 如果您使用自动清理并允许对DNS区域进行未经验证或匿名的更新，以期使A记录的列表保持新鲜……请想象这将是多么不安全！即使您设计了一些系统，在这些系统中客户端需要客户事先从您那里获得的客户端TLS证书才能更新区域，但地球上任何一个受感染的客户端都将启动僵尸网络并破坏您的服务。传统的DNS本身就存在不稳定的风险，而无需众包。

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

• DNS轮询无法替代适当的负载平衡。它无法从发生故障或在中间发生故障的一个节点中恢复。如果用户连接的节点出现故障，您是否要指示用户执行ipconfig / flushdns？GSLB和Anycast之类的问题已经解决了这类问题。

• 等等。

要回答所陈述的问题（“一个DNS A记录可以容纳多少个IP？”），答案很简单：单个A记录恰好包含一个地址。但是A，同一个名称可以有多个记录。

每个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个超时。

您所描述的并不是一个特别新颖的想法。正如其他答案已经涵盖的那样，您在一个答复中可以拥有多少条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有多少台边缘服务器为任何特定资源提供服务？我敢打赌两个以上。

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

简短的答案：UDP数据包中包含约25条记录。除此之外，DNS将切换到TCP，而且速度不会如此之快。对于未使用能够选择“最近” IP的DNS解析器的客户端，您还将遇到问题。另外，对于wifi和移动设备，“最近”通常不是正确的服务器。

更长的答案：

不要那样做 更好的方法是为指向适当服务器的每个用户设置单独的CNAME记录。比方说，你有两台服务器，server-f并server-r使用IMAP。将每个人的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记录。否则，您将陷入混乱和许多混乱。

我已经在拥有数千名用户的公司中看到了这一点，并且由于事情是自动化的，因此它的世界非常好。

正如其他人指出的那样，在现实世界中使用它是一个可怕的想法。

在现实世界中，有一些不一致的客户端和解析器，它们对不能容纳在单个UDP数据报中的响应有麻烦，并且有防火墙将强制实施有关DNS消息大小限制的特定但不符合协议的想法。

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

关于这个问题的历史琐事有趣的一点。在90年代，AOL扩展了DNS记录，以便MX查询返回> 512字节。这违反了RFC，破坏了许多SMTP服务器（qmail在当时很受欢迎），并引起系统管理员很多头疼。该修补程序需要打补丁或添加静态路由。

我不知道当前的情况如何，但是几年前，当我最后一次碰到qmail时，补丁仍然存在。

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