DNS配置很容易出错。为了尽量减少DNS中断的影响，你需要正确的流程和工具。
DNS对于互联网和现代数字企业的各方面运作至关重要。DNS是一个高度可用、高度冗余、高度可靠的服务，对你公司的应用和业务运营绝对是必不可少的。你的DNS出现故障会使业务停顿，危及你公司的未来。
DNS的问题是，配置文件中的一个微小的错误可以通过整个DNS产生连锁反应，并影响你公司运营的所有方面。一个DNS故障将阻碍你的客户使用你的产品的能力和你的公司赚钱的能力。如果没有扎实的DNS配置管理，你会使自己容易犯简单但代价高昂的错误。
DNS的变化是如此普遍和简单，以至于很少被认为是有风险的商业操作。对于较小的组织，开发团队可能会管理自己的DNS服务器，或有一些其他的方法来进行DNS的即时更改。随着组织规模越来越大，越来越复杂，DNS服务器的数量和可以对其进行更改的人数往往成倍增加。
有这么多人进行更改，偶尔出错并不令人惊讶。事实上，如果不出错，那就更令人惊讶了。
DNS中断是由各种因素造成的，包括人为错误、软件问题和硬件故障。但是，DNS中断的最常见原因是部署到DNS服务器的配置文件不正确。
一个缺乏高质量DNS卫生的小公司可以采取哪些措施，以便将高质量的DNS管理流程落实到位？以下是任何公司可以做的八件事，以提高其整体的DNS质量，以保持应用程序的运行和健康。
第1步:使用修订控制管理DNS配置
这是你可以做的最简单和最基本的事情，以提高你的DNS基础设施的质量。在核心部分，DNS配置是简单的平面文本文件。
许多DNS供应商给你提供了这些配置文件的前端控制面板，以便让你更容易进行修改。然而，它们也掩盖了你所做的改变的影响。不要使用这些控制面板!相反，使用标准的平面文本文件格式管理你的配置文件。
一旦你转移到平面文件格式，你就可以使用你用于管理应用程序源代码的相同的修订控制程序来轻松地管理这些配置文件。对于大多数公司来说，这就是Git的某种变体。
毫无疑问，今天你的公司已经有了管理源代码的程序，所以也可以使用相同或类似的程序来管理你的DNS配置文件。
这个简单的变化将使许多其他流程的改进自然而然地出现，如配置审查、审批工作流程，以及跟踪可能影响到你的应用程序的具体变化的能力。这是保持你的DNS服务运行和无错误的必要基础。
第2步:审查所有需要的DNS变更
一旦你使用修订控制程序管理你的变化，确保你所做的所有变化都被审查和批准。这可以像处理你的应用程序源代码一样，使用分支、拉动请求和合并来完成。
建立一个批准所有修改的程序。确保至少有一个或更多的人在将所有修改纳入生产配置之前对其进行审查。这个审查过程应该包括检查语法错误、不正确的DNS设置和其他潜在问题。DNS配置的问题可能是微妙的，所以应该由知识渊博的审查员进行彻底和有条理的审查。
第3步:记录所有修改的意图
你所做的每一个改变都应该被记录下来。如果你遵循上述步骤，那么这可以通过代码签入评论和拉动请求过程来完成。
如果存在问题或有人提出不兼容的改动，记录DNS的改动将有助于你以后的工作。了解为什么以前的改变会帮助你修复未来的问题，并帮助你理解为什么一个特定的改变可能或不合适。
第4步:配置部署过程自动化
一旦你有了管理配置文件的流程，建立一个流程来自动部署配置文件更新到你的生产DNS。通过自动化这个过程，你可以减少不正确的变化被推送到生产中的可能性，或者一个简单的人为错误会导致你的DNS失败或产生不良结果。
如果你发现自己在部署过程中从一个配置文件复制和粘贴变化到另一个配置文件，你将更有可能犯错并在DNS中引入一个错误。自动部署变化将确保变化以一致和可靠的方式应用。
你的自动化部署系统应该包括一个自动回滚机制。这可能是你的修订控制过程的自然延伸，或一个单独的部署回滚过程。但是，能够快速有效地撤消一个变化，可能意味着一个错误造成的小的不便或大规模的中断之间的区别。
第5步:发展成为一个更复杂的变更管理系统
随着你的DNS复杂性的增加，你可能要考虑在你已经建立的简单的版本控制系统的基础上，放一个完整的变更管理系统。全面的变更管理将涉及到使用变更请求表、授权请求、多团队签字和其他此类程序。
这些变化可能看起来很繁琐，但DNS配置不是一个可以在程序上偷懒的地方。一个简单的DNS变更可能会影响到你组织内的许多团队。在改变之前，甚至在改变建议被接受之前，征求这些团队的意见，可以为你以后节省很多麻烦。
你的变更管理系统的规模和复杂性自然取决于你的组织和其他软件管理流程的规模和复杂性。
第6步:使用一个独立的DNS供应商
一个高质量的DNS需要的不仅仅是配置管理。它还需要一个高质量的操作环境。
你的许多现有服务提供商可能会提供你可以轻松利用的DNS服务。特别是，领先的云服务提供商提供高质量的DNS服务。
然而，要小心使用由向你提供其他服务（包括其他云服务）的公司提供的DNS服务。
在服务中断期间，必须正常运行的最关键工具是你的DNS。你需要DNS来帮助你诊断和修复大多数其他故障。如果你的DNS也出现故障，你的故障时间将大大延长。
反之亦然：如果你正在处理DNS问题，你最不需要的就是由你的应用生态系统中的另一个服务引起的故障。
通过使用高质量的DNS供应商来避免这些问题，该供应商只向你提供DNS服务，不提供其他服务。这使你能够将你的DNS（以及你的DNS的任何问题）与你的应用程序中的任何其他服务隔离开来，减少与DNS有关的扩展中断的可能性。
确保你选择的供应商不依赖于你也已经在依赖的服务提供商，如云计算供应商!如果AWS发生故障，你希望你的独立DNS提供商能够继续运行。如果你的DNS供应商也依赖AWS，那就不会发生。
一些组织运行自己的DNS。如果你决定运行你自己的DNS，请确保你使用独立于你的应用程序其他部分的资源来操作它。这意味着在不同的数据中心、可用性区域，甚至是与你的应用程序其他部分不同的云区域中运行DNS。
第7步:分离内部和外部DNS
让我们把最后一点再往前推一步。你有公司内部的DNS需求和你的客户依赖的外部DNS需求。你的内部DNS提供对内部文件、内部系统（包括电子邮件和通信工具）以及其他内部流程和系统的访问。你的外部DNS为你的客户提供对你公司的应用程序、产品和服务的访问。
确保这两个DNS的需求是由不同的供应商处理的。如果你的外部DNS发生故障，如果你的内部DNS也发生故障，修复这个问题将变得非常困难。这是2021年10月Facebook瘫痪时Meta花了这么长时间来修复其应用程序的原因之一。
反过来说，如果你的内部DNS发生故障，你不希望这个问题扩散到你的外部客户。
使用不同的供应商以及不同的DNS配置和配置过程是避免这类问题的关键。
第8步:在另一个供应商中复制你的DNS
再往前走一步，使用两个不同的供应商设置你的生产DNS。使用一个作为主要供应商，第二个作为备份供应商。这样，如果你的主要DNS提供商发生故障，你就可以迅速将你的生产DNS切换到你的备份提供商。
备份提供商应该有一个完整的、可操作的、经过充分测试的DNS配置的副本，以便在需要时可以立即投入使用。如果你已经实施了上面推荐的自动化部署过程，这个过程会更容易。这个自动化过程可以帮助确保你的变化在你的主供应商和备份供应商之间保持同步。
DNS是一个关键的系统，应该从一开始就设计成高可用性和可靠性。在设计你的DNS基础设施时，你还需要考虑安全问题。确保你有冗余的系统，并且对你的DNS的访问是严格控制的。
最后，监控DNS对于确保你的系统继续顺利运行至关重要。你需要一些工具，在问题发生时提醒你，这样你就可以采取措施，尽快减轻影响。
DNS中断是一种常见的现象，但它们不一定会使你的整个公司陷入停顿。通过使用适当的程序和工具，你可以将任何故障的影响降到最低，并保持你的业务顺利运行。
