Go net.Resolver 自定义 DNS 解析超时的实现

Go 里想自定义 DNS 解析超时，关键不是只给 net.Dialer 设置一个数字，而是把“整次解析预算”和“连接 DNS 服务的预算”分开。调用 Resolver.LookupIPAddr 时用 context.WithTimeout 约束整个查询；在 Resolver.Dial 中再用 net.Dialer.DialContext 约束 UDP 或 TCP DNS 连接。这样超时发生在哪一层，日志和重试策略都能判断清楚。

推荐的组合是：PreferGo: true、Resolver.Dial 透传收到的 context，并在每次查询外层创建可取消的 context。不要在 Dial 回调里使用 context.Background()，否则调用方的截止时间无法传到底层连接。

官方参考：https://pkg.go.dev/net#Resolver

一、先把两层超时拆开

net.Resolver 的 Dial 字段只改变纯 Go resolver 访问 DNS 服务的连接方式。它不是业务连接的拨号器，也不会替你设置一次 LookupIPAddr 的总时限。真正的总时限应由调用者创建的 context 持有。

官方实现会把查询 context 传给 resolver 的拨号函数；因此可以在同一条链路里传递取消信号。下面的关系图是静态说明图，用来区分两个预算，不是本机运行截图。

二、配置 PreferGo 与 Resolver.Dial

自定义 DNS 地址时，显式打开 PreferGo 更容易保证当前 resolver 使用 Go 内置实现。Dial 回调要使用传入的 ctx，并保留 resolver 给出的 network；它可能是 udp 或 tcp。如果把 network 强行改成另一种，实际超时和故障行为就不再与 resolver 的选择一致。

package main

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

func newResolver() *net.Resolver {
	return &net.Resolver{
		// 只让这个 resolver 使用 Go 内置 DNS 实现，不改变全局 GODEBUG。
		PreferGo: true,
		// 多个子查询中出现临时错误时，要求整体返回错误而不是部分地址。
		StrictErrors: true,
		Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
			dialer := &net.Dialer{
				// 这是连接 DNS 服务的局部预算，不是整次解析的总预算。
				Timeout: 800 * time.Millisecond,
			}
			// 使用 resolver 传来的 ctx，让外层取消可以打断底层拨号。
			return dialer.DialContext(ctx, network, "192.0.2.53:53")
		},
	}
}

func lookup(ctx context.Context, host string) ([]net.IPAddr, error) {
	resolver := newResolver()
	// 外层 deadline 覆盖查询、重试和响应解析的整体时间。
	queryCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
	defer cancel()

	addrs, err := resolver.LookupIPAddr(queryCtx, host)
	if err != nil {
		if errors.Is(err, context.DeadlineExceeded) {
			return nil, fmt.Errorf("dns lookup timeout: %w", err)
		}
		return nil, err
	}
	return addrs, nil
}

示例中的 192.0.2.53 是文档保留地址，只用于说明配置位置；生产环境应替换为已确认可访问的 DNS 服务 IP。不要把它换成 dns.example.com:53 之类的主机名，因为 resolver 为了连 DNS 服务又需要先解析这个主机名，容易形成递归依赖。

三、用 LookupIPAddr 执行带超时的解析

每次请求都应创建自己的查询 context，而不是把一个带 deadline 的 context 长期放在全局 resolver 里。Resolver 可以复用，deadline 不应复用。对于 HTTP 客户端，外层还可以把请求 context 传入 lookup，让请求取消和 DNS 取消保持一致。

如果只需要一个地址，也不要因为返回切片为空就直接认为是超时。合法的“没有地址”、名称不存在、DNS 服务失败和 context 到期，应该分别记录 host、DNS 服务地址、网络类型和错误类型。这样排障时能看出是名称问题、解析链路问题，还是后续连接问题。

四、错误判断与参数边界

DNS 查询失败时，先检查 context，再检查 *net.DNSError 的字段和错误链；不要只比较错误字符串。StrictErrors 设为 true 后，A/AAAA 等多个子查询中的临时错误更可能使整体失败；设为默认值时，部分地址结果可能仍可返回。选择哪种策略取决于业务是否允许降级。

还要留意 UDP 与 TCP 的差异：回调收到的 network 是 resolver 当前请求的网络类型，必须让底层连接支持它；超大响应、截断响应或特定 DNS 服务策略可能涉及 TCP，不能只把 UDP 当成唯一通道。内层 800 毫秒和外层 2 秒也不是固定答案，应根据服务的尾延迟、重试次数和上游连接预算调整，但内层预算不能悄悄超过外层剩余时间。

常见问题与边界

为什么设置了 Dialer.Timeout，LookupIPAddr 还是等很久？

Dialer.Timeout 只覆盖建立 DNS 连接的阶段。若没有给 LookupIPAddr 传带 deadline 的 context，查询本身仍可能等待其他 resolver 工作；应同时设置外层 context。

Resolver.Dial 里能不能直接调用 net.Dial？

可以建立连接，但会丢掉传入 context 的取消和 deadline。更稳妥的是使用 DialContext，并把 network 传给它。

StrictErrors 一定要设为 true 吗？

不一定。需要完整 A/AAAA 结果时可以设为 true；能接受部分可用地址时保持默认值更有兼容性，但要在指标里区分部分成功。

收尾判断

自定义 Go DNS 超时的核心是两层预算和一条 context 链：外层限制一次解析能消耗的总时间，Resolver.Dial 限制访问 DNS 服务的连接时间，业务 TCP/TLS 连接再使用自己的预算。把三者分开配置和记录，才能在高并发请求中既快速失败，又不把 DNS 故障误判成业务服务故障。