注意:如果您是 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域的控制权。
最好的立即解决方案是什么?
添加一个.com域并将其用作所有我们的API客户端的默认域显然是一项艰巨的任务。 当然,如果.com发生故障,我们可能会遇到同样的问题,但是,我们对.com背后的管理更有信心。 显然,不仅可以早日发现问题,而且人们无需花费数小时就可以确认并纠正这种情况。
我们的DNS免费服务路线图
这些DNS问题导致我们停下来思考一下DNS破坏的所有方式。
- 我们失去了对自己领域的控制。 这可能以惊人的多种方式发生:
- Route53中断。 由于我们将getstream.io委派给Route53名称服务器,因此它们的名称服务器故障将中断我们的服务。 从2016年开始的DynDNS DDoS中断就是一个例子。
- .com TLD中断。
由于我们控制API客户端,因此实现故障转移机制非常容易。 设置和维护备份域和/或备份DNS提供程序可能非常具有挑战性。 在第一种情况下,我们需要保持数百个DNS记录同步,并使我们的SSL证书加倍; 其次,我们只需要更改基础架构即可不使用任何Route53特定功能。 为此,我们需要使两个不同提供商之间的所有DNS记录保持同步,并确保我们不使用任何特定于供应商的功能。 作为AWS客户,这是一个重大挑战,因为DNS已通过许多方式进行了深度集成。
展望未来,我们的计划是添加一个.org域,并找到一个DNS提供程序来管理名称服务器。
结论
事后看来,对于我们的核心API使用.IO域并不是一个不错的选择。 9月20日的停电表明问题和支持基础架构的严重程度。 根据我们的经验,如果可用性很重要,我们建议不要使用.IO域名。
要解决DNS问题,Stream的API流量现在在.com域名上运行。 该站点仍在.io上运行,因为这很难更改,并且对于正常运行时间而言并不那么重要。 为了进一步提高可靠性,我们正在考虑:
- 添加备用.ORG域名。
- 为.COM或.ORG域名使用备用DNS提供程序。
- 在我们的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/中找到。
From: https://hackernoon.com/stop-using-io-domain-names-for-production-traffic-b6aa17eeac20