Go 语言如何实现一个简单的 DNS 服务器

Go 语言如何实现一个简单的 DNS 服务器

用 miekg/dns 库启动一个可响应 A 记录查询的 DNS 服务器

Go 语言的标准库并未提供 DNS 服务器的实现，这算是一个小小的遗憾。不过，社区早已给出了优秀的解决方案——miekg/dns。这个库可以说是 Go 生态中处理 DNS 协议的事实标准：它足够轻量，纯 Go 实现不依赖 Cgo，文档清晰，非常适合用于快速构建调试工具或嵌入到其他应用中。

安装起来非常简单：

go get github.com/miekg/dns

其核心逻辑非常直观：注册一个处理函数（dns.Handler），监听指定的 UDP（或 TCP）端口，对收到的 dns.Msg 请求进行解析并构造响应返回。下面是一个最精简的、能响应 A 记录查询的示例：

package main

import (
    "log"
    "net"
    "github.com/miekg/dns"
)

func main() {
    server := &dns.Server{Addr: ":53", Net: "udp"}
    dns.HandleFunc(".", func(w dns.ResponseWriter, r *dns.Msg) {
        m := new(dns.Msg)
        m.SetReply(r)
        m.Compress = true

        if r.Question[0].Qtype == dns.TypeA {
            rr, _ := dns.NewRR("example.com. IN A 192.0.2.1")
            m.Answer = append(m.Answer, rr)
        }
        w.WriteMsg(m)
    })

    log.Println("DNS server listening on :53")
    log.Fatal(server.ListenAndServe())
}

注意：在 Linux 或 macOS 上，绑定 53 端口（标准 DNS 端口）通常需要 root 权限。开发测试时，可以改用 :8053 这类非特权端口。

如何正确构造响应记录（dns.RR）避免解析失败

构造 DNS 响应记录（dns.RR）是个精细活，格式上稍有差池，就可能导致客户端收到畸形响应（malformed response）甚至直接超时。以下几个细节需要特别注意：

• 域名必须完全合格（FQDN）：即必须以点（.）结尾，例如 "example.com."。如果少了这个点，它会被视为相对域名，客户端可能会为其拼接上搜索域，导致解析目标错误。
• 使用 dns.NewRR() 的字符串格式：格式为 "name. TTL class type data"。其中 TTL 建议显式指定（如 300），如果不写，某些情况下可能被默认设为 0，导致记录无法被缓存。
• Class 字段大小写：一般使用大写的 IN。虽然协议本身可能不区分，但部分严格的客户端或解析器可能会拒收小写的 in。
• 返回多条记录：如果需要返回多个 A 记录，只需多次调用 dns.NewRR() 并将结果追加到 m.Answer 切片中即可。

为了避免字符串格式的潜在问题，更推荐使用结构体直接构造的方式，这样更安全清晰：

rr := &dns.A{
    Hdr: dns.RR_Header{
        Name:   "example.com.",
        Rrtype: dns.TypeA,
        Class:  dns.ClassINET,
        Ttl:    300,
    },
    A: net.ParseIP("192.0.2.1").To4(), // 确保是 IPv4 地址
}
m.Answer = append(m.Answer, rr)

为什么只监听 UDP 不够？必须补上 TCP 处理

虽然大部分简单的 DNS 查询都通过 UDP 进行，但在实际生产环境中，仅支持 UDP 是远远不够的。以下情况会强制使用 TCP 连接：

• 响应数据大小超过 512 字节（例如包含大量记录或 DNSSEC 签名时）。
• 客户端在 UDP 请求中设置了 TC（Truncated）位，明确表示期望通过 TCP 获取完整响应。
• 某些现代解析器（如 systemd-resolved）对非本地权威服务器可能默认优先使用 TCP。

一个不支持 TCP 的 DNS 服务器，可能会被部分客户端静默忽略，导致服务不可用。补上 TCP 支持非常简单，只需额外启动一个 TCP 服务器：

tcpServer := &dns.Server{Addr: ":53", Net: "tcp"}
go func() {
    log.Fatal(tcpServer.ListenAndServe())
}()

好消息是，UDP 和 TCP 服务器可以共享同一个 dns.HandleFunc 处理逻辑，无需重复注册。

本地测试时 dig 返回 SERVFAIL 或超时的排查点

写完代码后，用 dig @127.0.0.1 -p 53 example.com A 命令测试是标准操作。如果遇到问题，可以从以下几个方面排查：

• connection refused：端口被占用或程序无权限绑定。特别是在 macOS 上，systemd-resolved 或 dnsmasq 可能已经占用了 53 端口。
• SERVFAIL：这通常表示服务器在处理请求时发生了内部错误（panic）。miekg/dns 库在捕获到 panic 时会自动返回 SERVFAIL。可以在处理函数开头加上 defer 和 recover 来打印日志定位问题。
• no answer：响应报文中的 m.Answer 切片为空。检查是否正确地判断了查询类型（Qtype），例如查询 A 记录却用了 dns.TypeAAAA 进行判断。
• 有响应但 dig 不显示：用 Wireshark 抓包发现服务器确实返回了数据，但 dig 无法解析。可以检查是否设置了 m.Compress = true（DNS 压缩），不压缩有时会导致响应长度计算异常。

当然，一个真正准备上线的 DNS 服务器还需要考虑超时控制、并发连接限制、日志采样等更多问题。但对于“快速实现一个简单的 DNS 服务器”这个目标而言，理清上述四个关键点，已经能解决 95% 的常见障碍了。