Boz*_*zho 34 domain-name-system ipv4
我有一个奇怪的想法——让多个人/组织托管同一个应用程序,并让他们的所有节点都可以通过一个域名访问。这是为了拥有一个真正分布式的社交网络,其中不牺牲可用性(即用户不必记住不同的提供商网址,然后当一个提供商出现故障时,切换到另一个提供商)
为此,我认为可以使用具有多个 IP 的 DNS 记录。
那么,单个 DNS A 记录可以保存多少个 IP?这个答案说它大约是 30,但那里的用例不同。对于上述情况,我不在乎给定的 ISP 是否只缓存 30 个,只要另一个 ISP 缓存另外 30 个,依此类推。
Rya*_*ies 84
免责声明:无意冒犯,但这是一个非常糟糕的主意。我不建议任何人在现实生活中这样做。
但是如果你给一个无聊的 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
}
}
}
Run Code Online (Sandbox Code Playgroud)
我继续为 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 或 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 记录的列表没有保持最新,或者可能有大规模中断影响了互联网的一部分。假设我的 Web 浏览器在继续尝试下一个 IP 之前每个 IP 有 5 秒的超时时间。所以现在我坐在这里盯着旋转的沙漏 2 分半钟等待您的网站加载。是不是没有人有时间这样做。我只是假设我的网络浏览器或我用来访问您的服务的任何应用程序甚至会尝试比前 4 或 5 个 IP 地址更多的地址。它可能不会。
如果您使用自动清理并允许对 DNS 区域进行未经验证或匿名的更新,以期保持 A 记录列表的新鲜...想象一下这将是多么不安全!即使您设计了一些系统,其中客户端需要事先从您那里获得客户端 TLS 证书才能更新区域,但地球上任何地方的一个受感染客户端也会启动僵尸网络并破坏您的服务。如果没有众包,传统的 DNS 就非常不安全。
大量的带宽使用和浪费。如果每个 DNS 查询都需要 32 KB 或更多的带宽,那将根本无法很好地扩展。
DNS 循环不能替代适当的负载平衡。它无法从一个节点出现故障或在中间变得不可用中恢复。如果他们连接的节点出现故障,您是否会指示您的用户执行 ipconfig/flushdns?诸如 GSLB 和 Anycast 之类的东西已经解决了这类问题。
等等。
kas*_*erd 10
每个 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
Run Code Online (Sandbox Code Playgroud)
如果我问 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
Run Code Online (Sandbox Code Playgroud)
我敢打赌,如果你尝试一下,我敢打赌你会得到不同的答案。Akamai 有多少个边缘服务器为任何特定资源提供服务?我敢打赌,不止两个。
归档时间: |
|
查看次数: |
23538 次 |
最近记录: |