什么是 DNS 解析失败？

Scrapeless 代理会通过网关基础设施来路由客户端请求，而该基础设施会添加其自身的命名和后续连接边界。

当解析器无法获得完成 DNS 查询所需的有效信息时，就会发生 DNS 解析失败。许多应用程序会更宽泛地使用这一说法，把任何未能产生可用地址的查询都称为失败。为了进行精确诊断，需要区分“解析失败”和“有效的否定应答”，后者表示某个名称或所请求的记录并不存在。

DNS 失败具有精确定义和实用含义

当解析器通过获取命名信息或有意义的否定答案来完成查询时，即表示一次解析已完成。当天无法获取有用信息时，解析就失败了。 DNS 解析失败分类 明确地区分了这种情况和否定回答。即使某个应用在顶层消息中将这两种结果都称为查询错误，这种区分仍然是有用的。

一个请求地址的应用程序在遇到多种不同结果后都可能无法继续。主机名可能不存在。名称可能存在但没有所请求的地址记录。解析器可能会遇到服务器故障、权威服务器不可达或验证问题。应保留底层的 DNS 结果，而不是将它们合并为“域名不可用”。

The DNS 响应代码和记录格式 为这些结果提供相应的术语。对于一条实用的事件记录，应保留精确的查询名称、请求的记录类型、在可用时的响应代码以及所使用的解析器。一张显示“无法访问该网站”的截图通常会遗漏大部分此类证据。

名称解析问题发生在客户端能够将得到的地址用于其预期连接之前。DNS 查询成功并不保证返回的地址会提供所请求的服务。请将查询结果与后续的连接结果分开对待，以免一个正常的 DNS 应答掩盖了实际上不可达的监听端口。

否定回答、服务器故障和未答复的查询

负向 DNS 应答会传达有关被请求名称或记录的信息。NXDOMAIN 表示在该 DNS 应答中，被查询的名称并不存在。无数据结果则可能表明名称存在，但所请求的记录类型缺失。即使应用程序无法利用这些信息进行连接，它们仍然是有意义的应答。

服务器故障响应表示响应的 DNS 服务器未能成功完成查询。超时表示客户端未能在其截止时间内收到所需的响应。这些结果需要解析器和权威路径的证据；它们并不能证明所请求的主机名不存在。

避免将宽泛的运行时代码视作完整的 DNS 诊断。一些库在未暴露 DNS 响应码的情况下就报告查询失败，而某些命名接口在其查询路径中包含本地配置源。在可能的情况下，保留原始运行时细节，并收集特定于 DNS 的证据。

对于自有主机名，比较权威记录状态与实际失败的查询。检查拼写、子域名、记录类型和委派情况。对于第三方主机名，记录观测到的结果和作用范围，不要假设你能够修复其区域。目标方运营者掌控其发布的命名信息。

通过相同的解析器路径查询同一名称

解析器的选择是观测的一部分。工作站、容器、浏览器和代理网关可以使用不同的命名路径。某个环境中的查询成功并不能证明另一个环境也能解析同样的名称，或能获得相同的答案。

识别应用程序请求的确切名称。代理网关主机名、目标主机名以及重定向目标都可能需要查询。如果错误与网关有关，只检查网站名称会错过实际失败的查询。如果重定向更改了主机名，第一页可能解析成功，而下一个主机则会解析失败。

The DNS 解析器和权威服务器模型 解释了为什么查询位置很重要。解析器可以从缓存中作答，或遵循已发布的委派来获取信息。在企业环境中，私有解析器还可以暴露经批准的内部名称，而公共解析器则无法解析这些名称。

不要将必需的组织解析器盲目替换为公共解析器作为修复手段。对比在策略允许时是有帮助的，但不同的结果需要进行解读。内部命名、网络策略以及分裂 DNS 可能会让私有答案在设计上与众不同。对于已接受的生产捕获，请保留所需的命名路径。

缓存解释了观察结果之间的一些差异

DNS 缓存会随着时间推移改变解析器返回的信息。即使在权威区域发生更改之后，缓存的记录或否定答案仍可能保持相关。 负面 DNS 缓存规则 解释缺失信息与肯定答案一样也可以被缓存。正因如此，“记录已被添加”与“每个客户端现在都能看到该记录”并不相同。

在清除本地状态之前，先检查观测到的应答及其缓存上下文。本地缓存的更改无法纠正权威委派或远程解析器已存储的结果。如果客户端之间存在分歧，记录每个客户端所看到的解析器和应答。分歧是有用的证据，但并不能证明某个客户端已损坏。

对于自有迁移，在规划记录和委派更改时要考虑预期的缓存行为。在命名变更被观测期间验证旧的和新的服务端点。即使 DNS 查询本身成功完成，到达旧地址的客户端也可能遇到后续的证书或连接错误。

在监控中，将解析器故障与否定应答区分开来。名称未找到结果的上升可能表明 URL 源数据格式错误或子域名不存在。服务器故障的上升可以指向解析路径。响应类别决定接下来应检查哪些证据。

代理端 DNS 增加了另一层命名边界

代理工作流可以在多个位置解析名称。客户端通常需要在连接之前解析其代理网关。目标解析可以根据协议和客户端配置发生在代理上。不要假定所有 DNS 都是本地的，而是要确定查询实际发生的位置。

对于在 HTTP CONNECT 交互中指定目标主机的情况，网关的后续路径很重要。如果网关无法解析或连接到目标，客户端可能会收到隧道失败或代理响应，而不是本地解析器的错误。记录代理响应和请求中的 authority，以便网关运营方进行调查。

SOCKS 客户端在处理目标名称的方式上也可能有所不同。使用客户端所选代理模式的文档化行为。仅有 SOCKS 代理的存在，并不能确定是本地客户端还是网关解析某个特定主机名。

当前 无抓取代理端点配置 为客户端侧边界提供网关取值。从授权渠道复制这些取值。网关主机名中的拼写错误与目标域解析失败属于不同的事件，尽管二者都可以在内容可用之前中断采集。

与后续网络阶段相比的 DNS 诊断

DNS 结果应作为请求记录中的独立阶段。这可以防止下游连接错误被误标为名称解析失败。

地址应答证明在观测条件下解析器确实返回了一个地址。它并不能证明该地址属于当前健康的应用，或目标证书与请求的名称匹配。连接被拒绝、TLS 错误和 HTTP 响应都需要各自的证据。

对于采集器，在标记查询或后续路径未解析的同时保留源 URL。不要把一次不成功的查询变成一个有效的空白页面或已移除的条目。本次抓取并未确定资源的内容状态。当数据源本身生成了错误主机名时，将格式错误的 URL 保留在单独的输入验证类别中。

创建有用的解析器事件记录

解析器事件记录应标明失败的查询和观测点。包括请求的记录类型、实际使用的解析器、响应类别、耗时，以及应用是直接连接还是经由网关连接。避免收集无关的浏览历史或私有查询参数。

在升级自有域问题时，添加预期的权威记录以及本应令其可用的部署变更。在升级网关问题时，提供已净化的通道引用和目标 authority。这些细节可以将运营方引导至正确的查询，而不泄露通道密码。

“ 云代理路由模型 ”为定位网关和后续连接边界提供相关上下文。“ 无抓取代理网络 ”有助于托管路由，但路由无法修复错误委派的目标区域。查看“ 当前 Scrapeless 方案 ”时，仅根据你已确定的流量和路由需求进行参考。

先解决命名问题，再解决内容问题

当所需解析器路径为预期查询返回可用且可信的命名信息时，DNS 解析故障即被解决。有效的否定应答则可能表明被查询的资源名称不存在；要保持这一含义的清晰。

只有在理解命名阶段之后，才继续进行套接字、TLS 和 HTTP 检查。记录每个阶段可以保留以下区分：缺失的主机名、失败的解析器路径，以及成功解析地址后其后的应用不可用。