RFC 1034要求我们为DNS服务器分配至less两个IP地址。 但是，如果我们使用选播地址，冗余可以通过一个IP地址来实现。 BGP选播似乎可以很好地扩展到数百甚至数千个服务器。
如果是这样，为什么我们仍然需要DNS服务器的多个IP地址？ 如果我们已经有了任播，它是否实际上增加了冗余（有助于可用性），还是只是一个神话？
如果我们只使用一个IP地址，那么我们可能会面对哪些问题和错误 ？
因此，我的意思是完全省略了辅助DNS地址，或者在某些设置至less需要两个地址时，使用伪造IP（例如1.2.3.4 ）作为第二个地址。
单个任播IP地址不会像两个不同IP前缀中的两个单播IP地址一样拥有相同的冗余。
通常最难解决的问题不是什么时候完全失败，而是不正确的行为只能够通过健康检查，但实际上并不起作用。
我已经看到一个DNS服务器closures的任播DNS设置，但数据包仍然会被路由到该DNS服务器。 无论是做广告的前缀可能根本不知道，DNS服务器已经closures。
如果所讨论的DNS服务器不是一个权威的DNS服务器，而是一个recursion的parsing器，则会变得更加棘手。
这种recursionparsing器需要同时具有用于接收来自客户端的查询的任播地址和用于查询授权的DNS服务器的单播地址。 但是，如果单播地址发生故障，它可能会看起来很健康，但仍然会被路由查询。
Anycast是扩展性和缩短延迟的好工具。 但是为了冗余，它不应该孤立。
多个冗余的选播池是可用性的一个很好的解决scheme。 一个众所周知的例子是8.8.8.8和8.8.4.4。 两者都是任播地址，但是决不能将它们路由到同一个物理DNS服务器（假设Google做的很好）。
如果您有10个物理DNS服务器，则可以将它们configuration为每个池中包含5个服务器的2个池或每个池中包含5个池的5个池。 您希望避免同时有一个物理DNS服务器在多个池中。
那么你应该分配多lessIP呢？ 您需要有可以独立configuration为任意播的IP。 这通常意味着您需要为每个池分配整个/ 24个IPv4地址空间或/ 48个IPv6地址空间。 这可能会很好地限制您可以拥有的游泳池数量。
另外，如果我们正在讨论授权服务器，那么DNS答复将与您所有的NSlogging和A和AAAA胶水一起放入一个512字节的数据包中。 对于根服务器，这个解决了13个地址。 但是，这不包括胶水和IPv6，所以你会达到的数量会更低。
每个池应尽可能地理分布。 如果你在欧洲有5个服务器，在Noth America有5个服务器，并且有2个任播IP，你不会在每个大陆上创build一个池。 你把来自欧洲的2个来自北美的3个游泳池，另外5个来自另一个游泳池。
如果您拥有两个以上的任播池，则可以让物理服务器临时处于多个池中。 但是，你绝对不应该让物理服务器同时在所有池中。
结合任播和单播是可能的，但必须小心。 如果你有两个IP池的IP，我不会合并。 但是，如果您只有一个单播IP协同工作，则也可以包含单播IP。 问题是，包括单播IP不会给你一个很好的延迟和负载平衡。
如果一台物理服务器可以通过单播和任播两种方式获得，则用户可能会冒险到达与主用和备用服务器相同的服务器，并且如果发生故障，将会失去访问权限。 这可以通过仅使用不在Anycast池中的服务器的单播地址或总是为用户提供两个单播地址来避免。
混合使用的单播地址越多，发送到任播地址的查询就越less，从延迟和可伸缩性方面来看，从任播中得到的好处就越less。
最佳做法是使用至less两个来自不同前缀的地址，并在两个不同的顶级域名下给它们一个名称。 如果你愿意，这两个地址都可以被任意选播。 只有一个IP地址会给你一个单点故障。 如果到该地址的路由不起作用（configuration错误，任播实例工作不正常，前缀被劫持等），那么你的整个域变得无法访问。
每个任播地址将需要至less一个/24 IPv4或/48 IPv6前缀在BGP中可路由。 在很多地方，全球路由表中通常不会接受较小（较长）的前缀。
永远不要把一个伪造的IP地址作为DNS服务器。 这将给解决scheme造成严重的延误。
RFC 1034仅指出您需要两台DNS服务器。 这不是一个强制性的要求，而是一个build议，所以你要做什么。 无论如何，如果你想要高可用性，你的2台DNS服务器可以使用任意广播来分配相同的IP地址，当一台DNS服务器出现故障时，最终用户唯一会注意到的就是networking重新连接的瞬间缺乏连接性。
所以总而言之，使用Anycast就足以满足RFC 1034的要求。