DNS是互联网的基础设施之一，每一次浏览器访问网站，背后都离不开DNS的协作。但很多人在学习和排查DNS问题时，会发现服务器有递归DNS和权威DNS之分，两者名字相似，职责却完全不同。如果把整个DNS体系比作一个查询系统，递归DNS更像前台接待员，负责帮你跑腿问到底；权威DNS则是真正的档案管理员，掌握着域名记录的最终答案。理解这两者的区别，是掌握DNS原理和排查解析故障的关键一步。
一、从一次完整的域名解析流程看两者的分工
假设你在浏览器中访问 www.ippipp.com，而本地没有任何缓存，整个解析过程大致是这样的：操作系统先向配置的递归DNS服务器（比如运营商分配的DNS或公共DNS）发起查询。注意，此时你的电脑并不直接去问权威DNS，而是把这个麻烦事交给了递归服务器。
递归DNS收到请求后，如果自己的缓存中没有记录，就会代替客户端进行迭代查询。它先问根服务器，根服务器告诉他负责.com顶级域的服务器地址；接着它去问顶级域服务器，顶级域服务器返回ippipp.com的权威DNS地址；最后递归DNS直接询问权威DNS，权威DNS返回www这台主机的A记录。递归DNS拿到结果后，一方面返回给客户端，另一方面将结果缓存一段时间。
从这个流程可以看出一个关键区别：递归DNS是替客户端跑完全程的角色，它自己也会发起查询请求，属于请求的发起方兼中间人；而权威DNS是被动应答的角色，只回答自己负责区域内的记录，绝不主动查别人。一个形象的说法是：递归DNS是代理人，权威DNS是资料库。
二、两者在职责、行为和部署上的核心区别
除了查询方式不同，两者在多个维度上都有明显差异。首先是数据来源：权威DNS的数据来自域名所有者配置的区域文件（Zone File），记录什么就是什么，它给出的回答是最终答案；递归DNS的数据来自缓存和其他服务器的应答，属于二道贩子，答案可能因缓存而过期。
其次是应答行为。权威DNS如果被问到不负责的域名，会返回REFUSED；如果被问到负责区域内不存在的记录，会返回NXDOMAIN。而递归DNS对任何域名都要尝试解析到底（除非策略限制），它需要处理缓存、转发、重试等复杂逻辑。这也决定了性能压力的不同：权威DNS面对的是全网递归服务器的查询，强调高可用和抗攻击；递归DNS面对的是自己的用户，强调缓存命中率和响应速度。
| 对比维度 | 递归DNS | 权威DNS |
|---|---|---|
| 服务对象 | 终端用户或局域网客户端 | 其他DNS服务器（主要是递归DNS） |
| 数据来源 | 缓存与迭代查询结果 | 本地区域文件配置 |
| 是否缓存 | 缓存结果，受TTL控制 | 一般不缓存，直接返回权威答案 |
| 典型软件场景 | 运行商DNS、企业内网DNS、公共DNS | 域名注册商DNS、自建权威服务 |
| 安全关注点 | 缓存投毒、DNS劫持 | 区域传送泄露、DDoS攻击 |
常见的BIND、PowerDNS、CoreDNS等软件其实既能做递归也能做权威，但在生产环境中通常建议分开部署。比如用BIND的话，可以通过配置明确划分角色，避免一台服务器既对外提供递归又提供权威服务带来的风险。
# 判断一个DNS服务器是递归还是权威，可用dig命令 dig @8.8.8.8 www.ippipp.com # 关注应答中的flags字段 # 出现 ra 表示支持递归（recursion available） # aa 表示权威应答（authoritative answer） dig @ns1.ippipp.com ippipp.com SOA +norecurse
上面命令输出中的flags是判断角色的重要依据。如果应答里带有aa标志，说明这个答案直接来自权威服务器；如果带有ra，说明该服务器愿意为你的客户端做递归查询。
三、缓存、TTL与两者的联系
递归DNS与权威DNS并非孤立存在，缓存机制正是连接两者的桥梁。权威DNS在每条记录上设置TTL（生存时间），递归DNS根据这个值决定缓存多久。TTL设置得长，递归侧缓存命中率高、权威侧压力小，但域名变更后生效慢；TTL设置得短则相反。这也是为什么在计划更换服务器IP前，有经验的运维会提前把TTL调低到60秒左右，等变更完成后再调回去。
两者的联系还体现在级联信任上。递归DNS之所以敢把结果交给用户，是因为它相信权威DNS给出的答案；而权威DNS的应答之所以能被全网认可，依赖的是从根服务器开始的一整套委派链条。如果某个环节的委派配置出错，比如域名注册商处的NS记录指向了错误的权威服务器，那么无论递归DNS多努力，也拿不到正确的答案。排查这类问题时要顺着委派链一层层检查。
# 查看委派链条：先查根，再查顶级域，最后查权威 dig com NS dig ippipp.com NS +trace # 查询记录的TTL值 dig www.ippipp.com A +noall +answer # 输出第二列即为TTL，单位秒，例如： # www.ippipp.com. 300 IN A 93.184.216.34
另一个容易踩的坑是：修改了权威DNS上的记录，却发现部分地区很久不生效。这往往不是权威服务器的问题，而是递归DNS的缓存还没过期。此时可以通过刷新本地缓存或等待TTL到期解决，而不是反复在权威侧改来改去。
四、实际部署与故障排查建议
在自建DNS的场景下，建议递归和权威严格分离。权威服务器只对负责的区域应答，关闭递归功能，防止被滥用做放大攻击；递归服务器只对自己的内网用户开放，不对公网提供递归，否则很容易被扫描利用。以BIND为例，可以在配置中显式声明角色。
# 递归服务器配置：只允许内网递归
options {
recursion yes;
allow-recursion { 192.168.0.0/16; };
forwarders { 223.5.5.5; 114.114.114.114; };
};
# 权威服务器配置：关闭递归，只应答本地区域
options {
recursion no;
allow-query { any; };
};
zone "ippipp.com" {
type master;
file "/etc/named/zones/ippipp.com.zone";
};
排查解析故障时，分清角色能让定位事半功倍。如果用 dig @8.8.8.8 查询正常，但本地运营商DNS查询异常，问题多半出在递归侧的缓存或策略；如果所有公共DNS都返回错误结果，则应检查权威侧的记录配置和委派状态。可以用在线的委派检查工具核对NS记录是否与注册商处一致。
总结来说，递归DNS解决的是用户怎么方便地拿到答案，权威DNS解决的是答案本身从哪里来。前者强调代理与缓存，后者强调数据与准确。两者一问一答、相互配合，才构成了我们每天使用却几乎感觉不到存在的域名解析体系。搞清楚这条链路，无论是配置域名、切换服务商还是排查解析故障，都会清晰很多。