需手动按 rfc 1035 构造 dns 查询包：初始化 12 字节头部→域名 label-wise 编码（长度字节+标签+0x00）→写 qtype/qclass（uint16 大端）→udp 发送（≤512 字节）。
怎么用 Go 手动构造 DNS 查询包
Go 标准库的 net.LookupHost 等函数不暴露底层包结构，真要手动发 DNS 查询（比如测权威服务器、绕过系统 resolver、写探测工具），就得自己拼 UDP 包。核心是按 RFC 1035 组织 12 字节头部 + 问题段，不能靠第三方库“自动补全”——否则就不是“手动构建”了。
关键步骤：初始化 dnsHeader 结构体 → 序列化域名（label-wise，以长度字节开头，结尾置 0）→ 拼上 QTYPE（如 A 是 1）和 QCLASS（通常 IN 是 1）→ 整体丢给 net.Conn.Write()。
- 域名编码别直接用
strings.Split("example.com", ".")后逐个写长度：空子域（如..com）会导致解析失败；正确做法是用len([]byte(label))做前缀，且最后补一个0x00 -
QTYPE和QCLASS必须是 uint16，小端序（binary.BigEndian.PutUint16），不是主机序 - UDP 包总长别超 512 字节（传统限制），否则可能被截断；EDNS0 可扩展，但手动加 OPT RR 复杂度陡增，初学者先守 512
为什么 DNS 查询发出去没响应或报错 “read: i/o timeout”
手动发包后收不到回复，大概率不是网络不通，而是包本身被远端拒绝或静默丢弃。DNS 服务器对格式错误极其敏感，连头部的 RD（recursion desired）位设错，某些权威服务器就直接 ignore。
-
Header.RD设为 0：发给根/顶级域服务器时必须关递归，否则它们不处理；但发给 8.8.8.8 这类递归服务器时得开（1），否则返回NOERROR但Answer RRs = 0 - 源端口必须绑定（
net.ListenUDP），不能只用net.DialUDP：后者可能复用端口，导致回复包被内核丢给旧连接 - 查
AAAA记录却填了QTYPE=1（A）：服务器不会自动转译，直接返回NOERROR+ 空应答，看着像超时
Go 里怎么安全读 DNS 响应包并解析头部字段
收到 UDP 数据后，不能直接用 binary.Read 解析整个包——DNS 响应长度可变，且资源记录（RR）数量未知。必须先解头部 12 字节，再根据 Answer RRs 字段数，循环解析后续 RR，否则会越界或错位。
立即学习“go语言免费学习笔记（深入）”；
- 用
binary.BigEndian.Uint16读Header.ID、Header.Bits等，别手写位移：Go 的uint16是大端，和 DNS 协议一致 -
Header.Bits是 16 位打包字段（含 QR、OPCODE、AA、TC、RD、RA、Z、RCODE），推荐用掩码提取：(bits & 0x8000) != 0判断是否响应（QR），而不是bits >> 15 == 1——后者在某些平台行为不一致 - 响应中的域名压缩指针（
0xc0开头）必须递归解压，不能假设都是完整 label；标准库net.DNSName不处理压缩，得自己写跳转逻辑
要不要用 gopacket 或 miekg/dns 库替代手写
如果你目标是快速实现功能而非理解协议细节，用 miekg/dns 更稳：它把包构造/解析封装成结构体方法，Msg.SetQuestion 自动处理域名编码、头部位设置、RR 计数，还内置压缩解压。但代价是失去对每个字节的控制权，调试协议交互时反而更难定位问题。
- 手写适合：协议学习、fuzzing、定制化探测（如故意发 TC=1 包测截断行为）、嵌入式环境裁剪依赖
-
miekg/dns适合：生产级 DNS 工具（如 dig 替代）、需支持 TSIG/EDNS/AXFR 的场景；注意它默认启用 EDNS，发到老设备可能被拒 -
gopacket过重：它面向链路层，DNS 只是应用层 payload，用它等于拿挖掘机挖蚯蚓——能挖，但初始化、过滤、回调机制全是冗余
真正卡住人的永远不是“怎么拼出第一个包”，而是域名压缩、位字段语义、UDP 分片边界这些 RFC 里轻描淡写的细节。写两遍 packDomain 函数，比读十遍 RFC 记得牢。
