因为getaddrinfo是阻塞式系统调用，内核层面不可中断，且默认AI_ADDRCONFIG在IPv6不可用时跳过AAAA记录；实操应避免线程池封装，改用libuv或Boost.Asio的async_resolve实现可取消、带超时的异步DNS。
为什么不能直接用 getaddrinfo 做异步DNS查询
因为 getaddrinfo 是阻塞式系统调用，哪怕你把它丢进线程池，也绕不开内核层面的同步等待。glibc 的实现会读取 /etc/resolv.conf、发 UDP 包、等超时重试，全程不可中断。更麻烦的是，它默认启用 AI_ADDRCONFIG，可能在 IPv6 不可用时意外跳过 AAAA 记录——这在容器或云环境里很常见。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 别封装
getaddrinfo+std::thread，线程开销大且无法取消 - 若必须用 libc，至少设
AI_NUMERICHOST避免 DNS 查询（仅用于已知 IP） - 真正异步需换底层：要么用
libuv的uv_getaddrinfo，要么用Boost.Asio的resolver.async_resolve
用 Boost.Asio 实现可取消的并发 DNS 查询
Boost.Asio 的 resolver 封装了平台原生异步 DNS（Linux 用 getaddrinfo_a 或自建线程池，macOS 用 dns_service_create），支持 cancel、timeout、多记录类型。关键点不是“怎么写”，而是“怎么避免常见误用”：
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 构造
boost::asio::ip::tcp::resolver时传入io_context，别复用全局单例——不同线程或生命周期的请求要隔离 - 查 A 和 AAAA 记录必须分开调用
async_resolve，传boost::asio::ip::tcp::resolver::query("example.com", "http", boost::asio::ip::tcp::resolver::query::canonical_name)；混用udp::resolver会失败 - 回调里检查
ec：若为boost::asio::error::operation_aborted，说明被 cancel；若为boost::asio::error::host_not_found，不等于失败——可能是 NXDOMAIN，需结合ec.value()判断
高性能场景下为何要绕过 libc 的 DNS 缓存
glibc 的 __res_maybe_init 会缓存 resolv.conf 解析结果和部分 DNS 响应，但它是进程级静态变量，多线程下有锁竞争；更严重的是，它不遵守 TTL，缓存过期后仍返回旧地址。高并发服务（如反向代理）若依赖它，可能持续将流量打到已下线的节点。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 禁用 glibc 缓存：编译时加
-DRESOLV_USE_EDNS0并运行时设export RES_OPTIONS="edns0"，但这只影响 EDNS 支持，不解决 TTL 问题 - 生产环境推荐自建缓存：用
LRU cache存std::string → std::vector<:asio::ip::address></:asio::ip::address>，key 含记录类型（A/AAAA）、TTL 秒级时间戳，查前先校验过期 - 注意
boost::asio::ip::address没有比较 operator==，用to_string()做 key 要小心 IPv4 映射格式（如::ffff:192.0.2.1）
如何处理 DNSSEC 验证失败和 SERVFAIL
多数 C++ DNS 客户端（包括 Boost.Asio）默认不验证 DNSSEC。遇到 SERVFAIL 时，libc 可能静默重试或返回空结果，而真实原因是签名无效或链断裂。业务若涉及金融或敏感域名，必须显式控制验证行为。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- Boost.Asio 不支持 DNSSEC 验证，得换
c-ares：用ares_set_servers_ports_csv配置可信 DNS（如1.1.1.1），再调ares_query发AD标志位请求 -
c-ares返回ARES_EBADRESP时，检查响应包里的AD位——需手动解析 DNS 报文，ares_parse_a_reply不暴露该字段，得用ares_parse_dns_reply+ 位运算 - 遇到
SERVFAIL别立刻重试：先确认是否是上游 DNS 不支持 EDNS（常见于老旧 ISP），可降级用 TCP 重发，设置ARES_FLAG_USEVC
异步 DNS 的坑不在代码量，而在对协议细节的容忍度——比如一个没设 timeout 的 async_resolve，可能让整个 io_context 卡住数分钟；又比如把 std::shared_ptr 捕获进 lambda 却忘了延长生命周期，导致 resolver 回调访问已释放内存。这些没法靠文档发现，只能靠压测和抓包。
