基于Python实现迭代DNS查询（简化dig工具）的流程逻辑与AA位校验问题咨询

原有实现逻辑的本质问题 #

你当前遇到的流程卡死、AA位始终为0的问题，核心是对迭代查询流程和AA位的定义存在认知错位：

• 向1.1.1.1这类公共递归DNS发起查询时，对方本来就不会返回带AA=1的响应。从你Wireshark抓包的Flags字段也能直接看到，对应位明确标注Server is not an authority for domain，这是完全符合规范的正常表现，不是抓包异常。
• 公共递归服务器的定位是替你走完整个迭代查询链路、缓存常用结果后，把最终答案打包返回给请求方。它本身对google.com这类业务域没有权威应答权限，自然永远不会将AA位置1。
• 你之前的流程无法收敛的根本原因是：把递归服务器返回的、位于应答段的业务服务IP（也就是google.com的网站访问IP）错当成了下一跳可查询的DNS服务器地址，对着网站的业务IP反复发送DNS查询请求，自然永远等不到带有效AA位的响应。

正确的迭代DNS查询落地流程 #

真正的迭代查询从流程起点就不应该向公共递归服务器发请求，完整的自实现链路是：

• 内置全球根DNS服务器的IP列表作为初始查询节点，直接向任意一台根服务器发起目标域名的查询
• 根服务器不会返回最终的域名解析结果，而是在Authority（权威记录段）返回对应顶级域（比如.com）的DNS服务器地址列表
• 从返回的顶级域DNS列表中选取可用节点，再次发起相同的域名查询请求
• 顶级域服务器也不会返回最终解析结果，同样会在权威记录段返回目标二级域（比如google.com）的权威DNS服务器地址列表
• 向拿到的目标域权威DNS节点发起查询，这时候返回的响应报文会将AA位置1，同时在应答段返回最终的域名解析IP，整个迭代流程才算结束。

权威应答与非权威应答的准确区分 #

AA位的判断逻辑非常明确，不存在模糊空间：

• AA位仅代表返回当前响应的DNS服务器自身，是不是你所查询域名的权威管辖服务器，和答案本身的准确性、是否是最终结果没有任何关联。
• 只要你是向公共递归服务器（比如1.1.1.1、8.8.8.8这类公共DNS）发请求拿到的响应，AA位必然为0。你日常使用原生dig工具向公共递归发请求时，输出里标注的「Non-authoritative answer」，和抓包看到的AA=0是完全对应的，这是所有递归查询结果的固有特征，不是异常。
• 只有当你跳过所有递归层，直接向某个域名的官方权威DNS服务器发查询时，收到的响应才会带置1的AA位。

你抓包拿到的Flags字段完全符合RFC 1035的规范要求：1.1.1.1作为公共递归节点，已经返回了代查到的正确解析结果，同时明确标识自己不是该域的权威，整个交互过程没有任何错误。你之前的流程因为把业务IP错当成下一跳DNS节点，才会出现无限重发请求、无法收敛的问题。

内容的提问来源于stack exchange，提问作者Milad Esrafilian