Go 语言如何实现一个简单的 DNS 服务器
用 miekg/dns 库启动一个可响应 A 记录查询的 DNS 服务器
Go 语言的标准库并未内置 DNS 服务器的实现，这为开发者带来了一些挑战。幸运的是，社区提供了成熟且高效的解决方案——miekg/dns 库。该库已成为 Go 生态中处理 DNS 协议的事实标准：它采用纯 Go 编写，无需依赖 Cgo，具有轻量级、文档完善的特点，非常适合用于快速构建 DNS 调试工具、教学示例或嵌入到其他应用程序中。
安装过程非常简单，只需一条命令：
go get github.com/miekg/dns
其核心工作原理非常清晰：注册一个自定义的处理函数（dns.Handler），在指定的 UDP 或 TCP 端口上进行监听，对接收到的 dns.Msg 请求进行解析，并构造相应的 DNS 响应报文返回。以下是一个最精简的、能够响应 A 记录查询的 Go DNS 服务器示例代码：
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 系统上，绑定标准 DNS 端口 53 通常需要管理员（root）权限。为了便于开发和测试，建议使用如 :8053 这样的非特权端口，以避免权限冲突。
如何正确构造响应记录（dns.RR）避免解析失败
构造 DNS 响应记录（dns.RR）是一项需要细致操作的任务，格式上的微小偏差都可能导致客户端收到畸形响应（malformed response）甚至查询超时。在编写 Go DNS 服务器时，以下几个关键细节必须特别注意：
- 域名必须为完全合格域名（FQDN）：即域名末尾必须包含点号（
.），例如"example.com."。如果遗漏了这个点，它将被视为相对域名，客户端可能会自动为其附加搜索域，最终导致解析的目标地址与预期不符。 - 掌握
dns.NewRR()的字符串格式：其标准格式为"name. TTL class type data"。强烈建议显式指定 TTL（生存时间）值，例如300。如果不指定，在某些情况下 TTL 可能默认为 0，导致记录无法被客户端或中间解析器缓存。 - 注意 Class 字段的大小写：通常使用大写的
IN（表示 Internet）。虽然 DNS 协议规范可能不区分大小写，但部分严格遵循标准的客户端或解析器可能会拒绝接收小写的in。 - 返回多条记录的方法：如果需要为一个域名返回多个 A 记录（例如实现负载均衡），只需多次调用
dns.NewRR()函数，并将每次生成的rr依次追加到响应报文的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 的 DNS 服务器是不完整的。以下情况会强制要求或优先使用 TCP 连接进行 DNS 通信：
- 当 DNS 响应报文的数据大小超过 512 字节时（例如包含大量资源记录、大型 TXT 记录或 DNSSEC 签名时）。
- 当客户端在 UDP 请求报文中收到了 TC（Truncated，截断）标志位时，会主动发起 TCP 请求以获取完整的响应数据。
- 部分现代解析器（如 systemd-resolved）出于安全或可靠性考虑，对非本地权威服务器可能默认优先使用 TCP 协议。
一个不支持 TCP 的 DNS 服务器，可能会被上述客户端静默忽略或判定为不可用，导致服务中断。在 Go 中增加 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 命令进行本地测试是标准流程。如果遇到 SERVFAIL、超时或无响应等问题，可以按照以下步骤进行系统化排查：
connection refused：通常表示目标端口未被监听。可能是程序没有成功启动、端口被其他进程（如 macOS 上的systemd-resolved或dnsmasq）占用，或者当前用户权限不足无法绑定 53 端口。SERVFAIL：这通常表明服务器在处理请求时发生了未捕获的异常（panic）。miekg/dns库在捕获到处理函数中的 panic 时会自动返回 SERVFAIL 响应。建议在处理函数开头使用defer和recover()来捕获并打印错误日志，以便精确定位问题。no answer：表示响应报文中的m.Answer切片为空。请仔细检查代码中对查询类型（Qtype）的判断逻辑，例如确认查询的是 A 记录（dns.TypeA）而不是错误地判断为 AAAA 记录（dns.TypeAAAA）。- 有响应但
dig不显示：如果使用 Wireshark 等抓包工具确认服务器已返回数据，但dig命令无法解析显示，可以检查是否设置了m.Compress = true（DNS 压缩）。在某些情况下，不启用压缩可能导致响应长度计算异常，影响客户端解析。
当然，一个准备投入生产环境的 DNS 服务器还需要考虑更多高级特性，如请求超时控制、并发连接数限制、日志记录与采样、访问控制等。但对于“使用 Go 语言快速实现一个简单可用的 DNS 服务器”这一目标而言，透彻理解并处理好上述四个核心要点，已经能够解决开发过程中绝大多数常见问题了。
