登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  Golang >  Go问答

Go Resolver 为什么设置 Dial 后仍然走系统 DNS

来源:17golang原创

时间:2026-10-26 18:08:20 355浏览 收藏

给 net.Resolver.Dial 写了自定义拨号函数,查询时却仍像是在访问系统 DNS,这个现象通常不是闭包没有执行,而是当前请求没有走 Go 内置 DNS 解析器。Dial 的作用范围很窄:它只负责 Go 内置解析器连接 DNS 服务时的拨号;如果解析路径选择了系统解析器,设置它不会自动改写系统解析流程。

官方资料:https://pkg.go.dev/net#Resolver

要让自定义 DNS 拨号生效,需要同时满足三个条件:在当前 Resolver 上优先使用 Go 内置解析器、让 Dial 返回能访问 DNS 服务的连接,并且让实际调用方使用这个 Resolver 实例。只改其中一个字段,排障现象就可能不变。

先确认 Resolver.Dial 的作用范围

Resolver.Dial 不是“所有 DNS 查询的全局代理”。Go 官方文档将它定义为 Go 内置 DNS resolver 连接 DNS 服务的可选拨号函数。也就是说,Dial 介入的是“解析器如何访问 DNS 服务”,不是“操作系统如何决定使用哪一种解析器”。

net.Resolver、PreferGo、Resolver.Dial 与 Go 内置和系统 DNS 解析器的静态关系说明图
图1:Resolver.Dial 与解析器选择范围的静态关系说明图,不是运行截图或 DNS 抓包。

在支持两种解析路径的平台上,Resolver 可能使用 Go 内置解析器,也可能使用系统解析器。只有前者会继续读取 Resolver.Dial。因此,看到系统 DNS 仍有请求时,第一件事不是在 Dial 里加日志,而是先问:当前这个查询到底由哪个解析器完成?

用 PreferGo 把选择范围限定在当前 Resolver

如果目标是让某一个解析器实例使用自定义 DNS 拨号,可以设置 PreferGo: true。它相当于把“优先选 Go 内置解析器”的意图绑定到这个 Resolver,比修改全局环境更容易控制影响范围。

package main

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

func main() {
	resolver := &net.Resolver{
		// 让当前 Resolver 优先走 Go 内置 DNS 解析器。
		PreferGo: true,
		// Dial 连接的是 DNS 服务地址,不是待查询的业务域名。
		Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
			var d net.Dialer
			// address 应是 DNS 服务的字面量 IP 和端口,保留 ctx 以支持取消。
			return d.DialContext(ctx, network, address)
		},
	}

	// 查询必须使用这个 resolver,不能又调用 net.LookupHost 的默认实例。
	addrs, err := resolver.LookupHost(context.Background(), "example.com")
	if err != nil {
		fmt.Println("DNS 查询失败:", err)
		return
	}
	fmt.Println("解析结果:", addrs)
}

这段写法的关键不是 Dialer 本身,而是 PreferGo 和最后那次 resolver.LookupHost 必须属于同一条调用链。若把前面的对象配置好,却改用包级 net.LookupHost,查询会回到 DefaultResolver,自定义实例自然不会生效。

正确理解 Dial 的三个参数

Dial 的签名是 func(ctx context.Context, network, address string) (net.Conn, error)。其中 network 通常表示 DNS 查询使用的传输类型,例如 udp 或 tcp;address 是 DNS 服务端地址。官方文档明确说明,这个地址中的主机部分始终是字面量 IP,端口部分是字面量端口号,不是需要再次解析的域名或服务名。

因此,下面几种写法的语义不同:

位置应该放什么常见误区
Resolver.Dial 返回的连接能与 DNS 服务通信的 net.Conn把业务服务器连接当成 DNS 连接
network解析器传入的 UDP/TCP 网络类型无视参数,固定成不匹配的网络
addressDNS 服务的 IP:端口字面量再用待解析域名拼一次拨号地址
ctx取消和超时边界新建无关的 Background,导致上层超时失效

如果需要通过代理、固定出口或特殊网络命名空间访问 DNS,可以在这个函数内部选择合适的拨号方式,但仍要返回符合 DNS 传输要求的连接;不能只返回一个已经连到普通 HTTP 服务的连接。

把同一个 Resolver 接入实际调用链

自定义解析器只有被调用方持有并使用才有意义。直接调用 resolver.LookupHost 最容易确认对象没有丢失;在 HTTP 客户端中,则应把它放到 net.Dialer.Resolver,再把这个拨号器交给 Transport。

net.Dialer、Dialer.Resolver、Resolver.LookupHost、Resolver.Dial 及 DNS 连接参数的静态结构图
图2:自定义 Resolver 接入调用链与参数边界的静态结构图,不是运行截图或请求证据。
package main

import (
	"context"
	"net"
	"net/http"
	"time"
)

func newClient() *http.Client {
	resolver := &net.Resolver{
		// 让 HTTP 使用的这一个 Resolver 选择 Go 内置解析路径。
		PreferGo: true,
		Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
			// 这里保留传入的 network、address 和 ctx,避免破坏解析器约定。
			return (&net.Dialer{Timeout: 2 * time.Second}).DialContext(ctx, network, address)
		},
	}

	dialer := &net.Dialer{
		Timeout:   5 * time.Second,
		KeepAlive: 30 * time.Second,
		// Resolver 必须挂在实际会被 Transport 使用的 Dialer 上。
		Resolver: resolver,
	}
	transport := &http.Transport{DialContext: dialer.DialContext}
	return &http.Client{Transport: transport, Timeout: 10 * time.Second}
}

排查时可以沿着这条关系检查:HTTP Transport 是否真的使用了这个 Dialer,Dialer.Resolver 是否指向目标对象,以及目标对象是否同时设置了 PreferGo 与 Dial。中间任意一层换回默认对象,最终看到的就可能仍是系统解析路径。

仍然走系统 DNS 时按三层排查

  1. 解析器选择层:确认当前 Resolver 是否设置 PreferGo: true,不要把“定义了 Dial”误认为“已经选择 Go resolver”。
  2. 对象接入层:确认实际调用的是 resolver.LookupHost,或者 HTTP 的 Dialer.Resolver 确实引用了该实例,而不是包级函数和 DefaultResolver。
  3. 拨号参数层:确认 Dial 返回的连接面向 DNS 服务,保留传入的 network、address 和 ctx,并处理错误。

还要注意,主机名已经是 IP 字面量时,解析器可能直接返回地址,不会产生 DNS 查询;这不是 Dial 失效。相同主机的并发查询也可能被解析器合并,不能把每一次业务调用都理解成一次独立的 DNS 拨号。

常见问题

为什么设置了 PreferGo 仍不能保证走自定义 DNS? PreferGo 是选择 Go 内置解析器的偏好,前提是平台支持这条路径;同时还要确认调用方确实使用了这个 Resolver。

能不能只设置全局 DefaultResolver 的 Dial? 不建议把排障依赖放在全局可变对象上。优先创建局部 Resolver,并显式注入到实际调用链,影响范围更清楚。

Dial 的 address 可以写成 DNS 域名吗? 不应这样设计。官方约定这里是字面量 IP 和端口,使用域名会引入递归解析或地址格式不符合预期的问题。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>