网络监视器的一篇文章”含咖啡因的DNS监控和AT&T DNS中断“发布在 SpeedAwarenessMonth.com 上关于 2012 年 8 月 15 日关于 AT&T 域名服务器 （DNS） 中断的帖子，说明了为什么非缓存的 DNS 监控方法会导致更快的修复时间 （TTR），甚至由于 DNS 问题而导致的停机时间为零。
全文可在 SpeedAwarenessMonth.com 获得，但基础知识包括：
缓存或不缓存 – 这是 DNS 监控问题
首先，通常不知名的是基于外部的HTTP请求类型的网站监控，就像本地java关节的咖啡一样，有不同的“等级”——基于缓存和非基于缓存。 Dotcom 监视器采用非缓存监视，该监视通过每个监视实例的完整 DNS 进程传播。 基于缓存的监视（由许多基本监视服务使用）不会通过 DNS 进程传播，并且会错过 DNS 问题。
如何有效监控下一次 DNS 中断情况
在AT&T DNS中断问题的情况下，有几个关键因素有助于加快修复时间（TTR）或避免停机：
- 错误检测方法：使用使用非缓存方法的监控解决方案将 DNS 查询一直传播到每个监控实例的根名称服务器。 缓存方法服务缓存 DNS，因此根本不会检测到辅助 DNS 问题，或者可能需要几天甚至几周的时间才能检测到问题。
- 监视频率：使用更快的非缓存监视频率，例如每 1 分钟一次，而不是每小时一次。 非缓存监视解决方案检测受影响的管理员使用失败的 DNS 服务并提醒受影响的管理员的速度越快，切换到 DNS 故障转移提供程序的速度就越快。
- 生存时间 （TTL） 设置的值：DNS 管理员用于从主权威名称服务器保留域的 IP 缓存的 TTL 设置的值越小，实现故障转移到另一个 DNS 提供程序的速度就越快。 通常设置为 86，400 秒（1 天）或更长时间，在灾难恢复计划中，TTL 可以设置为每 300 秒一次，但设置越低，权威域名服务器上的负载就越高。
- 诊断（例如检测到 DNS 问题时的自动跟踪路由）由监视解决方案提供（请记住，许多基本监视服务不提供任何诊断信息）。
- 修复：在错误情况下继续监视以进一步查明问题。 将受监视的结果发送给您的 DNS 提供商。 您还可以在 www.dotcom-monitor.com/WebTools/trace.asp 处运行免费的手动 DNS 跟踪路由（选择跟踪样式“DNS”），以根据需要验证问题。
- 预防：密切关注“软错误”DNS 问题，例如 DNS 速度减慢和间歇性 DNS 中断，以便在“软错误”变成“硬错误”（例如客户面临停机）之前采取措施。
谢谢，我会带咖啡因的双深水炸弹，非缓存
很明显，非缓存和其他因素的组合限制了由于2012年8月15日的AT&T DNS中断等问题而导致的停机时间。 此外，非缓存的 DNS 监控方法是加快 TTR 甚至零停机时间的关键因素。
最后，重要的是要记住，TTR决定了由于停机时间造成的损失。 换句话说，检测、诊断和修复 DNS 问题所需的总时间越长，DNS 问题的影响就越大。 相反，监控解决方案加快TTR的速度越快，损失就越少，或者完全避免。
与一杯优质的含咖啡因咖啡类似，非缓存方法可以在停机日和快速生产日之间产生差异。
有关 AT&T DNS 中断的更多信息，请参阅我们的文章《 正确执行 DNS 监控：AT&T DNS 中断》。
