dns重定向_变更时代的DNS综合监控是重要和必要的

DNS对健康互联网的重要性

选择DNS供应商是您在服务可靠性方面可以做出的最重要的选择之一。它也可以说是监控网络性能最重要的元素。如果DNS基础设施出现故障，依赖它的所有数字服务都将随之降低。当2016年大规模的DDoS攻击系列袭击Dyn时，这一点变得非常明显，并且北美和欧洲的大量用户无法访问互联网上的大部分网站和应用程序。

域名系统(DNS)是Internet的地址系统。这种基础技术是一个复杂的私人和公共服务网络，可确保您在浏览器中输入的URL是您要访问的网站。DNS查找和解析过程应该花费几毫秒，但如果在此过程中出现问题，您的浏览器将会滞后，无法访问该站点，或者更糟糕的是，被劫持并重定向到另一个(可能是恶意的)站点。

大多数Web规模的企业使用第三方DNS服务提供商来消除管理其全球DNS基础架构的麻烦。许多企业依赖于平台即服务(PaaS)模式，如Dyn，Cloudflare，Neustar，AWS或NS1，它们也被称为“托管DNS”。自2016年Dyn停电以来，许多企业也采用了多DNS策略 - 即选择辅助提供商和主要提供商 - 以保护自己，以便如果一个DNS供应商出现中断，他们的服务仍将通过其他供应商提供给最终用户。

DNS供应商合并

管理DNS提供商在业界最近发生了一些变化，包括甲骨文收购Dyn和Neustar收购Verisign的DNS合同。

甲骨文现在宣布它基本上关闭了Dyn，将其Web应用程序安全性，电子邮件传递和“同类最佳DNS”折叠到其原生服务中，仅通过Oracle云基础架构(OCI)平台提供。除互联网智能外，独立Dyn服务将于2020年5月停止提供。

Oracle云基础架构DNS服务上的新DNS服务不支持区域传输到外部域名服务器(多DNS架构的一个实现的关键)，Webhop(HTTP重定向)和DNSSEC。DNSSEC通过使用基于公钥加密的数字签名来加强DNS中的身份验证，这通常很弱。今年早些时候，ICANN呼吁在所有不安全的域名中最大限度地部署DNSSEC，并称，“为了让互联网具有广泛的安全性，DNSSEC需要得到广泛部署。”此外，有传言称，相当数量的ex-Dyn工作人员将被释放，可能只留下通才而不是支持专家。

决策时间

很多人现在想知道Oracle的DNS服务是否足够好。“所有这些变化都可能导致”企业依赖这些服务的已安装基地面临巨大风险，“NS1首席运营官Brian Zeman在最近发布的甲骨文公告中表示。另一方面，Verisign关闭并将合同转移到UltraDNS到目前为止已经成功。然而，仍有ITOps和NetOps团队回忆起他们对UltraDNS所面临的挑战以及他们为什么首先转向Dyn。

无论如何，整个DNS解决方案领域正在进行整合，并且正在减少提供全球Anycast足迹的可用托管DNS提供商的数量，旨在减少延迟并提供大多数现代全球数字服务所需的必要功能。

无论是采用单DNS还是多DNS策略(我们强烈推荐后者)，他们都会询问他们是否应该使用他们拥有的选项或更改为新的供应商。我们在Catchpoint面临同样的决定，并且已经实施了继续拥有可靠的多DNS架构的计划。

综合监测是必须的

大多数人认为他们只需选择一个可靠的DNS供应商，然后继续进行下一个供应商或工具评估。但实际情况是，你还远未完成，因为你刚刚将你的成功归功于另一家公司的可靠性和可用性。现在，您还必须不断监控DNS提供商，以确保您获得可靠的服务。

在多步DNS过程中存在许多可能出错的问题。大多数DNS供应商将Anycast系统用于其DNS基础架构，以确保DNS解析的低延迟。但是，这会增加其全球覆盖范围，并且随之而来的是微小中断的风险，其中特定区域的用户无法解析您的域并访问您的服务。

一个关键的监控策略是依靠真实用户监控(RUM); 但是，RUM不能让您充分了解中断或为SLA和基准测试提供稳定的测量，因为它仅在用户访问您的页面时收集数据。这意味着您无法快速(或根本)检测到问题，也无法正确解决问题。

相反，您需要从最终用户所在的关键地理位置，从尽可能多的位置进行全天候综合监控。Catchpoint的大量全球测试位置(称为节点)是我们最大的优势之一，因为它提供了跨越骨干网，宽带，云，最后一英里和无线提供商的有利位置。它们不仅提供对您来说重要的地理区域的可见性，还提供来自关键的公交，宽带和消费者ISP的可见性，以检测这些本地中断。

合成监控对DNS至关重要。它允许您查看所涉及的所有名称服务器的性能，并检测整个DNS解析链中的任何错误。它还为您提供了一个窗口，其中显示了DNS服务器(从MX到CName记录)使用的数据库记录，可以诊断错误的特定原因，例如配置错误，DNS缓存中毒或不安全的区域传输。

正如我们最近讨论的那样，监控您的服务水平协议(SLA)也很重要，而不是简单地依赖供应商对其服务的评估，这可能不会带来您作为买方所需的责任。

您从哪里测量SLA的问题不是通过使用第三方来解决的; 您需要确保您的监控服务没有从错误的角度进行监控。如果您考虑使用其中一个大型云服务作为新的DNS供应商，则尤其如此。

例如，如果您正在考虑将Amazon Route 53作为您的新DNS替代品或将新的DNS供应商纳入您的多DNS策略，那么使用来自APM供应商(如Dynatrace)的“Synthetics”进行监控非常重要， NewRelic，AppDynamics或Datadog将监控亚马逊数据中心的DNS。延迟将几乎为零，可用性将是最高可能性 - 因为合成监控代理不必通过互联网，只需到同一物理位置和同一网络中的下一个房间。

重要的是服务对您的最终用户的可达性，而不是亚马逊的可达性。从云监控根本没有意义; 你的最终用户不在那里。如果您使用Amazon或Azure进行DNS，您当然不希望也使用它们进行监控。

此外，您无法通过监控HTTP URL来仅使用推断的DNS指标来监控DNS，因为您并未真正监控DNS服务和提供服务的供应商基础架构。您将通过“权威名称服务器”，“递归解析器”和OS DNS解析的多个层来监控DNS解析。这意味着DNS TTL(生存时间)进入混合状态，DNS在用户的操作系统，浏览器以及跨用户共享的递归解析器上的缓存方式也是如此。

这就是为什么在Catchpoint，我们有一个专门监控DNS的监控器。它允许您通过复杂的DNS层次结构跟踪查询，查明问题，并解决您的供应商的任何问题，无论他们是在这些不断变化的时代。

DNS是客户与您的品牌的第一次互动; 它是最关键的，同时也是最脆弱的，因为UDP。

我一直很喜欢这个笑话：“我会告诉你一个关于UDP的笑话，但你可能不会得到它。”