DNS Alogging可以有多lessIP？

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

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

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

我开始创build名为testing.testing.com. 65025主机logging，没有错误testing.testing.com. 字面上每个IPv4地址从1.1.1.1到1.1.255.255。

然后，我想确保能够毫无错误地突破65536（2 ^ 16位）的Alogging总数，所以我可以假设我可能已经一路走到了16581375（1.1.1.1到1.255 .255.255），但我不想坐在这里看这个脚本整夜运行。

所以我认为可以肯定地说，对于服务器上不同IP地址的同一名称，可以添加到区域中的Alogging的数量没有实际的限制。

但是，从客户的angular度来看，这实际上会起作用吗？

以下是我从Wireshark查看的客户端获得的信息：

（以全尺寸在新的浏览器标签中打开图像。）

正如你所看到的，当我从客户端使用nslookup或ping时，它会自动发出两个查询 – 一个UDP和一个TCP。 正如你已经知道的，我能够塞进一个UDP数据报的最多的是512字节，所以一旦超过这个限制（如20-30个IP地址），就必须使用TCP代替。 但即使使用TCP，我也只能得到testing.testing.com的一个非常小的Alogging子集。 每个TCP查询返回1000条logging。 Alogging的列表随着每个连续的查询而正确地旋转1，正如您期望循环法DNS工作的方式一样。 这将需要数百万的查询来循环所有这些。

我不明白这将如何帮助您制作大规模的可扩展的，有弹性的社交媒体networking，但是您的答案仍然存在。

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

• 假设我是普通的互联网用户，我想连接到您的服务。 我在我的网页浏览器中inputwww.bozho.biz。 我的电脑上的DNS客户端取回1000条logging。 好吧，运气不好，列表中的前30条logging是不响应的，因为Alogging的列表不能保持最新，或者是大规模的中断，影响了大量的互联网。 假设我的networking浏览器在每次IP移动之前都有5秒的超时时间，并尝试下一次。 所以现在我坐在这里盯着旋转沙漏等待你的网站加载2分半钟。 没有人为此付出时间。 我只是假设我的networking浏览器或任何我用来访问您的服务的应用程序甚至会尝试超过前4或5个IP地址。 它可能不会。

• 如果你使用自动清理，并允许未经validation或匿名更新的DNS区域，希望保持Alogging清单新鲜…只要想象会有多么不安全！ 即使你devise了一些客户端需要客户端TLS证书的系统，以便更新这个区域，一个在这个星球上任何地方受到威胁的客户端都会启动一个僵尸networking并破坏你的服务。 传统的DNS是不稳定的，因为它没有人群来源。

• 带宽占用率高，浪费大。 如果每个DNS查询需要32千字节或更多的带宽，那么根本就不能很好地扩展。

• DNS循环不能替代正确的负载平衡。 它没有办法从一个节点中断或恢复。 你是否要指导你的用户做一个ipconfig / flushdns，如果他们连接的节点出现故障？ 这类问题已经被GSLB和Anycast等解决。

• 等等。

为了回答这个问题（“单个DNS Alogging有多lessIP”？），答案很简单：一个Alogging只包含一个地址。 然而，可以有多个相同名称的Alogging。

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

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

如果您同时拥有25个IPv4地址和14个IPv6地址，则您将指望在单独查询中请求IPv4和IPv6地址的客户端。 如果客户在单个查询中询问这两种types的地址（这很less见），那么您就必须降低。

如果应答大小超过了512字节，如果客户端和服务器支持EDNS，它仍然可以通过UDP工作。 没有EDNS，客户端会收到一个截断的答复，它将不得不通过TCP重试。 这增加了通信从1到4往返。 但更糟糕的是，有时会出现configuration错误，导致TCP上的DNS无法正常工作。

即使你可以挤压多于14个地址，而不会在DNS层造成问题，这也不太可能是非常有用的。 在放弃一个地址并继续下一个地址之前，客户使用的超时时间通常很重要。

不得不一次等待这个超时会导致糟糕的用户体验。 如果客户在得到响应之前必须经过14个地址，则用户将不得不等待13个超时。

你所描述的不是一个特别新的想法。 正如其他答案已经涵盖的，你在一个答复中可以有多less个Alogging是有限的，但是没有提到总共有多less个Alogging。

例如，你可以实现一个DNS服务器，该服务器用一个随机IP来回答对Alogging的查询。 查询足够的次数，这将导致4294967296唯一的Alogging：每个IPv4地址一个。

正如我所说，这不是一个新的想法。 实际上， Akamai的工作方式 （可能还有很多其他的CDN）也是如此。 您获得的任何Akamai域名的Alogging是由他们的黑魔法DNS服务器决定的。 我敢打赌，你得到的答案取决于dynamic负载平衡和地理问题。

例如，我选了一个338.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有多less个边缘服务器为特定资源提供服务？ 我敢打赌，不止两个。

其他人已经提到它作为一个细节，但从实际的angular度来看，硬限制是512字节的UDP数据包大小限制。 虽然在检测到截断的情况下可以切换到TCP，但实际上很多/大多数客户端不会这样做（并且可以说他们不应该这样做;这会给大多数应用程序带来不好的用户体验，而且我只希望区域传输或其他专用查找来支持TCP）。 所以，你正在寻找约三十个IPv4（Alogging）地址的限制，而IPv6（AAAA）则更less一些。 域名的长度会削减到这个数字，并会进一步限制这个数字。

正如其他人所指出的，现实世界的使用是一个可怕的想法。

在现实世界中，存在不合格的客户端和parsing器，这些客户端和parsing器在一个UDP数据报不能适应的情况下遇到问题，而且有防火墙会强制实现特定的但不符合协议的关于DNS消息大小限制的想法。

即使你可以指望你在每种情况下都能获得巨大的回应（你无法做到），还有另外一个原因，那就是非常糟糕的想法。 您的DNS响应规模越大，reflection攻击的有效载荷就越有吸引力，因为您提供了巨大的放大因子。 在这种在DNS中常见的拒绝服务攻击中，将UDP查询发送到打开的recursionparsing器。 UDP查询的源地址通常很容易被欺骗，攻击者将查询源设置为其预定目标的IP。 对攻击者来说，有两个可取的效果：首先，他们的一个相对较小的发送努力（来自一个小的欺骗性查询）导致相当大的到达目标的不希望的stream量的洪stream（这是放大因子），其次 – 攻击的实际来源对目标是隐藏的; 目标只知道用作reflection器的recursionparsing器的地址。

有关这个问题的历史琐事的有趣点。 在90年代，AOL扩展了他们的DNSlogging，以便MX查询返回大于512字节。 这违反了RFC，打破了很多SMTP服务器（qmail当时很受欢迎），并导致系统pipe理员很头疼。 该修复程序需要修补或添加静态路由。

我不知道目前情况如何，但几年前，当我最后一次碰到qmail的时候，补丁还是到位的。

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

简短的回答：约25个logging适合UDP数据包。 除此之外，DNS将切换到TCP，它不会那么快。 您还会遇到客户端没有使用能够select“最近”IP的DNSparsing器的问题。 另外，有了wifi和移动设备，“最近的”往往不会是合适的服务器。

较长的答案：

不要这样做。 更好的方法是为每个指向相应服务器的用户设置单独的CNAMElogging。 假设您有两台服务器， server-f和server-r用于IMAP。 使用服务器名称USERNAME.imap.example.comconfiguration每个人的IMAP客户端，其中“USERNAME”由其电子邮件用户名replace。 现在，您可以在服务器之间移动人员，而无需重新configuration电子邮件客户端。

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.

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

我已经看到，这些公司在成千上万的用户中完成，而且由于事情是自动化的，所以这个世界非常好。