前端看后端 15:什么是 DNS?

专栏第十五篇,网络与协议篇第八章。上一篇我们聊了 CORS,搞懂了浏览器为什么要"扣押"你的响应。但在那之前,浏览器还得先找到服务器在哪------你输入 google.com,它怎么知道该连哪台机器?毕竟计算机只认 IP 地址,可没人会背 142.250.72.206 这种数字。这中间的翻译官,就是今天的主角:DNS(域名系统)。它是整个网页访问之旅的"第一块多米诺骨牌",也是面试高频考点。


一、DNS 是什么?------互联网的电话簿

DNS = Domain Name System(域名系统)

一句话:DNS 是互联网的"电话簿" ------把人类可读的域名(google.com)翻译成机器可读的 IP 地址(142.250.72.206)。

为什么需要它?

计算机在网络上通信,靠的是 IP 地址 (如 192.168.1.1 或 IPv6 的 2001:db8::1)。但人类记数字的能力实在堪忧:

人类喜欢 机器需要
google.com 142.250.72.206
baidu.com 110.242.68.66
bilibili.com 119.3.70.xxx

DNS 就是解决这个"人机语言不通"问题的翻译官。

💡 类比:DNS 就像手机通讯录。你点一下"妈妈"就能拨出去,不用背 +86 138xxxx。通讯录帮你把名字翻译成号码,DNS 帮你把域名翻译成 IP。


二、DNS 解析的完整流程(面试必考)

当你在浏览器输入 https://www.google.com 并回车,到拿到 IP 地址,中间经历了 8 个步骤。这是面试最常考的内容,建议截图保存。

text 复制代码
1. 浏览器缓存 → 2. 系统缓存 → 3. 本机 hosts 文件
                                        ↓
4. 本地 DNS 服务器(LDNS,通常是你的路由器或运营商)
                                        ↓
5. 根 DNS 服务器(Root) → 告诉你 .com 在哪
                                        ↓
6. 顶级域 DNS(TLD,.com 服务器) → 告诉你 google.com 的权威 DNS 在哪
                                        ↓
7. 权威 DNS 服务器(Authoritative) → 返回 www.google.com 的 IP
                                        ↓
8. 浏览器拿到 IP,开始 TCP 握手 + TLS + HTTP 请求

逐步拆解

1️⃣ 浏览器缓存

浏览器会缓存 DNS 结果(Chrome 默认 60 秒到几分钟不等)。先查自己有没有,有就直接用。

2️⃣ 系统缓存

浏览器没命中,就问操作系统。Windows 调用 gethostbyname,Linux/Mac 读取 /etc/resolv.conf 里配置的 DNS 服务器。操作系统自己也有一层缓存。

3️⃣ hosts 文件

系统缓存也没有,查 hosts 文件:

  • Windows:C:\Windows\System32\drivers\etc\hosts
  • Linux/Mac:/etc/hosts

这是程序员最常用的"本地 DNS 劫持"手段:

text 复制代码
# 开发环境常用
127.0.0.1       localhost
192.168.1.100   api.dev.com

4️⃣ 本地 DNS 服务器(LDNS)

hosts 也没命中,请求才真正发出去,送到本地 DNS 服务器 (通常由你的 ISP 提供,如电信的 114.114.114.114,或你手动配的 Google 8.8.8.8)。LDNS 自己也有缓存,如果有就直接返回------大部分情况下,DNS 查询在这一步就结束了。

5️⃣ 根 DNS 服务器

LDNS 没缓存,就去找根服务器 。全球只有 13 组根服务器(编号 A-M)。根服务器不直接解析域名,它只告诉你:".com 域的 TLD 服务器在这。"

6️⃣ 顶级域 DNS(TLD)

LDNS 拿着根服务器的指引,去找 .com 的 TLD 服务器。TLD 查了查,告诉你:"google.com 的权威 DNS 是 ns1.google.com,你去找它。"

7️⃣ 权威 DNS 服务器

LDNS 终于找到 google.com 的权威 DNS,这里才真正返回 www.google.com 的 IP 地址(142.250.72.206)。权威 DNS 是域名所有者自己配置的,你在阿里云/Cloudflare 买的域名,那里配的记录就存在权威 DNS 上。

8️⃣ 返回并缓存

LDNS 把结果返回给你的电脑,并按 TTL 缓存起来。浏览器也开始缓存,接下来就可以进入 TCP 握手、TLS 握手、发 HTTP 请求了。

⏱️ 耗时 :整个过程通常在 几十毫秒到几百毫秒。如果 LDNS 有缓存,甚至 < 1ms,你根本感知不到。


三、DNS 记录类型(重点)

DNS 不只是存 A 记录(域名→IP),它有十几种记录类型。作为工程师,这几种必须认识:

记录类型 作用 例子
A 域名 → IPv4 地址 google.com → 142.250.72.206
AAAA 域名 → IPv6 地址 google.com → 2607:f8b0:4005:...
CNAME 域名别名 → 另一个域名 www.google.com → www.l.google.com
MX 邮件服务器 google.com → smtp.google.com
NS 指定该域名的权威 DNS google.com → ns1.google.com
TXT 文本记录(SPF、域名验证) google.com → "v=spf1 include:_spf.google.com ~all"
PTR IP → 域名(反向解析) 8.8.8.8 → dns.google
SOA 区域起始授权记录 包含主 DNS、管理员邮箱、刷新时间等
SRV 服务定位记录 _xmpp-server._tcp.gmail.com
CAA 指定哪些 CA 可以签发证书 google.com → 0 issue "pki.goog"

最常用的三类

1. A 记录(Address)

最基础的映射:域名 → IPv4。配网站、配接口,第一个要加的就是 A 记录。

2. CNAME(Canonical Name)

把一个域名指向另一个域名(注意:不能直接指向 IP)。

text 复制代码
images.google.com  CNAME  www.l.google.com
www.l.google.com   A      142.250.72.206

好处 :当 www.l.google.com 的 IP 变了,images.google.com 自动跟着变,不用改两条记录。CDN 厂商最喜欢让你 CNAME 到他们的域名,就是这个原因。

3. MX 记录(Mail Exchange)

指定邮件服务器。发邮件到 alice@gmail.com 时,发件方 DNS 查 gmail.com 的 MX 记录,找到 Gmail 的邮件服务器,然后投递。MX 记录还能带优先级(数字越小越高)。


四、DNS 的应用场景(重点)

DNS 远不止"把域名变 IP"这么简单,它在现代架构中扮演着核心调度角色

1️⃣ 网站访问(基础场景)

最经典的用法。用户访问 taobao.com,DNS 返回淘宝服务器的 IP,浏览器才能建立连接。

2️⃣ CDN 调度(智能解析)

CDN 厂商(Cloudflare、阿里云 CDN)通过 DNS 实现就近接入

text 复制代码
用户在北京 → DNS 返回 北京节点的 IP
用户在上海 → DNS 返回 上海节点的 IP
用户在国外 → DNS 返回 美国节点的 IP

这就是所谓的 GeoDNS,根据用户的地理位置返回最近的 CDN 边缘节点 IP。

3️⃣ 负载均衡(DNS Round Robin)

一个域名对应多个 IP,DNS 轮询返回:

text 复制代码
api.example.com  A  10.0.0.1
api.example.com  A  10.0.0.2
api.example.com  A  10.0.0.3

每次 DNS 查询,DNS 服务器按顺序返回不同的 IP,实现简单的负载均衡。

缺点也很明显:DNS 缓存会导致流量分布不均;一台机器挂了,DNS 还会继续返回它的 IP。所以 DNS 轮询通常只作为第一层负载均衡,后面还要配合 Nginx/LVS 等。

4️⃣ 服务发现(微服务)

微服务架构中,服务实例动态变化,IP 随时在变。DNS 可以作为服务发现机制:

text 复制代码
user-service.default.svc.cluster.local → 10.244.1.5
user-service.default.svc.cluster.local → 10.244.2.7

Kubernetes 就用 CoreDNS 做服务发现,Service 名 → ClusterIP 的解析全靠它。

5️⃣ 高可用与故障转移

通过降低 TTL,当主服务器宕机时,快速修改 DNS 记录指向备用服务器。但因为各级缓存的存在,切换不是秒级的,通常有几分钟延迟。

6️⃣ 邮件系统

MX 记录指定邮件服务器,SPF/DKIM/DMARC 通过 TXT 记录验证邮件合法性,防止伪造和钓鱼。

7️⃣ 内网服务命名

公司内部用 DNS 代替记 IP:

text 复制代码
mysql.internal   → 10.0.0.100
redis.internal   → 10.0.0.101
jenkins.internal → 10.0.0.102

没人愿意背 IP,内网 DNS 是提升幸福感的基础设施。


五、DNS 的 TTL(生存时间)

每条 DNS 记录都有一个 TTL 值(单位:秒),告诉缓存服务器"这个结果多久内有效"。

text 复制代码
www.example.com.  300  IN  A  93.184.216.34

TTL=300 秒(5 分钟)意味着:LDNS 缓存 5 分钟,期间所有对这个域名的查询都直接返回这个 IP,不再去问权威 DNS。

TTL 的权衡

  • TTL 短(如 60 秒):故障转移快,但 LDNS 查询频率高,解析慢,权威 DNS 压力大。
  • TTL 长(如 86400 秒 = 1 天):解析快,缓存命中率高,但 IP 变更后要等缓存过期,切换慢。

最佳实践:正常情况下 TTL 设较长(如 3600 秒 = 1 小时);变更前临时调短(如 60 秒);变更完成后再调长。


六、DNS 的安全与隐私

DNS 从设计之初就没考虑安全,所以这些年补了不少补丁。

1. DNS 污染(DNS Spoofing)

攻击者伪造 DNS 响应,让你访问假网站(比如把 taobao.com 指到钓鱼站点)。

防御DNSSEC(DNS Security Extensions)给 DNS 记录加数字签名,客户端可以验证响应是否被篡改。

2. DNS 劫持

运营商或中间人篡改 DNS 查询结果,强行跳转到广告页。你有没有过访问一个网站却跳到运营商导航页的经历?那就是 DNS 劫持。

防御DoH (DNS over HTTPS)或 DoT(DNS over TLS),把 DNS 查询也加密,中间人就看不到也改不了了。

3. 隐私泄露

传统 DNS 查询是明文的,ISP(或任何网络中间人)能看到你访问了哪些网站。

解决方案

  • DoH:DNS over HTTPS,走 443 端口,和普通 HTTPS 流量混在一起。Firefox、Chrome 都支持。
  • DoT:DNS over TLS,走 853 端口。
  • DNS over QUIC:新兴方案,基于 QUIC 协议,性能更好。

七、公共 DNS 服务

服务商 IPv4 特点
Google Public DNS 8.8.8.8 / 8.8.4.4 全球最快之一
Cloudflare 1.1.1.1 注重隐私,支持 DoH/DoT
国内 114 114.114.114.114 国内速度快
阿里 DNS 223.5.5.5 / 223.6.6.6 国内稳定
OpenDNS 208.67.222.222 有内容过滤

开发调试常用8.8.8.8114.114.114.114


八、常用命令与工具

排查 DNS 问题时,这些命令是你的好帮手。

1. nslookup(简单查询,跨平台)

bash 复制代码
nslookup google.com
nslookup -type=MX google.com       # 查 MX 记录

2. dig(详细查询,Linux/Mac)

bash 复制代码
dig google.com                     # 查 A 记录
dig +trace google.com              # 追踪完整解析链(根→TLD→权威)
dig @8.8.8.8 google.com            # 指定 DNS 服务器
dig -t AAAA google.com             # 查 IPv6

dig +trace 能让你亲眼看到解析是怎么一步步从根服务器走到权威 DNS 的,强烈建议自己试一次。

3. host

bash 复制代码
host google.com
host -t MX google.com

4. ping(间接测试)

bash 复制代码
ping google.com   # 先触发 DNS 解析,再发 ICMP 包

如果 ping 一个域名能通但 curl 不通,至少说明 DNS 解析没问题。

5. 在线工具


九、串联整个通信系列

到这里,我们终于可以把前面所有知识串成一条完整的"网页访问之旅"了:

text 复制代码
1. 用户在浏览器输入 https://www.google.com
   ↓
2. DNS 解析(本篇主角)
   - 浏览器缓存 → 系统缓存 → hosts → LDNS → 根 → TLD → 权威 DNS
   - 拿到 IP: 142.250.72.206
   ↓
3. TCP 三次握手(第 08 篇 TCP/IP)
   ↓
4. TLS 握手(HTTPS 加密协商)
   ↓
5. HTTP 请求发送(第 09 篇 HTTP / 第 10 篇 RESTful)
   - 如果是跨域,还会有 CORS 预检(第 14 篇 CORS)
   ↓
6. 服务器处理
   - 检查 Cookie/Session 验证身份(第 13 篇)
   - 可能调用内部 gRPC 服务(第 11 篇)
   - 或查询数据库、缓存
   ↓
7. HTTP 响应返回
   ↓
8. 浏览器渲染页面
   - 如果页面有 WebSocket,会升级连接(第 12 篇)
   - 如果页面有 API 调用,又会回到第 2 步

DNS 是整个过程的"第一块多米诺骨牌"------它不倒,后面全玩完。


十、总结

  • DNS 是什么:互联网的电话簿,域名 ↔ IP 的翻译系统。
  • 解析流程:浏览器缓存 → 系统缓存 → hosts → LDNS → 根 → TLD → 权威 DNS(8 步,面试必背)。
  • 核心记录:A(IPv4)、AAAA(IPv6)、CNAME(别名)、MX(邮件)、NS(权威)、TXT(文本验证)。
  • 应用场景:网站访问、CDN 智能调度、负载均衡、K8s 服务发现、邮件系统、高可用切换。
  • TTL:平衡解析速度与变更灵活性的关键参数,变更前调短、变更后调长。
  • 安全:DNSSEC 防污染,DoH/DoT 防劫持和保护隐私。
  • 调试工具dignslookuphostping,以及 whatsmydns.net

写在最后

DNS 是那种"日用而不知"的基础设施------你每天上网几百次,每次都要用它,但很少有人能完整说清解析流程。理解它最大的价值,不只是应付面试,而是当你遇到这些问题时不再抓瞎:

  • 为什么改了 DNS 记录,有的用户立刻生效、有的要等半天?(TTL + 各级缓存)
  • 为什么配了 CDN 还是慢?(GeoDNS 调度错了节点)
  • 为什么域名能 ping 通但浏览器打不开?(可能是 hosts 被改了,或 DNS 被劫持)
  • 为什么 Kubernetes 里 Service 名能直接当域名用?(CoreDNS 在做服务发现)

下一篇,我们来聊一个你天天在配、却未必真正理解的概念:什么是端口?一台服务器只有一个 IP,为什么能同时跑网站、数据库、邮件那么多服务?80、443、3306、8080 这些数字背后到底是什么?端口和进程又是怎么对应起来的? 敬请期待。

如果这个系列对你有帮助,欢迎点赞、关注、收藏三连,我们下篇见 👋

相关推荐
echoVic1 小时前
会话选择器不是列表:Orca 如何守住切换边界
agent·ai编程
文艺理科生1 小时前
LangChain.js-v1-记忆管理最佳实践
前端·javascript·后端
echoVic1 小时前
Agent 架构里最容易混淆的四种责任
agent·ai编程
子兮曰1 小时前
Elysia vs Hono 完整性能对比:Bun 专属优化还是跨平台通用,2026 实测数据给出的答案
前端·后端·typescript
小满zs1 小时前
Go语言第七章(Map)
后端·go
To_OC1 小时前
从一个颜色选择器说起:我终于整明白了 React+TS 里的 model 与 api 分层
前端·react.js·typescript
赵大仁1 小时前
浏览器端 RAG:Transformers.js + WebGPU 本地检索入门
前端·ai·react·webgpu·rag
Undoom2 小时前
我用豆包Seed-Evolving搞了个高中物理可视化工具,结果被自己的高中物理水平整破防了
后端
木叶丸2 小时前
从 Loop 到 Graph:AI 智能体协作系统工程指南
前端·后端·架构