每个监控检查都是以同样的方式开始。在你首页、API 响应或 SMTP 横幅返回一个字节之前，监控代理必须先将主机名转换为 IP 地址。第一步就是 DNS 解析，你如何配置它会改变你的正常运行时间数据的实际意义。
大多数团队从未动过监控器上的 DNS 设置。他们指向一个检测目标 api.example.com，选择一个间隔，然后继续进行。但是该检测下的解析器行为决定了你是在测量真实用户体验、几秒内捕获 DNS 故障，还是生成可以跨运行比较的清洁响应时间。你无法同时优化这三者。
Dotcom-Monitor 正是基于这个原因为你提供了四种 DNS 解析模式。本指南逐一介绍，每种模式重点集中在大多数人容易弄错的选择上：缓存、非缓存与临时（基于 TTL 的）缓存。
为什么 DNS 解析是每个检测中的第一步
DNS 是你监控的几乎每个协议的第一跳。网站检查、API 监控调用、邮件服务器监控探测、ICMP Ping 监控测试——每一个都需要先获得 IP 地址才能建立连接。因此代理会先解析主机名，然后在其上执行 TCP、TLS 以及应用层请求。
这个顺序重要有两点。第一，DNS 查询时间是你总响应时间的一部分，缓慢的解析器会增加下游所有数值。第二，DNS 失败会在检测开始前阻止检测。如果解析失败，就没有连接可测试，没有证书可验证，没有状态码可读取。监控器报告严重失败，而根本原因则在你本以为正在监视的层下面。
因为 DNS 位于所有流程之前，代理处理该查询的方式是真正的设计决策，而非细节。每次请求都重新解析可以快速捕捉解析器问题，但增加负载和查询时间。缓存会使数值更快且更稳定，但错误的 DNS 记录可能会在缓存后面隐藏数小时。Dotcom-Monitor 的模式允许你根据实际监控的对象选择合适的权衡。想更深入了解如何缩减这第一跳时间，请参见我们的关于提升 DNS 解析时间的指南。
Dotcom-Monitor 的四种 DNS 模式
Dotcom-Monitor 在监控任务中公开四种 DNS 解析模式。每种模式改变 IP 地址来源及缓存时长。
设备缓存（Device Cached）
设备缓存是默认模式。在单次设备检测内，代理针对每个主机名仅解析一次，并在该检测期间与设备中的所有任务共享结果。如果检测中较早的任务已解析过该主机，后续任务会复用缓存的 IP，否则代理将执行完整查询并在检测期间缓存结果。
优点是效率。多数检测在一分钟内完成，因此没有必要每隔几秒解析相同主机。缺点体现在每任务时间点上。如果同一设备监控两个同主机的 URL，第一个 URL 需要包涵 DNS 查询时间，第二个使用缓存 IP，看起来更快，尽管本质没变。这是预期行为，不是错误，但初次查看瀑布图时会让人惊讶。
非缓存（Non-Cached）
非缓存模式完全跳过设备缓存。每次任务执行都会运行自己的完整 DNS 查询，因此每次检测都需要付出全部解析时间。这样保证了时序统一且可比，因为每次检测付出的解析代价相同。
权衡是负载和延迟。每次检测都新解析会增加任务时间和 DNS 基础设施的流量。非缓存模式不适用于基于浏览器的 BrowserView 或 UserView 平台。现实页面可能从同一主机拉取数十个元素，在几秒内多次解析主机名不符合浏览器行为，因此这些平台以每次检测仅解析一次为真实模型。
TTL缓存（TTL Cached）
TTL 缓存像用户端真正的解析器一样工作。它遵循记录的生存时间（TTL）：代理缓存已解析地址并继续使用，直到 TTL 过期，才通过本地 DNS 服务器重新解析。该模式最接近真实访客的体验，因为他们的浏览器和操作系统同样缓存。
风险在于该行为本身。如果支持该记录的 DNS 服务器失败，而缓存中仍存在有效答案，监控器直到 TTL 过期才可能注意到，TTL 可能设置为数小时、数天甚至更久。因此，如果目标是现实用户体验计时，TTL 缓存是合适选择；若目标是快速捕获 DNS 故障，则不适合。
外部 DNS 服务器（External DNS Server）
外部 DNS 服务器让你指定一个解析器 IP 进行查询。若你知道大多数用户使用公共解析器如 Google（8.8.8.8、8.8.4.4）或 Cloudflare（1.1.1.1），你可通过该服务测试解析。也可直接针对知晓权威区域的解析器，跳过递归查询，实现更快更直接的解析。
限制在于覆盖范围。只要指定解析器返回有效答案，监控就视为成功，即使负责该域的 DNS 服务器有异常。因此该模式测试的是该解析器视角，而非整个解析链。另需注意：每个不同解析器 IP 拥有独立缓存，指向不同外部服务器的两个任务保持各自缓存。
缓存、非缓存与临时缓存对比
这是让人混淆的决策，值得并列说明。缓存（设备缓存）优化效率。非缓存（非缓存）优化可比、可重复的时序和快速故障检测。临时缓存（TTL缓存）模拟真实浏览器一样，以年龄淘汰记录优化现实感。
| 模式 | 解析方式 | 适合场景 | 主要权衡 |
|---|---|---|---|
| 设备缓存（缓存） | 设备检测内解析一次，任务共享 | 高效检测；对同主机多个任务 | 首个任务含解析时间，后续任务看似更快 |
| 非缓存（非缓存） | 每次执行新完整解析 | 统一时序；快速检测 DNS 问题 | 更高 DNS 负载和延迟；不适合 BrowserView/UserView |
| TTL缓存（临时缓存） | 遵循 TTL，过期后重新解析 | 匹配真实用户体验 | DNS 服务器故障可能隐藏至 TTL 过期 |
| 外部 DNS 服务器 | 查询你指定的解析器 IP | 测试特定公共或权威解析器 | 仅见指定解析器结果，非整条链路 |
简而言之：缓存提高速度，跳过缓存快速捕获故障，遵守 TTL 观察用户体验。选择与检测目标相符的模式。
为什么大多数监控工具忽略 DNS 问题
让你值得设置这个的原因是：大多数监控工具不提供选择。它们解析一次主机，缓存结果，并持续复用这答案直到记录失效。这本可行，直到 DNS 问题出现在生产环境——错误的记录、权威服务器故障、解析器返回错误 IP——而缓存的监控器因使用过时答案仍显示正常，实际用户却遇到故障。
监控领域中对解析模式的细粒度控制很少见。强制每次检测新解析，依据 TTL 回收记录，或者指定特定解析器，都几乎是 Dotcom-Monitor 的标志性特性，是区分别只假设 DNS 正常的监控与实际测试 DNS 问题的监控的界限。如果捕获生产中 DNS 问题是检测目标，绝大多数工具默认的全部缓存行为恰恰是掩盖问题的罪魁。
如何选择合适的 DNS 模式
你选择什么模式取决于监控器旨在回答的问题。以下是 DevOps 和 SRE 团队最常见的几个模式。
你想尽快捕获 DNS 故障。使用非缓存模式。当检测是为了在解析失败的瞬间提醒——注册商更改出错、区域过期、记录被劫持等情况——你不希望缓存中有旧答案。每次检测都新解析意味着故障会在下一次检测显示，而非要等几小时 TTL 过期。配合严格的告警确保信号传达到值班人员。
你想获得匹配真实访客的时序。使用 TTL 缓存模式。如果检测服务于正常运行时间监控服务等级协议或实时用户体验仪表盘，按浏览器解析方式处理保持数据诚实。只需接受 DNS 故障检测可能延迟 TTL 时间，并且如果这点很重要，额外添加非缓存检测。
你对同一主机运行多个任务。默认的设备缓存通常合适。它控制 DNS 负载，且每次检测解析一次主机。阅读每任务瀑布图时考虑缓存：首个任务含解析时间。
你关注一个特定解析器。使用外部 DNS 服务器模式。适合团队验证 Google 或 Cloudflare 公共解析器返回正确记录，或直接检测特定权威服务器。它是有针对性的测试，建议同时保持广泛检测。更多策略请参阅我们对DNS 监控工具的综述。
每种模式捕获的 DNS 错误
DNS 是常见故障点，且其故障方式多样。迁移中记录被更改、区域过期、权威服务器宕机、甚至攻击者通过缓存污染使域指向其控制服务器。你的解析模式决定这些故障出现的速度。
非缓存模式是揭示解析问题最快的，因为它不信任之前的答案。TTL 缓存最慢，因为有效缓存记录可能在其背后故障发生时依然存在。外部 DNS 服务器捕获你指定解析器的问题，但可能错过链路其它位置的故障。如果你想了解到检查如何跨层次失败，我们的DNS、TCP、TLS 和 HTTP 故障指南对此有详尽解析。若关注宕机，应结合避免 DNS 宕机的操作手册，与非缓存检测配合效果更佳。
无论使用哪种模式，DNS 监控的目标是第一个发现记录变为非预期 IP。当主机名解析到异常 IP 时，Dotcom-Monitor 会生成错误并触发告警，帮助你在用户访问错误服务器前采取反应。
如何在 Dotcom-Monitor 中设置 DNS 模式
更改解析模式只需几次点击。具体标签会根据设备类型略有不同，但流程一致。
- 步骤 1：打开你想配置的设备或任务，进入 Dotcom-Monitor 平台。
- 步骤 2：编辑任务设置，找到 DNS 解析模式（或 DNS 选项）部分。
- 步骤 3：选择四种模式中的一个：设备缓存、非缓存、TTL缓存或外部 DNS 服务器。
- 步骤 4：若选择外部 DNS 服务器，输入要查询的解析器 IP，如 8.8.8.8 或 1.1.1.1。
- 步骤 5：保存任务并运行几个间隔，再查看响应时间拆分以确认 DNS 计时符合预期。
由于每个设备都从 Dotcom-Monitor 的全球监控网络运行，设置完成后你可以比较不同地点解析表现。
结论
DNS 解析是每次检测的第一步，因此解析模式不是可以自动驾驶的设置。需要高效检测时缓存，共享主机时缓存；要快速捕获 DNS 故障时跳过缓存；要反映真实用户计时时遵守 TTL；需要检测特定服务视角时指定外部解析器。
大多数团队最终会在检测中运行多种模式，因为单一监控很少回答所有问题。将模式与检测目的匹配，让你的数据真实反映 DNS 状况。
在 DNS 损伤你的正常运行时间之前先行监控
设置适合每项检测的解析模式，记录变化瞬间获得告警。Dotcom-Monitor 利用全球网络运行 DNS 监控，并提供本文指南中介绍的缓存控制功能。
