本文为翻译文章，原文地址：https://sysdig.com/blog/dns-security-cloud-protection/
在云中使用DNS时，安全性不容忽视。本文适用于云架构师和安全从业者，他们希望了解有关DNS安全部署选项的更多信息，以及云中DNS的一些安全最佳实践。
您将学习DNS安全的DNS最佳实践，并看到DNS云方法的优势。DNS的三个主要要求是：
在本文中，我们从DNS基础知识开始，然后转到云中的DNS主题。接下来，我们将更深入地研究DNS安全性，并最终提出一些建议，以帮助您决定满足DNS需求的“构建与购买”方法。
让我们来看看DNS基础知识。非常熟悉DNS并只想了解云端DNS的读者可能希望跳过。
什么是DNS？
您可能知道，DNS 是 Domain Name System 的缩写。正如 Paul Mockapetris 在 1987 年最初定义的那样，后来被不少于 45 个（！）其他RFC的扩展，DNS 是互联网的电话簿（对于我们这些记得电话簿的人）。
在实际连接到网站时，我们使用 DNS 客户端而不是电话号码来向DNS 服务器询问该网站的IP 地址。我们查找完全限定域名（也称为主机名）而不是联系人姓名，例如www.sysdig.com ，如果 DNS 正常工作，我们会收www.sysdig.com的 IP 地址作为答案，现在我们可以连接了。
DNS查询如何工作？
DNS不仅仅适用于手机和PC。它还用于与互联网连接的厨房电器，如冰箱或咖啡机！让我们从一个图表开始，以显示简单的DNS查找的基本步骤。
DNS 是按层次结构组织的，最上面是根服务器，下面是顶级域（.com、.net、.org）以及国家域。根服务器遍布世界各地，必须以稳健、防弹的方式进行架构。
至于传输协议，UDP 端口 53 是你的朋友，但最近TCP 端口 853也是。我们没有从我们的应用程序或 Web 浏览器中看到 DNS 查找，因此这里有一个使用dig作为 DNS 客户端的命令行。
早些时候，我谈到了在您不知情的情况下将未加密的 DNS 货币化的隐私问题。幸运的是，像EDNS、客户端子网指示，当然还有DNS over HTTPS (DoH) 和DNS over TLS (DoT) 等相对令人兴奋的发展正在使事情变得更好，包括功能和隐私。
DNS非常大。根据[ Verisign Domain Names 报告，截至 2022 年第一季度，所有顶级域 (TLD) 的域名注册量达到 3.505 亿。其中[大约有 1262]( Verisign Domain Names report)个TLD，包括原来的 8 个。
DNS用例和架构
有两个主要的 DNS 服务器用例和两个主要的部署架构。
作为我们需要在组织内部解决的所有问题的
内部 DNS 服务器。
例如（并注意这听起来有些陈旧）文件服务器、邮件服务器、打印服务器和数以千计的其他类型的设备，它们使传统的组织网络运转起来。
作为面向 Internet 的 DNS 服务器，用于来自 Internet 的查询。在远程工作、后疫情时代的 SaaS 世界中，这不仅可以处理我们的客户，还可以处理我们的员工。
当然，大多数组织都会同时拥有这两个用例。有时在同一台服务器上组合，一些使用单独的服务器。使用 DNS 视图或“[拆分 DNS]( Verisign Domain Names report) ”是 DNS 最佳实践。
两种主要的部署架构是
- 构建您自己的 DNS 基础设施。这种方法是互联网最初二十年左右的唯一选择，并且一直是喜忧参半的成绩单。一般来说，DNS 的 DIY 方法很难做到正确，尤其是在规模上。但现在我们有了选择。
- 在云端使用 DNS。至少在过去十年中，将 DNS 用作服务一直是一种选择，并且越来越多地被接受。许多原因使其成为可行的第一选择，其中最重要的是一切都在迁移到云端。
在本文中，我们将重点介绍云中的 DNS。
云架构中的DNS
查看托管 DNS 提供商的基本高级架构，出现了一个共同的主题。在内部，这些提供商中的每一个都有自己的秘诀，但这超出了本文的范围，而且在大多数情况下，它实际上并不是公共信息。
有关这些提供商如何构建其 DNS 服务的公开记录信息揭示了一个通用的边缘网络任播架构，如下所示：
使用 Anycast，全球分散的 DNS 服务器通告一个相同的 IP 地址，该地址通过 BGP 的魔力传播出去。第 3 层路由自然会导致 DNS 查询到达最近的服务器。这提供了冗余、性能、可靠性和最低延迟。
在此基础上，我们构建了云中DNS高级架构的视图：
云 DNS 提供商在全球任播边缘网络上部署一组 DNS 服务器，并向其客户提供 DNS 作为服务。客户使用 API 或 Web 界面来配置他们的区域并将他们的域委托给 Cloud DNS 提供商。DNS 提供商负责在整个服务器群中复制客户配置。
之后，流程如下。
- 基于 Anycast 的魔力，DNS 查询被路由到最近的 DNS 服务器
- 云 DNS 服务器向客户配置查询的 FQDN（完全限定域名）。
- 云 DNS 服务器通常会在算法中添加健康检查和地理定位。这确保了返回的答案指向“健康”的资源，即可用且可用。
- 对于相对于原始查询具有低延迟的健康资源，返回 DNS 答案
共同责任模式
如果我们放大，我们会看到云中DNS的共享责任模型。
- 托管 DNS 提供商负责 DNS 服务器本身的部署、维护、安全、数字安全、性能和可靠性
- 客户对其具体配置负责：
- 域包括域注册。
- 区域和记录，将 FQDN（完全限定域名）映射到云资源，例如 VM 或托管区域。
- 管理用户帐户。
- 资源的健康检查配置（包括频率和超时间隔）。
- 资源的地理位置记录
云端DNS功能
云端DNS（也称为托管DNS或DNS即服务）是DIY的替代方法，具有关键优势。
注意：云中的DNS不是您在AWS EC2实例上站立BIND的地方。云中的DNS意味着您将DNS硬件、软件以及大部分DNS安全性外包。没有BIND或其他DNS软件需要维护，也没有操作系统或虚拟机需要维护。DNS引擎是从您那里抽象出来的，您只需要处理您这边的共享责任模型。
云中的DNS为许多优化打开了大门（例如之前涵盖的Anycast）。在现代网页上，每个图像、添加按钮、小部件、链接、图标和其他嵌入式内容可能有一个唯一的主机名和一个顶级页面，例如www.cnn.com需要100多个DNS查找才能加载页面！
谢天谢地，DNS是云真的很快，看看其中有多少给了你一位数毫秒的响应时间？您可以在https://www.dnsperf.com/上从几个不同的地理位置亲自尝试一下
来源：https://www.dnsperf.com/
云端DNS的好处
云中 DNS 的好处不仅仅是低延迟、安全性和可靠性。以下是云中 DNS 的主要优势：
安全。更多内容请参见下文，但本质上您将 DNS 服务器本身外包，您不必担心保持 BIND 或其他 DNS 软件的补丁和安全以防止最新的黑客攻击，您不必担心 DDOS 攻击会停止您的 DNS 服务器，或任何其他会影响您必须关心和提供的 DNS 服务器的令人讨厌的漏洞和攻击。可以说，历史上最著名的 DNS 软件错误当然是已故的 Dan Kaminsky 在 BlackHat 2008 上首次宣布的Kaminsky 攻击。
性能。云中的 DNS 非常非常快。由于有数百个 DNS 实例和任播，这将比您建立自己的面向 Internet 的 DNS 服务器所实现的任何目标都要快。已经完成了一些有趣的测试，比较了您可以阅读的云托管 DNS 性能。
部落知识。如果您在云中托管的 DNS 在您的云提供商上，例如在 AWS 的情况下，则具有强大的集成能力。例如，Route53 了解 AWS 资源，因此您可以利用 AWS 特定的优势，例如针对负载均衡器的健康检查、基于服务的路由规则等等。
定价。DNS 即服务，如 Route53，价格实惠且性能卓越，已被用于创意，例如将其用作
非常便宜且功能强大的数据库服务器！
可靠性。在 DNS 要求方面，容错、可扩展性和可靠性不仅仅是任播，还与性能共享最高荣誉。毫无疑问，云中的 DNS 比您自己构建的任何东西都更可靠，除非您有大型网络云提供商的预算。作为托管 DNS 的可靠性示例，AWS Route53 是唯一提供100% 正常运行时间。SLA 的 AWS 服务。如果出现中断，这实际上可能表现为您的 AWS 账单上的退款信用，因此您可能需要一个备份提供商来接近真正的 100% 正常运行时间。稍后请参阅有关堆叠多个提供程序以获得更大冗余的更多信息。
使用 DNS 即服务的另一个好处是尽可能远离 DNS 引擎的实现细节。BIND 当然会在这里浮现。好消息是大多数主要的云 DNS 提供商要么使用定制的 BIND ，要么根本不使用 BIND，这消除了一个非常大的变量。
集成云DNS
我们中的许多人正在部署到公有云，并为业务应用程序制定了云优先策略。那么，由于我们的应用程序和服务已经在云端，拥有了解云服务的DNS并可以利用它们有意义吗？
什么是集成云DNS？
集成云 DNS 是我最近提出的一个术语，因为我认为我们需要一种方法来描述来自云提供商的托管 DNS，其中包括与其他本地服务的特殊挂钩。这些钩子提供了集成。
一般来说，云模式强调松耦合模式，虽然我们不想支持紧密耦合，但任何一般规则当然都有例外。
具体来说，当您映射到 DNS 的 IP 地址是同一云提供商中的服务时，DNS 和这些服务之间更牢固的“耦合”提供了一些真正的优势。当然，这对部分云提供商来说是有意的，因为这有助于推动其原生服务产品的采用和忠诚度。
然后是使用集成 DNS 的一些强制功能，有时即使您不想要它，也会将 DNS 作为副作用。举一个具体的例子，考虑启动一个资源，例如 EC2 实例——这会自动为该资源生成一个 DNS 记录。并且您的开发人员可能会开始使用这些记录。
这种“牢固”的耦合提供了以下好处：
- 无需担心的一组凭证 – DNS 服务可以利用您现有的身份和访问管理 (IAM) 策略。
- 基于逻辑而非 IP 地址的运行状况检查，具体示例是实例 ID 和标签。当 IP 地址可能不时更改时非常有用，但 AWS EC2 实例 ID 和标签的持久性将比 IP 地址长得多。
- 使用 AWS Cloud Trail 等现有云日志记录机制审核 chagnes 和日志记录。
- 与 AWS Guard Duty 等现有云安全控制和策略集成。
但是让我们看一些具体的例子来说明我在说什么：
Amazon Route 53与其他 AWS 服务进行了定制集成，包括 Amazon IAM、Amazon API Gateway、Amazon ELB、Amazon VPC、AWS S3 Buckets 等。这是一个简单的例子，最好是直观地展示：
以下是Amazon Route 53如何与Kubernetes集群集成的另一个示例
在安全性方面，DNS安全有精心设计的集成。
集成云DNS比较
两个主要的集成云DNS产品是Google Cloud DNS和AWS Route 53。
Google Cloud DNS具有许多出色的功能，为紧密耦合提供了理由。AWS Route53也是如此。但是，尽管Route 53多年来一直与AWS负载平衡集成，但谷歌云DNS刚刚开始使用自己的负载均衡器集成。
谷歌云DNS最佳实践有点通用，不是很具体，但它们包括：
使用条件转发
使用DNS对等互连
打开谷歌云防火墙以允许DNS流量
挖掘AWS Route 53，如Google Cloud DNS，它具有许多功能，如果您在VPC中站立传统的DNS服务器，您将无法获得这些功能。
在使用AWS路由53时，有几个DNS最佳实践似乎要具体得多，包括：
- 将TTL设置为60或120秒，用于快速故障转移机制
- 使用数据平面 Route 53 运行状况检查
- 利用路由53别名记录而不是CNAME记录
- 始终是基于地理位置的路由的默认值
当然，我们必须包括AWS Route 53与AWS负载平衡的非常好的集成。
但一个更有趣的例子是，AWS Route 53与AWS EKS Elastic Kubernetes Service for ExternalDNS紧密耦合。此功能需要AWS身份和访问管理（IAM）权限，允许Amazon EKS访问Amazon Route 53。
这些有形的好处是DNS最佳实践，使用自己的滚动方法将非常难以实现，并且是紧密耦合好处的一个很好的例子，当然，紧密耦合的通常权衡也适用，例如更深入地锁定特定的云提供商。
我们不能忘记管理审计日志记录：与谷歌云DNS一样，将跟踪AWS Route 53的AWS帐户中所做的任何更改。在AWS的情况下，这种跟踪是使用CloudTrail完成的，就像CloudTrail获得的一样接近实时。现在，您只需要弄清楚哪些更改是危险的，可能需要额外的解决方案或工具。
您不想知道您的AWS帐户中是否有人将VPC与托管区域关联，更改资源记录集，注册域，或围绕您的Route 53配置从事其他危险行为吗？
当谈到GCP的谷歌云DNS和AWS Route 53 DNS服务时，让我们深入了解它们是如何堆叠的。
云DNS比较：谷歌云DNS与AWS路由53
云DNS安全功能比较：谷歌云DNS与AWS路由53
堆叠多云DNS
在本文前面，我们讨论了 DNS 的原始高度分布式预期部署实际上是如何得到巩固的，并参考了几篇关于为什么这是一件坏事的学术研究文章。著名的 Dyn 攻击当然会在您阅读本文时浮现在您的脑海中，因为许多大型 Web 资产实际上并没有备用 DNS 提供商。
但实际上很容易避免受到下一次 Mirai 攻击的影响：不要将所有鸡蛋放在一个篮子里。使用多个云 DNS 提供商。
虽然 DNS 坚持至少有两个权威名称服务器 (NS)，但这些都是菜鸟号码，您可以继续使用 4、6、8 甚至更多，并在多个云 DNS 提供商之间平衡它们。当然，您必须使它们保持同步。
因此，为了支持这一建议，这里是我为您可能会认识的三个北美大型金融组织查找 DNS 服务器时制作的屏幕截图。
您可以通过对dig命令的响应看到，这些机构中的第一个似乎使用 DIY 方法托管自己的 DNS，而第二个和第三个正在使用在云中拥有多个 DNS 的“堆叠”方法（也称为作为 DNS 即服务）提供商，为他们提供可能很难实现的冗余。其中一个是同时使用 Ultradns 和 Akamai，另一个是使用 NS1 和 Akamai。
DNS攻击类型和危险
DNS 危险可能是明显的危险，例如 DDOS 和偷偷摸摸的黑客攻击，但我们不能忽略可能导致 DNS 暴露和易受攻击或导致意外中断的配置错误。
DNS危险的主要类型可以分为三类：
- 基于容量 DDOS 的拒绝服务
- 黑客和漏洞利用
- 失误和自残
DDOS攻击
在过去的几年里，Dyn和AWS Route53都受到过大规模的DDOS攻击，尽管这些确实造成了中断，但想象一下每秒1.2太比特的DDOS攻击会对您自己的自托管DNS基础设施造成什么影响。
Dyn Mirai Attack阻止了Reddit、纽约时报、Twitter、Netflix、GitHub和AirBnb等数百万人使用的网站的DNS解析。这次攻击利用Mirai控制了一支物联网设备大军，从数千万源IP攻击Dyn。最近，在2022年6月，安全研究员Brian Krebs报告了起诉经营一家企业的罪犯的进展情况，这些罪犯提供启动基于DNS的DDOS攻击的工具。
很多鸡蛋，几个篮子
就Dyn而言，为什么“互联网”因为一个DNS提供商受到攻击而停止？理论上，由于完全分散，DNS应该是完全多余的，但事实证明，它实际上只是伪分散的。根据Moz.com的数据，在前500个网站中，有181个使用上述5个服务之一作为其DNS提供商。
您可以在这篇伟大的论文《互联网熵下降的证据：哈佛大学研究人员的主要网站和服务在DNS分辨率方面缺乏冗余》中深入研究这个主题。
DNS黑客
如果DDOS是大锤，还有其他DNS攻击类型更像手术器械。很难对所有这些DNS攻击类型进行分类，但高层次的黑客分为两大类：
- 从内到外的DNS黑客，如DNS隧道
- 来自外部的DNS黑客，如DNS欺骗和缓存中毒
从简单的Google Dorks到查找子域（网站：*.sysdig.com-www-store-jobs-uk），再到Github上的各种很酷的工具，有很多现成的滥用DNS选项。
来自内部的DNS黑客体现在许多DNS隧道和泄露DNS攻击类型上。一般来说，在这些类型的攻击中，黑客利用这样一个事实，即防火墙几乎总是允许DNS数据包发送到任何IP地址。正如Infoblox的一位作家所写的那样，DNS走私有一个相当精彩的看法：“DNS数据泄露就像在不打开车库门的情况下偷车：你必须把车分解成小块，穿过门窗，然后在外面重建汽车。”我认为这是一个非常聪明和有趣的类比。
以下是DNS走私的一个非常简单的示例（还有其他例子）：
假设攻击者已经在您的网络中，可以访问信用卡数据库，但希望发送信用卡号码而不被发现。
攻击者在互联网上站立DNS服务器，并注册了一些听起来很无辜的域名，如“windows-server-update-microsoft.net”，在撰写这篇博客文章时，它恰好以大约12美元的价格可用。
注意：甚至不要考虑注册此域名！我只是向你展示这个斜坡有多滑。您会认为微软在沙发垫上零钱，可以很容易地让一些数据科学家运行一些专注于关键字“更新”和“窗口”的域生成算法，并提前简单注册所有这些域......但我们在这里：
在他们的DNS服务器上，攻击者启用查询日志记录，以便记录每个查询。然后，从网络内的脚趾握持，他们运行一个脚本，循环所有信用卡号码，并将其附加到DNS域，如下所示：
现在您已经知道DNS的工作原理了，您可以看到此查询不会转到windows-server-update-microsoft.net服务器......相反，查询会转到配置的本地DNS解析器，而该解析器反过来又将其转发。瞧，当查询到达攻击者的DNS服务器时，查询内容将被记录。
但这并不是唯一一种由内而外的 DNS 攻击。一旦进入您的网络，坏角色可以瞄准您的DNS服务器，并尝试像任何服务器一样控制它们。DNS服务器的区别比大多数服务器更丰富，因为一旦控制了这一点，黑客可以将流量引导到他们想要的任何地方。
通过重定向常见域名并避免粗糙且易于检测的策略，例如为命令和控制服务器使用特殊的DNS名称，黑客可以避免检测。
来自外部的DNS黑客包括现代侧通道攻击和DNS劫持，如海龟，但当然最著名的是DNS缓存中毒。
经典的DNS缓存中毒和DNS欺骗黑客已经存在了几十年。事实证明，一旦橡胶上路，由于部署笨重且有问题，DNSSEC等缓解措施没有得到广泛采用。由于配置和维护DNSSEC是多么痛苦，外包给已经提供DNSSEC的DNS云服务可能是一个更好的选择。
一个重大的隐私问题是，大多数DNS服务器不支持加密，这导致了MiTM的担忧。默认情况下，今天。来自Firefox浏览器的DNS查询由卫生部加密，并转到Cloudflare或NextDNS。是的，覆盖您的操作系统配置的内容！
著名的Kaminsky攻击表明，BIND对响应的薄弱验证如何允许攻击者暴力强制正确的事务ID，当时只是一个16位数字。
有基于域名本身的黑客攻击。域名数量之多构成了基于域名本身文本的混淆攻击的大表面积，包括Brand Impersonation、TypoSquatting、CyberSquatting和Look-a-Like网站。
具有备用TLD、同字域、连字符域的域以及具有“登录”或“www2”或“支持”等关键字的域以及该品牌的域是构建各种攻击的基础，如域名接管、OWASP CSRF攻击和网络钓鱼。
整个博客文章可以写在有趣的DNS工具上，如DNS Razzle。为了好玩，我尝试了一个稍微简单的名为dnstwist的域名生成算法（DGA）工具，在这里，我正在对域名netflix.com运行它，以查看所有排列。这可用于错别字攻击，看到有多少是可怕的，而且不太可能所有这些IP地址都属于netflix！
DNS 配置错误、模糊和中断
DNS错误配置和错误涵盖了从直接错误配置错误到在补丁方案上落后的范围内。DNS因难以配置而臭名昭著。核心BIND本身有这么多错误，它们不断出现。并出现。
遵循DNS最佳实践将有助于避免这些情况，但有很多DNS错误和混乱的故事，比如这个。
尽管世界上一些最大的组织可能无法避免不时犯错误，但在几乎所有情况下，将您的DNS外包给大型DNS即服务提供商仍然会更加可靠，因为他们有庞大的团队，除了专注于保持DNS一直运行外，什么也不做。
正如卡内基梅隆大学的Aqsa Kashaf、Vyas Sekar和Yuvraj Agarwal在分析现代网络服务中的第三方服务依赖性：我们从Mirai-Dyn事件中吸取教训了吗？“堆叠”多个DNS提供商是有道理的，这样，如果一个DNS提供商出现问题，您将滚动到一个基于完全独立基础架构的备份DNS提供商。此备份可能是另一个云DNS提供商，甚至可能是您自己——例如，在Dyn事件发生后，twitter.com通过部署除Dyn以外的私有DNS来增加冗余。
同样，如果您可以轻松堆叠托管DNS提供商，例如，您的NS SOA记录有AWS Route 53（有时缩短为Route53）和Google DNS，我个人在金融行业关键领域的多达8条NS记录中看到了这一点。毕竟，没有人希望银行网站的DNS失败！
DNS安全最佳实践
DNS特别容易受到体积DDOS攻击（作为目标和棋子），可以以各种方式被黑客入侵和利用，并且具有无关紧要的自我伤害维度，因为配置错误（包括无法跟上补丁）可能会导致中断甚至更糟。
有一些低级、非常具体的DNS最佳安全最佳实践，例如将主DNS服务器隐藏在代理后面。你必须把这些弄对。
但是，即使您正确掌握了所有低级配置细节，如果您在战术层面不遵循高级最佳实践，您最终仍可能会遇到麻烦。我们研究了可用信息，并提出了以下高级最佳DNS安全最佳实践：
安全配置和修补
如果您自己正在构建DNS基础设施，您有责任跟上CVE和DNS软件的其他更新。鉴于DNS中不朽错误的历史（BIND，我正在看你），将您的DNS修补视为最重要的服务。部署DDOS保护和DNS防火墙。酌情使用DNSSEC，并考虑卫生部对隐私的影响。对每个有权访问配置的帐户使用多因素身份验证（MFA），并使用TLS 1.2或更高版本与管理界面通信。
了解您的域名（以及谁在注册）
一个真正基本的步骤是了解您的所有域名，以及它们如何映射到您的应用程序。想象一下，如果这失控会发生什么。编排您的所有DNS服务器、所有区域以及您的DNS架构和拓扑。一个很棒的策略是通过观看这篇博客文章中描述的云日志，实时掌握域名创建。
部署DNS监控解决方案
DNS 中断甚至可能发生在最大的组织中。这就是为什么在您监控应用程序正常运行时间时，您将受益于更精细的DNS监控，以了解与其他问题（如应用程序堆栈不执行或数据库中断）相比，DNS本身是否造成了问题。DNS监控解决方案列表在这里，但也有很多其他解决方案。
了解您的DNS安全功能
了解您现有的DNS解决方案或服务提供商提供的安全功能。从您的DNS供应商那里获取您的路线图以获得安全性，并确认他们致力于跟上DNS安全的发展。如果您没有提供安全功能的DNS解决方案或服务提供商，请转储它们并找到一个提供安全功能的。请参阅本文前面介绍的DNS功能表。
大量且有效地记录
正如应用程序的所有方面都依赖日志一样，您需要以相同的优先级收集和分析DNS日志。您的DNS日志可能会显示威胁检测的早期指标，对于使用您的安全信息和事件管理（SIEM）或类似工具进行补救至关重要。使用AWS CloudTrail设置API和用户活动日志记录。
部署威胁预防
使用威胁提要阻止对恶意域的请求。在杀戮链的早期使用DNS威胁过滤将防止攻击对您的Web服务器进行TCP SYN。DNS的威胁提要也可以适用于DNS如何影响电子邮件服务。您需要酌情部署允许列表和阻止列表，并监控DNS流量的异常。从相反的角度来看，您可以使用https://www.dnsbl.info/等服务来了解其他组织是否错误地屏蔽了您的域名。
采用云优先的DNS策略
十多年来，随着组织推动数字化转型和现代化，云优先一直是推荐的方法。DNS也不例外。
托管DNS很容易证明这一点。云中DNS的简单性、安全性、鲁棒性、性能和有效性应该是默认的部署方式。考虑“堆叠”您的DNS提供商也是一个好主意，这样如果发生另一个Mirai，您就有一个备份提供商。
云提供商知道，许多客户无法在一夜之间关闭其本土的DNS架构。AWS Route 53甚至包括将私有DNS与AWS集成的高级功能，称为混合云的AWS Route 53解析器。
对于一些角落情况，例如高安全性、黑暗环境等，100%的云DNS不合适，但它仍应是您的默认情况。
结论
您已经看到了DNS对互联网和内联网上的应用程序和业务策略至关重要。
当DNS不起作用时，什么都不起作用。即使从应用程序和微服务的角度来看，您在互联网上部署的服务和应用程序是防弹的，如果DNS不起作用，没有人可以消耗您的服务，事情就会停滞不前。
您已经了解了为什么选择正确的部署策略很重要。
DNS最重要的要求是：
有两种基本的构建方法：
- 经典的DIY方法。
- 构建自己的DNS确实是可能的，在遗留环境中，它将持续多年。
- 展望未来，对于新的部署，DIY方法可能仅限于极端情况，例如高安全性环境。
- 创建一个高度可扩展、可靠和高效的DNS基础设施需要时间、金钱和专业知识。
- 利用云DNS
- 该行业的趋势是使用这种方法。
- 对于大多数组织和用例来说，这是满足DNS要求的最佳、最具成本效益的途径。
- 云端DNS的功能和采用率正在增长
虽然您可能也有两者的混合，但云优先策略仍然适用。
虽然决定权在你手中，但云端的DNS有很多优势，很难朝着不同的方向前进。
