Go DNS 查询怎么设置独立超时并区分临时错误

Go 里不要用一个覆盖整个请求的超时，顺手猜 DNS 是否失败。更稳的做法是给 net.Resolver.LookupHost 单独套一层 context.WithTimeout，查询结束立即释放 context，再结合 context 错误和 *net.DNSError 判断下一步。这样可以把“DNS 预算用完”“调用方主动取消”“临时解析故障”和“域名确实不存在”分开。

核心写法是：解析阶段使用独立 context；先判断上下文是否结束，再用 errors.As 取出 DNSError，但不要把 Temporary() 或 Timeout() 为 false 直接当成永久失败，因为 Go 文档明确说明这两种状态可能未知。

先给 DNS 查询单独建立超时预算

DNS 只是请求链路中的一个阶段。比如一次 HTTP 调用总预算是 2 秒，可以给域名解析 500 毫秒，剩下的时间再留给 TCP 连接、TLS 和响应读取。解析阶段的预算应由子 context 表达，而不是修改全局解析器。

package main

import (
	"context"
	"fmt"
	"net"
	"time"
)

func lookupWithBudget(parent context.Context, host string) ([]string, error) {
	// 子预算只约束 DNS，不改变调用方的总生命周期。
	ctx, cancel := context.WithTimeout(parent, 500*time.Millisecond)
	defer cancel() // 释放定时器和关联资源。

	resolver := &net.Resolver{PreferGo: true}
	addrs, err := resolver.LookupHost(ctx, host)
	if err != nil {
		return nil, fmt.Errorf("lookup %q: %w", host, err)
	}
	return addrs, nil
}

LookupHost 返回的是该主机的地址列表，解析器会使用本机 resolver。PreferGo 只是在可用时优先使用 Go 内置解析器；它不是超时开关，真正的时间边界来自传入的 context。若父 context 已经结束，子 context 也会随之结束。

超时、取消和临时错误要分开判断

解析失败后，第一层先问上下文是否结束：如果是 DeadlineExceeded，说明这次查询用完了自己的预算；如果是 Canceled，通常是调用方不再需要结果。只有上下文没有给出结论时，才进一步拆解 DNS 错误。

func classifyLookupError(parent context.Context, err error) string {
	// 先看调用方的生命周期，避免把主动取消误判成可重试 DNS 故障。
	if errors.Is(err, context.DeadlineExceeded) {
		return "dns-timeout"
	}
	if errors.Is(err, context.Canceled) || errors.Is(parent.Err(), context.Canceled) {
		return "caller-canceled"
	}

	var dnsErr *net.DNSError
	if errors.As(err, &dnsErr) {
		switch {
		case dnsErr.IsNotFound:
			return "name-not-found"
		case dnsErr.Timeout():
			return "resolver-timeout"
		case dnsErr.Temporary():
			return "temporary-dns-error"
		default:
			return "dns-error-unknown"
		}
	}
	return "other-network-error"
}

上面的函数需要额外导入 errors。分类结果可以映射到不同动作：超时可按退避策略重试一次，临时错误可以进入短暂重试队列，名称不存在不应机械重试，而未知错误应保留原始错误和主机名供排查。

不要把 Temporary 和 Timeout 当成绝对真相

DNSError.Timeout() 表示 Go 已知这次 DNS 查找超时，Temporary() 表示已知它是临时错误；两者都可能返回 false，但这不代表事实一定相反。系统 resolver、操作系统配置、搜索域和不同网络环境可能让错误信息不完整。

因此，重试策略最好同时保留三类信息：错误分类、原始 error 和本次 context 是否到期。日志可以记录 dnsErr.Name、dnsErr.Server 和 dnsErr.Err，但不要把 DNS 服务器地址、完整错误文本直接当成用户可见提示。

接入连接时保留两层时间边界

如果解析后还要建立 TCP 连接，不要让 DNS 子 context 继续代表整个连接阶段。可以先完成解析，再使用另一个 context 调用 DialContext；或者让拨号器直接解析主机名，并让它自己管理包含解析在内的拨号预算。两种方案的语义不同，选择前要确认是否需要记录独立的 DNS 指标。

func dialResolved(parent context.Context, host string, port string) (net.Conn, error) {
	addrs, err := lookupWithBudget(parent, host)
	if err != nil {
		return nil, err
	}

	// 连接阶段使用新的预算，避免复用已接近截止的 DNS context。
	dialCtx, cancel := context.WithTimeout(parent, time.Second)
	defer cancel()
	dialer := &net.Dialer{}
	for _, addr := range addrs {
		conn, dialErr := dialer.DialContext(dialCtx, "tcp", net.JoinHostPort(addr, port))
		if dialErr == nil {
			return conn, nil
		}
	}
	return nil, fmt.Errorf("dial %s: all resolved addresses failed", host)
}

这里的重点不是“解析一次再永远缓存”，而是让每一段网络动作都有可解释的预算和错误边界。生产代码还应限制重试次数，并避免对同一域名的并发失败请求同时触发大量重新解析。

常见问题

为什么设置了 LookupHost 的 context，HTTP 总耗时还是很长？

因为 context 只约束传给它的解析阶段。TCP、TLS、读取响应和连接池等待仍需各自的预算，外层请求也应有总 deadline。

Temporary 返回 false 就不能重试吗？

不能这样绝对判断。false 只表示“没有被确认是临时错误”；是否重试还要结合是否超时、父 context 是否仍有效、重试次数和业务幂等性。

小结

• 用 context.WithTimeout 给 LookupHost 建立独立 DNS 预算。
• 先判断 DeadlineExceeded 和 Canceled，再通过 errors.As 读取 DNSError。
• Timeout()、Temporary() 为 false 可能只是未知，重试必须有限且带退避。