概览

1

dns 开发用的少， 简单了解， 后续有遇到问题再补充说明。

从访问网站到建立连接：DNS、缓存与故障判断的整体逻辑

一次典型的网站访问流程可以抽象为三步：名字解析 → 地址选择 → 建立通信。应用在发起访问时，首先需要将域名解析为 IP 地址，随后客户端基于选定的 IP 使用 TCP 或 UDP 进行通信，DNS 只参与连接建立前的解析阶段，后续数据传输与 DNS 无关。

1. 名字解析的优先级顺序

在实际系统中，域名解析并不总是通过 DNS 网络查询完成，而是遵循如下优先级链路：

1. /etc/hosts（本地静态映射，优先级最高）
2. 应用或操作系统 DNS 缓存
3. 本地或递归 DNS 服务器
4. 权威 DNS 服务器

只要在 /etc/hosts 中命中，系统将直接使用对应的 IP 地址，不会发送任何 DNS 请求。

2. DNS 缓存的作用与位置

DNS 缓存存在于多个层次，包括应用层、操作系统以及递归 DNS 服务器。其核心作用是减少重复解析带来的延迟和网络开销。缓存是否生效以及缓存多久，由 DNS 记录中的 TTL 决定。由于缓存的存在，绝大多数访问场景中 DNS 查询只发生一次，因此用户往往“感觉不到”DNS 的存在。

3. 如何不抓包判断 DNS 失败还是连接失败

在不抓包的情况下，仍然可以通过现象快速区分问题类型：

• DNS 解析失败
  • 错误通常立即返回
  • 常见提示包括 “Could not resolve host”“Name or service not known”
  • ping 或 curl 域名直接失败
• IP / 连接失败
  • 已解析出 IP，但连接超时或被拒绝
  • 表现为明显的等待过程
  • 错误包括 “Connection timed out”“Connection refused”

一个实用判断方法是：
如果域名失败但直接访问 IP 成功，问题几乎可以确定在 DNS；如果 IP 访问本身失败，则属于网络、路由或服务层问题。

4. /etc/hosts 的角色与风险

/etc/hosts 是一种本地、静态的域名到 IP 映射机制，常用于本地开发、临时调试或绕过 DNS 异常。但由于其不会自动更新、不支持 TTL 和负载均衡，且只在单机生效，极易因“忘记清理”而引发定位困难的问题。在排查网络异常时，检查 /etc/hosts 往往是第一步。

5. 工程视角总结

从工程角度看，DNS 的职责非常单一：将名字转换为地址。一旦地址确定，后续通信完全由 IP 和传输层协议负责。理解解析顺序、缓存位置以及常见失败现象，可以在不抓包的情况下快速完成大多数网络访问问题的定位。