Go net.DNSError 的 IsNotFound 与 Temporary 怎么判断

Go 做 DNS 查询时，不要用 "no such host" 这类错误文字决定是否重试。更稳的做法是先用 errors.As 取出 *net.DNSError，再看 IsNotFound、Timeout() 和 Temporary()：名称不存在通常停止，已知临时故障才进入有上限的重试。

先把 DNS 错误还原成可判断的类型

查询错误经常被 fmt.Errorf("resolve: %w", err) 再包一层，直接类型断言可能失效。用 errors.As 沿包装链查找，才不会把一个真实的 DNS 错误误归类：

func classifyDNSError(err error) string {
    var dnsErr *net.DNSError
    // 沿 %w 包装链查找 DNS 错误，不依赖最外层类型。
    if !errors.As(err, &dnsErr) {
        return "unknown-network-error" // 交给通用网络错误路径。
    }
    // 名称不存在通常是配置或服务发现问题，不应盲目重试。
    if dnsErr.IsNotFound {
        return "name-not-found"
    }
    // Temporary 已包含 Timeout，这里保留超时分支便于记录原因。
    if dnsErr.Timeout() || dnsErr.Temporary() {
        return "temporary-dns-error"
    }
    return "unknown-dns-error"
}

IsNotFound 与 Temporary 不是同一个开关

这两个维度并不互斥：IsNotFound 说明目标是否存在，Temporary() 说明当前失败是否被识别为可恢复。两者都为 false，也不能绝对推出“永久失败”，因为解析器可能没有足够信息。

把状态接到有边界的重试策略

高并发服务中，所有 goroutine 都对同一域名重试，会把解析器故障放大。把“确定性不存在”排在最前面，临时信号只允许有限退避：

func shouldRetry(err error) bool {
    var dnsErr *net.DNSError
    // 先排除确定性失败，避免重试风暴。
    if errors.As(err, &dnsErr) && dnsErr.IsNotFound {
        return false
    }
    // 未知错误进入诊断路径，不自动扩大重试范围。
    return errors.As(err, &dnsErr) && dnsErr.Temporary()
}

// 调用方还应叠加最大次数、指数退避和 context deadline。

上线前至少记录 Name、Server、错误类型和最终动作；检查最大重试次数、退避上限与调用方 deadline 是否同时存在。这样才能区分“域名写错”和“解析服务暂时不可用”。

相关问题

为什么不直接比较 “no such host”？

错误文字是展示信息，包装层和平台解析器都可能改变它；IsNotFound 才是结构化判断。

IsNotFound 为 true 时还能重试吗？

默认不重试。若服务发现数据正在同步，应在更高层安排一次带期限的刷新，不要重复同一次 DNS 查询。

Temporary 为 false 就绝对不能重试吗？

不能绝对推断。官方说明临时性并不总是可知；必须容忍未知故障时，应依靠总预算和可观测性，而不是无限重试。