设置定时 DNS 健康检查

一次性的 DNS 查询告诉您当前的状态，而定时、重复的查询则告诉您这个状态是否在变化。对于一个您并不打算改动的域名来说，变化通常正是值得尽快知道的事，而不是几周后才偶然发现。

确定要包含哪些内容

从那些一旦发生未被察觉的变更就会造成实际影响的对象开始：生产域名及其关键子域名、与邮件送达率相关的域名，以及任何列入安全观察名单的域名。为一个即使发生变更也没人会处理的域名安排定时检查，价值不大。目标是得到一个您真的会响应的信号，而不是一份没人看的完整日志。

选择检查频率

如何处理检查结果

任务本身只占一半价值，另一半在于某次运行的结果与上一次不同时会发生什么。至少要保留足够的历史记录，以便比较连续两次运行（本工具会在可配置的保留期内保存任务运行历史，原因正在于此）。把每次运行的结果导出为 CSV 或 JSON，就能方便地用程序做差异比对，而不必指望有人恰好在某天打开仪表盘时凭肉眼发现变化。

一旦定时任务稳定运行，实际效果就是把 DNS 监控从偶尔手动执行的任务，变成一个后台进程，只在真正有情况需要查看时才要求您的关注，这正是它的意义所在。

设计告警，而不仅仅是检查

如果每一次运行都发出通知，哪怕那些没有任何新发现的运行也不例外，用不了几周，人们就会学会忽略它，这就彻底背离了初衷。真正有用的信号是变化本身：这次解析出的地址与上次不同，某个域名从可解析变为失败（或者相反），或者一个新地址落在了本不该可达的地址段。围绕“自上次以来发生了什么变化”而不是“这是今天的结果”来构建通知，才能让告警在几个月后仍然值得点开，而不是变成收件箱里又一个未读标签。

检查本身失败时会怎样

定时任务需要为自身的失败制定预案，而不仅仅是针对它发现的问题。如果任务根本无法运行，比如队列积压、工作进程崩溃，或者它所依赖的底层基础设施宕机，那么这是一个比任何单个域名的结果都更特殊、优先级更高的信号，因为它意味着这张安全网本身已经悄无声息地失效，而且未必有人注意到。一个简单、独立的“任务是否在预期窗口内运行过”的检查，在运行延迟时发出告警，就能补上这个缺口；否则，一个悄悄停止监控的监控系统，可以说比没有监控还要糟糕，因为它会制造一种所有东西仍在被监视的虚假信心。