Go 自定义 DNS Resolver 仍访问默认服务器怎么办

给 net.Resolver 设置了 Dial，程序却仍然访问系统默认 DNS，最常见的原因不是地址拼错，而是这次查询没有走 Go 内置解析器。Resolver.Dial 只负责 Go 内置解析器建立 DNS 连接；如果当前平台或运行时选择了原生/cgo 解析器，这个回调就不会成为实际路径。

解决方法是把 PreferGo: true 和自定义 Dial 放在同一个 Resolver 上，并让真正发起查询的代码使用这个 Resolver。对 HTTP 客户端，还要把它挂到 Transport 的 DialContext 关联的 net.Dialer 上。

先判断自定义 Dial 为什么没有生效

net.Resolver 的三个字段容易被混在一起理解：

• PreferGo：在支持的环境中优先选择 Go 内置 DNS 解析器，作用域只限于当前 Resolver。
• Dial：给 Go 内置解析器提供 DNS 连接函数，连接的地址参数是字面量 IP 和端口。
• DefaultResolver：包级查找函数和没有显式 Resolver 的 Dialer 使用的默认对象。

所以只设置 Dial 并不等于强制所有平台都走这条链路。尤其在 macOS、Windows 或存在特定解析环境变量时，标准库可能偏向原生解析器。下面这张静态说明图只展示依赖边界，不是运行截图。

排查时先确认调用方没有偷偷使用 net.LookupHost、net.LookupIP 这类包级函数。它们使用的是默认 Resolver，不会自动继承你新建的实例。

用 PreferGo 和 Dial 组合自定义 DNS

要让 Go 内置解析器向固定的 DNS 服务发包，至少需要同时设置 PreferGo 与 Dial。DNS 服务地址应该直接写成 IP:port，不能再写一个需要解析的域名，否则会形成循环依赖。

package main

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

func lookupWithCustomDNS(ctx context.Context, host string) ([]string, error) {
    resolver := &net.Resolver{
        // 让当前 Resolver 优先使用 Go 内置解析器，Dial 才有机会被调用。
        PreferGo: true,
        // DNS 端点使用字面量 IP，避免为 DNS 服务名再次触发域名解析。
        Dial: func(ctx context.Context, network, _ string) (net.Conn, error) {
            dialer := net.Dialer{Timeout: 2 * time.Second}
            // 忽略 Resolver 传入的默认地址，统一连接到指定 DNS 服务。
            return dialer.DialContext(ctx, network, "10.20.0.53:53")
        },
    }

    // 显式调用该 Resolver，避免误用 net.LookupHost 的默认对象。
    return resolver.LookupHost(ctx, host)
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
    defer cancel() // 释放超时计时器，避免请求结束后仍保留上下文资源。

    ips, err := lookupWithCustomDNS(ctx, "service.internal")
    if err != nil {
        fmt.Println("DNS 查询失败：", err)
        return
    }
    fmt.Println(ips)
}

这里的关键不是把 Dial 写得更复杂，而是让三个条件同时成立：使用当前 Resolver、启用 Go 内置解析器、在回调中连接实际 DNS 端点。若只改了第三处，运行时仍可能绕过回调。

把 Resolver 接入 HTTP Transport

如果问题出现在 HTTP 请求中，直接调用 resolver.LookupHost 只能证明解析链路可用，并不会自动改变 http.Client 的连接行为。HTTP 客户端要通过 Transport 的 DialContext 使用一个带 Resolver 的 net.Dialer。

package main

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

func newHTTPClient() *http.Client {
    resolver := &net.Resolver{
        // PreferGo 与 Dial 必须属于同一个 Resolver 实例。
        PreferGo: true,
        Dial: func(ctx context.Context, network, _ string) (net.Conn, error) {
            dialer := net.Dialer{Timeout: 2 * time.Second}
            // DNS 服务器地址使用 IP，回调只处理 DNS 连接，不充当 HTTP 代理。
            return dialer.DialContext(ctx, network, "10.20.0.53:53")
        },
    }

    transport := &http.Transport{
        // 让 HTTP 连接建立阶段使用带自定义 Resolver 的 Dialer。
        DialContext: (&net.Dialer{
            Timeout:   5 * time.Second,
            KeepAlive: 30 * time.Second,
            Resolver:  resolver,
        }).DialContext,
    }

    // 复用 Transport，避免每个请求重新创建连接池和 DNS 配置。
    return &http.Client{Transport: transport, Timeout: 10 * time.Second}
}

这个连接关系里，Resolver 只参与“把目标主机名解析成地址”；它不是代理，也不会改变 HTTP 请求的 Host、TLS 或路由。目标服务 IP 仍由解析结果决定，DNS 服务器只负责回答解析请求。

处理平台差异和失败回退

官方 net 文档说明，Go 会根据平台、构建方式和环境配置选择 Go 或原生解析器。下面几类情况尤其容易让“只设置 Dial”的代码看起来失效：

• 平台默认偏向原生解析器，例如部分系统为了兼容系统解析能力而这样做。
• 设置了 LOCALDOMAIN、RES_OPTIONS 或 HOSTALIASES 等环境变量。
• 构建标签或 GODEBUG=netdns=go/cgo 改变了运行时的解析器偏好。
• 实际请求使用了另一个 Transport、另一个 Dialer，或调用了包级 Lookup 函数。

兼容处理应当把选择写在配置层，而不是在业务代码里到处复制 Resolver。生产环境可以把 DNS 端点、是否启用 Go 解析器和超时时间做成配置，并在初始化阶段记录“当前客户端使用哪一个 Resolver 实例”。如果自定义 DNS 不可用，应该返回明确错误或切换到预先约定的回退方案，不要静默混用两个解析链路。

检查连接复用与安全边界

自定义 DNS 生效后，还要检查它是否符合调用场景。最小检查表如下：

还要限制配置来源：DNS 地址不应由未经信任的请求参数直接拼接，回调中也不应接受任意网络目标。自定义 Resolver 解决的是解析器选择和 DNS 连接问题，不能替代证书校验、HTTP 代理认证或应用层访问控制。

相关问题

为什么设置了 Resolver.Dial 仍然看不到回调日志？

先确认查询是否使用了这个 Resolver，再确认 PreferGo 是否为 true。如果调用的是包级 Lookup 函数或 HTTP 客户端使用了其他 Transport，当前回调自然不会出现。

Resolver.Dial 的 address 参数可以直接拿来连接吗？

可以，但它应被当作 DNS 服务地址使用；标准库文档约定其中的主机和端口是字面量，不是需要再次解析的服务名。若要固定 DNS 端点，直接使用配置中的 IP:port 更清晰。

自定义 DNS 能不能实现 HTTP 代理？

不能。Resolver 只影响域名解析，HTTP 代理需要配置 Transport 的 Proxy 或其他连接策略。把两者混在一个 Dial 回调里，会让故障边界和安全审计都变得模糊。