.io域名_停止将.IO域名用于生产流量

.io域名

注意：如果您是 Stream 的用户 ，请确保将您的API客户端更新到最新版本，以大大提高可靠性。 对于使用自定义API客户端的用户，请查看我们更新的 REST文档 。

域解析是Internet的骨干服务之一。 我们通常很少花时间考虑这一点。 当然，它在中断时会改变。 在过去的一年中，IO域中断一直是我们的客户无法使用Stream的第一原因。 具体来说，2017年9月20日的停电是一个令人头疼的大问题。 本文将详细介绍.IO域名可靠性问题背后的细节以及我们如何解决这些问题。

Internet域名系统（DNS）的基础结构庞大而复杂。 由于其分散的性质，如果问题出在您的DNS提供商或更广泛的DNS基础结构上，除了坐下来等待问题解决之外，您几乎无能为力。 解决DNS中断的唯一实际解决方案是回退到备份域。

这使DNS中断非常令人讨厌。 许多风险是复杂的，且缓解的成本很高，在某些情况下，实际上是不可能做到的。

出了什么问题：.io顶级域的全局中断

在2017年9月20日，我们的系统监视器和运行状况检查开始显示间歇性故障。 对我们的网站和API服务器的Ping无法将“ getstream.io”记录解析为有效的主机名。

要访问我们的核心API服务和仪表板，必须进行域名解析。 没有它，客户端将无法找到我们服务器的地址。 毋庸置疑，这立即被视为至关重要，并得到了我们团队的充分关注。

经过初步调查，我们发现解析任何getstream.io记录将随机失败，并返回错误的NXDOMAIN错误。 随后，我们的一位工程师发现，在6个权威.io域名服务器中的2个上，.io域的解析将始终失败。 其余四个运行正常，这说明了错误的明显随机性。

坏的情况如下所示：

由于这是在权威名称服务器上发生的，因此我们与DNS提供商联系，然后也尝试与NIC.io联系。 令我们惊讶的是，我们发现NIC.io仅可在UTC星期一至星期五上午7点至凌晨12点之间通过电话访问，而未公开有关服务运行状况的任何状态 。

同时，我们开始查看还有谁受此中断的影响，并在Twitter和Hacker News上发布了有关此中断的信息。 在等待中断结束的同时，我们还增加了DNS TTL，以使DNS查询量尽可能少。 此后不久，我们收到了Gandi.net的回复，通知我们NIC.io正在解决该问题。

中断持续了将近2个小时，在此期间，任何.getstream.io记录的DNS查询的1/5都会失败。 对于摆在我们服务面前的事情，这是一个巨大的问题，并在我们这方面提出了多个问题。

TLD不会发生这种情况吗？

我们懂了。 有时候事情会破裂。 实际上，任何顶级域都可能发生类似的中断。

早在2014年成立之初，我们就从品牌角度决定.io很棒。 Stream是技术产品，而我们的观众主要是技术人员，因此.io似乎很合适。 对于API使用相同的域，更多的是结果，而不是经过深思熟虑的决定。

无法估计.com名称服务器与.io名称服务器发生相同故障的可能性。 令我们感到惊讶的是，尽管所有.io域的DNS解析度都达到了20％左右 ，但很难在Twitter上找到抱怨的人。 实际上，我相信我们是第一个发布此消息的人。 如果所有.com域都发生了这种情况，那么所有新闻来源都将大火。

真正错误的地方

不幸的是，我们发现NIC.IO不具备管理顶级域所需的技术支持和系统的困难方式。 在发生重大故障时无法联系到他们是无法接受的。

进一步看，发现.io TLD团队在过去几年中犯了一些错误，这并不需要进行大量研究。 仅举几个：

• 一年前发生了几乎相同的中断 （错误的NXDOMAIN负面响应）。
• 2017年7月，来自Google的安全工程师能够购买其中一个权威名称服务器 （ns-a1.io） 的域，并获得对每个.io域的控制权。

在HN上搜索.io会返回一长串类似的中断。

最好的立即解决方案是什么？

添加一个.com域并将其用作所有我们的API客户端的默认域显然是一项艰巨的任务。 当然，如果.com发生故障，我们可能会遇到同样的问题，但是，我们对.com背后的管理更有信心。 显然，不仅可以早日发现问题，而且人们无需花费数小时就可以确认并纠正这种情况。

我们的DNS免费服务路线图

这些DNS问题导致我们停下来思考一下DNS破坏的所有方式。

1. 我们失去了对自己域名的控制。 这可能以惊人的多种方式发生：

• NIC.io决定取消我们的域 。
• 我们忘记了续订 域名 （哎呀）。

1. Route53中断。 由于我们将getstream.io委派给Route53名称服务器，因此它们的名称服务器中断会中断我们的服务。 从2016年开始的DynDNS DDoS中断就是一个例子。
2. .com TLD中断。

由于我们控制API客户端，因此实现故障转移机制非常容易。 设置和维护备份域和/或备份DNS提供程序可能非常具有挑战性。 在第一种情况下，我们需要使数百个DNS记录保持同步，并使我们的SSL证书增加一倍； 其次，我们只需要更改基础架构即可不使用任何Route53特定功能。 为此，我们需要使两个不同提供商之间的所有DNS记录保持同步，并确保我们不使用任何特定于供应商的功能。 作为AWS客户，这是一个重大挑战，因为DNS已通过许多方式进行了深度集成。

展望未来，我们的计划是添加一个.org域并找到一个DNS提供程序来管理名称服务器。

结论

事后看来，将.IO域用于我们的核心API并不是一个很好的选择。 9月20日的停电表明问题和支持基础架构的严重程度。 根据我们的经验，如果可用性很重要，建议不要使用.IO域名。

要解决DNS问题，Stream的API流量现在在.com域名上运行。 该站点仍在.io上运行，因为这很难更改，并且对于正常运行时间而言并不那么重要。 为了进一步提高可靠性，我们正在考虑：

• 添加备用.ORG域名。
• 将备用DNS提供程序用于.COM或.ORG域名。
• 在我们的SDK中实施客户端DNS故障转移。

整体而言，DNS是大多数人理所当然的事情之一，但很容易造成严重的停机和麻烦。 使用诸如.com / .net / .org之类的广泛使用的TLD是确保可靠性的最佳，最简单的方法。

这是GetStream.io团队的合作，由GetStream.io的CTO Tommaso Barbugli领导。 原始博客文章可以在https://getstream.io/blog/stop-using-io-domain-names-for-production-traffic/中找到。

翻译自: https://hackernoon.com/stop-using-io-domain-names-for-production-traffic-b6aa17eeac20

.io域名