DNS解析核心在于“谁查、怎么查、查到哪”：用户发起递归查询，本地DNS服务器代为执行迭代链路（根→TLD→权威），最终返回A/AAAA/CNAME/MX等记录对应结果，全程依赖UDP 53端口及TTL缓存机制。
DNS记录配置和底层查询机制，核心在于理解“谁查、怎么查、查到哪”三个层面。配置记录只是静态数据，真正让域名变IP的是查询协议与递归/迭代的协同执行过程。
DNS记录类型决定查询目标
每条DNS记录对应一种解析意图，客户端或解析器会按需发起特定类型的查询：
- A记录：用于正向解析域名到IPv4地址，浏览器访问网站时默认查它；
- AAAA记录：同A记录，但返回IPv6地址，双栈网络中常与A共存；
- CNAME记录：不直接提供IP，而是把一个域名“别名”指向另一个域名，查询会自动重定向并重新发起；
-
MX记录：邮件系统专用，查询时需显式指定类型（如
dig mx example.com），普通HTTP访问不会触发； - PTR记录：仅用于反向解析（IP→域名），由DNS服务器在in-addr.arpa或ip6.arpa子域中响应，通常不被浏览器调用。
递归查询是用户侧的“一键委托”
你输入网址那一刻起，本地设备就启动了递归流程——它只发一次请求，其余全交给配置的DNS服务器（如114.114.114.114或8.8.8.8）去跑腿：
- 先查自身缓存（浏览器、系统hosts、OS DNS缓存），命中即止；
- 未命中则将请求交给本地DNS服务器，该服务器承诺“给你结果，不管多绕”；
- 这个服务器内部会走迭代链路，但它对用户完全透明；
- TTL值控制该结果能缓存多久，过期后才会重新走完整流程。
迭代查询是服务器之间的“逐级问路”
递归服务器拿到请求后，并不自己知道所有答案，而是靠迭代方式一级级“问出来”：
- 先问根服务器：“.com的管理员在哪？” → 根返回负责.com的顶级服务器地址；
- 再问.com服务器：“example.com的权威DNS是谁？” → 返回ns1.example.com等；
- 最后问权威DNS：“www.example.com的A记录是什么？” → 直接拿到IP并返回；
- 每一步响应都不带最终答案，只给“下一家找谁”，所以叫“迭代”而非“代查”。
协议层面依赖UDP+少量TCP
DNS查询默认走UDP 53端口，因大多数响应小于512字节，轻量高效：
- 若响应超长（如含大量记录或启用EDNS0扩展），服务器会设TC位，客户端自动降级为TCP重试；
- TCP也用于区域传输（AXFR/IXFR）和某些高安全场景（如DNSSEC验证）；
- 现代DNS还支持HTTPS（DoH）和TLS（DoT）封装，本质是把DNS报文包进加密隧道，底层仍遵循递归+迭代逻辑。
