Go net.Resolver.LookupAddr 怎么做反向 DNS 查询并处理多个主机名

我在给连接日志补充主机名时，最容易先写错的不是 API，而是把正向和反向 DNS 的方向弄反。Go 里，net.Resolver.LookupAddr 接受 IP 地址字符串，返回映射到该地址的主机名切片；同一个地址可能有多个名称，所以不能只拿一个“首选主机名”。

要做 IP 到名称的反向查询，就调用 Resolver.LookupAddr(ctx, addr)，给它一个有截止时间的上下文，遍历返回的全部名称，并把“有部分名称但同时有错误”的情况单独记录。

正向查询和反向查询不是一回事

LookupHost 是“主机名到地址”，LookupAddr 是“地址到主机名”。后者通常依赖 DNS 的 PTR 记录。PTR 没有配置、解析器不可达或返回名称格式不合法时，结果就可能为空或伴随错误；这不等于 Go 把 IP 解析失败成了另一种地址。

调用参数是字符串。如果业务对象是 net.IP，先用 ip.String() 转成可读地址；IPv6 地址也直接按文本传入，不需要自己拼接反向查询域名。

用 Resolver.LookupAddr 传入上下文

日志增强、审计展示这类任务不应因为一次 DNS 查询拖住主流程。零值 net.Resolver 可以直接使用，关键是把超时放进调用上下文，而不是在调用外面用一个无法取消的 goroutine 包住它。

package main

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

func reverseNames(parent context.Context, addr string) ([]string, error) {
    // 给单次反向查询设置上限，避免日志任务无限等待 DNS。
    ctx, cancel := context.WithTimeout(parent, 2*time.Second)
    defer cancel()

    // Resolver 零值即可使用本机配置的解析器。
    resolver := net.Resolver{}
    names, err := resolver.LookupAddr(ctx, addr)
    if err != nil {
        // 这里保留 names，调用方可以决定是否使用部分结果。
        return names, fmt.Errorf("反向查询 %s: %w", addr, err)
    }
    return names, nil
}

示例返回的是“名称切片加错误”。这是为了保留 API 的信息：当返回名称仍有业务价值时，不要因为 err != nil 就把切片丢掉。需要严格成功语义的调用方，再把非空错误升级为失败。

把超时、空结果和多结果分开处理

真正写入日志时，我会把地址、名称数量、错误类型和耗时放在同一条记录里。多结果要完整遍历；空切片表示当前解析环境没有给出可用名称，不能擅自把 IP 当成主机名。错误则用 errors.Is 和 errors.As 分层。

import "errors"

func describeReverseLookup(ctx context.Context, addr string) {
    // 复用上层上下文，让请求取消能够传递到 DNS 查询。
    names, err := reverseNames(ctx, addr)
    if len(names) > 0 {
        // 一个地址可能对应多个 PTR 名称，不要只保存 names[0]。
        fmt.Printf("addr=%s names=%v count=%d\n", addr, names, len(names))
    }
    if err == nil {
        return
    }

    // 超时通常需要降级为“没有主机名”，不应伪造一个名称。
    if errors.Is(err, context.DeadlineExceeded) {
        fmt.Printf("addr=%s dns_timeout=true\n", addr)
        return
    }

    var dnsErr *net.DNSError
    if errors.As(err, &dnsErr) {
        // DNS 错误保留原始类型，便于区分临时故障和配置问题。
        fmt.Printf("addr=%s dns_error=%s\n", addr, dnsErr.Err)
        return
    }
    fmt.Printf("addr=%s reverse_lookup_error=%v\n", addr, err)
}

这里的输出是结构示例，不代表某个固定 IP 的真实查询结果。生产代码还可以把名称去掉末尾的根域点，但应保留原始值或明确记录规范化规则，避免后续排查时失去线索。

解析器配置决定了结果边界

LookupAddr 依赖本机使用的 resolver。Go 文档说明，系统可能选择纯 Go resolver 或 cgo/native resolver，操作系统、环境变量和 /etc/resolv.conf 等配置都会影响选择。排查“开发机能反查、容器里为空”时，应先比较运行环境的 DNS 配置，而不是立刻改成固定主机名。

Resolver.PreferGo 可以把偏好限制在这个 resolver 上，GODEBUG=netdns=go 或 netdns=cgo 则是更广的运行时选择。它们是部署排障手段，不是让 PTR 记录凭空出现的开关。反向 DNS 也只适合做展示、日志增强和诊断提示，不能单独用来证明连接对端身份。

常见问题

为什么返回多个主机名？

反向查询返回的是映射到该地址的名称列表，多个 PTR 或环境策略都可能让列表有多个元素。业务需要单值时应明确排序、白名单或展示规则，不要默认第一项永远可靠。

为什么没有错误却拿到空切片？

空结果通常意味着解析器没有返回可用的映射，是否算业务失败取决于场景。日志增强可以保留 IP 继续处理；强依赖名称的流程则应显式拒绝空结果。

LookupAddr 和 LookupHost 可以互相替代吗？

不能。前者是地址到名称，后者是名称到地址；即使两次查询看起来互相对应，也不代表 DNS 一定保持可逆关系。

我的取舍是：把 LookupAddr 当成一个有超时、可能多结果、可能返回部分信息的外部依赖。这样既能补全网络日志，又不会把一次反向解析抖动放大成主流程故障。