APE
文章标签归档关于

© 2026 APE.PUB

2026-07-09· 12 分钟

DNS

DNS

DNS 与域名系统笔记

1. 域名和 IP 是如何对应的

域名和 IP 的对应通过 DNS(Domain Name System,域名系统) 完成。DNS 是互联网的"电话簿",把人类可读的域名翻译成机器用的 IP 地址。

基本解析流程(以 www.example.com 为例)

1. 浏览器缓存 — 先查本地浏览器

2. 操作系统缓存 / hosts 文件 — /etc/hosts 优先级最高

3. 本地 DNS 解析器(运营商或 8.8.8.8、1.1.1.1)— 发起递归查询

4. 根域名服务器(.)— 返回负责 .com 的服务器地址

5. 顶级域名服务器(.com)— 返回负责 example.com 的权威服务器

6. 权威域名服务器(example.com)— 返回 www.example.com 对应的 IP

7. 结果层层缓存回来,浏览器拿到 IP 后发起 TCP 连接

关键记录类型

| 记录 | 作用 |

|------|------|

| A | 域名 → IPv4 |

| AAAA | 域名 → IPv6 |

| CNAME | 域名 → 另一个域名(别名) |

| NS | 指定该域名的权威服务器 |

| MX | 邮件服务器 |

补充点

  • 一对多:一个域名可对应多个 IP(负载均衡、CDN)
  • 多对一:多个域名指向同一 IP(虚拟主机通过 HTTP Host 头区分)
  • TTL:控制每条记录缓存多久
  • 动手查:dig www.example.com 或 nslookup

2. DNS 映射数据的来源

DNS 数据不集中存储,是分布式分层管理——每层只管自己那块,靠"授权(delegation)"链条串起来。

数据源头:域名注册

1. 你注册域名 — 通过注册商(Namecheap、阿里云、GoDaddy)向注册局申请

2. 注册商写入注册局数据库 — .com 由 Verisign 运营,域名的 NS 记录存在 Verisign 的 TLD 数据库

3. 在权威 DNS 服务器上配置具体记录 — A、CNAME、MX 由域名所有者自己填

真正的"数据源"是域名持有者。

分层授权链

根服务器(.)
  └── 知道 .com 的 NS ──► Verisign 的服务器
        └── 知道 example.com 的 NS ──► 你的 DNS 服务商
              └── 知道 www.example.com = 1.2.3.4 ──► 你填的记录
  • 根服务器数据:ICANN/IANA 维护,13 组根服务器(Anycast 部署上千实例)
  • TLD 服务器数据:各顶级域运营方(.com → Verisign,.cn → CNNIC)
  • 权威服务器数据:域名所有者通过 DNS 服务商(Cloudflare、Route53、DNSPod)配置

递归解析器(如 8.8.8.8)

自己不存原始数据,只是:

  • 内置根服务器地址(root hints)
  • 缓存查过的结果
  • 遇到没缓存的域名沿授权链去问

3. 每次访问域名都要问根服务器吗

不会,绝大多数情况根服务器一次都不用访问。靠多层缓存。

缓存层级(从近到远)

1. 浏览器 DNS 缓存

2. 操作系统缓存

3. hosts 文件

4. 本地路由器缓存

5. 递归 DNS 服务器缓存(最关键)

6. 都没命中,才真的问根服务器

递归缓存有多强

.com 的 NS 记录、根服务器地址几乎永远在缓存里,TTL 通常 1~2 天。

真实流程:

你查 www.example.com
  ↓
8.8.8.8 缓存里没有 www.example.com
  ↓
但 .com 的 NS 在缓存里 ✓(跳过根 + TLD)
  ↓
直接问 example.com 的权威服务器

TTL

  • 根 / TLD 的 NS 记录:1~2 天
  • 普通网站 A 记录:几分钟到几小时
  • CDN 的 A 记录:几十秒(方便切换)

动手验证

dig www.google.com          # 第一次
dig www.google.com          # 第二次,Query time ≈ 0 ms
dig www.google.com +trace   # 从根开始的完整流程

4. 公共 DNS 造假会绕过根服务器吗

能,完全可以。 这就是 DNS 劫持 / DNS 污染。

为什么能造假

DNS 协议(1987 年设计)默认没有身份验证:

  • 递归返回的响应,客户端无法判断真伪
  • 根服务器只告诉"去问谁",不检查最终答案

现实中的例子

1. 运营商劫持 — NXDOMAIN 广告页

2. GFW 的 DNS 污染 — UDP 53 响应被伪造抢答

3. 恶意 Wi-Fi — DHCP 下发假 DNS

4. 路由器被入侵

5. 恶意软件 — 改 /etc/hosts

防御手段

| 手段 | 防什么 |

|------|--------|

| DNSSEC | 权威 → 递归的伪造(签名验证) |

| DoT (853) | 递归 → 你的中间人(加密传输) |

| DoH (443) | 同上,混在 HTTPS 里 |

| 换可信递归(1.1.1.1 / 9.9.9.9) | 运营商劫持 |

| HTTPS 证书 | 劫持到假 IP 时假服务器拿不出合法证书 |

信任链断点

根 → TLD → 权威(都可信)
    ↓
[递归服务器] ← 断点 1:可以造假
    ↓
[网络传输]   ← 断点 2:可以中间人
    ↓
你的电脑

DNSSEC 修断点 1,DoH/DoT 修断点 2。


5. 域名服务商改解析等于绕过根服务器

是的,而且这是合法权限内的操作。 解析权其实握在 DNS 服务商手里。

为什么根服务器管不着

根 / TLD 只存 NS 记录,不存 A 记录:

  • 改 A → 不惊动根/TLD,缓存过期后全世界自动跟新
  • 改 NS(换服务商)→ 才需要注册局/注册商配合

真实事件

1. 域名被服务商"没收" — 美国 ICE 没收盗版站,改 A 记录到警告页

2. 服务商账号被黑 — 2018 年 MyEtherWallet 被 DNS 劫持盗走数百万美元

3. 注册商层面被夺(domain hijacking)— 改 NS,整个解析权转移

防御措施

1. 双因素认证

2. 注册局锁(Registry Lock)

3. DNSSEC

4. CAA 记录 — 限制哪些 CA 能签证书

5. DNS 监控

6. 多服务商冗余

完整信任链

你 → 递归 → 权威(DNS 服务商)→ 注册商 → 注册局 → ICANN/IANA

域名从来不是你的,是租的。


6. NS 记录是什么

NS = Name Server 记录,作用是告诉查询者:"这个域名的权威解析在哪台服务器上"。

不告诉 IP,只告诉"去问谁"——DNS 授权链的"路标"。

例子

问根:.com 归谁管?        → NS: a.gtld-servers.net
问 Verisign:example.com? → NS: ns1.cloudflare.com
问 Cloudflare:www.example.com? → A: 1.2.3.4    ← 到这才是真答案

dig 查询

$ dig NS google.com
google.com.  172800  IN  NS  ns1.google.com.
google.com.  172800  IN  NS  ns2.google.com.
...

NS 存在两处(必须一致)

1. 上级 TLD 服务器 — 注册商代你提交

2. 自己的权威服务器(自我声明)

在注册商控制台改"DNS 服务器",改的是第 1 处。

NS vs A

| 记录 | 存什么 | 谁配置 | 改动影响 |

|------|--------|--------|----------|

| NS | 权威服务器域名 | 注册商控制台 | 换 DNS 服务商 |

| A | 具体 IP | DNS 服务商控制台 | 换服务器 IP |

为什么至少两条

DNS 规范要求至少 2 台权威服务器,防单点故障。


7. hichina.com 的 NS 情况

查询结果

hichina.com.  3600  IN  NS  ns1.hichina.com.
hichina.com.  3600  IN  NS  ns2.hichina.com.

权威 NS 就是自己家的服务器(self-hosted)。

是什么公司

hichina.com = 万网(HiChina):

  • 1996 年创立,中国最早的域名注册商之一
  • 2009 年被阿里巴巴收购
  • 现在是阿里云域名服务的底层品牌

Whois:Registrar = Alibaba Cloud Computing (Beijing) Co., Ltd.

是否权威

是权威,两个层次:

1. 对 hichina.com 自身 — self-hosted NS,大服务商都这样(Cloudflare 也一样)

2. 作为 DNS 服务提供商 — 中国顶级权威之一,国内大量域名的解析权都在这套 NS 系统里


8. 去中心化域名

把域名系统从 ICANN + 注册局 + 注册商的中心化链条里解放出来,用区块链管理所有权和解析。

核心目标:没人能没收你的域名,也没人能审查你的解析。

主流方案

| 方案 | 后缀 | 特点 |

|------|------|------|

| ENS | .eth | 最主流,建在以太坊上,域名 = NFT |

| Handshake | 任意 TLD | 野心最大,把整个 DNS 根区搬上链 |

| Unstoppable Domains | .crypto、.nft、.wallet | 一次性付费,永久所有权 |

| 其他 | .sol、.tez、.bit | 各种公链自己搞的 |

工作原理(以 ENS 为例)

传统 DNS:
  你 → 递归 → TLD → 权威 → IP

ENS:
  你 → ENS 解析器(读以太坊智能合约)→ 记录

关键区别:

  • 没有中心化数据库 — 记录存链上
  • 没有注册局 — 智能合约就是"注册局"
  • 所有权 = 私钥

怎么访问 .eth 网站

浏览器默认不支持,需要:

1. 专用浏览器:Brave 内置支持

2. 浏览器扩展:MetaMask、ENS 插件

3. 网关代理:vitalik.eth.limo(有点讽刺)

4. 本地跑节点

最大痛点:不解决访问入口就只能圈内流转。

优缺点对比

| | 传统 DNS | 去中心化域名 |

|---|---|---|

| 所有权 | 租借 | 完全拥有(凭私钥) |

| 抗审查 | 差 | 强 |

| 浏览器支持 | 全部 | 几乎没有 |

| 解析速度 | 毫秒级 | 慢(读链) |

| 隐私 | 一般 | 差(钱包地址公开) |

| 私钥丢失 | 客服恢复 | 永久失去 |

| 争议仲裁 | UDRP | 无 |

实际用途

1. 加密钱包的人类可读地址 — 最成功的用例

2. Web3 / dApp 入口

3. 抗审查的静态站点(配合 IPFS)

4. 数字身份

5. 投机 / 收藏

一句话总结

把"租域名"变成"拥有链上资产"——用密码学保证所有权,用区块链保证规则不可篡改。理想很美好,现实很骨感,目前更像加密世界的内部基础设施,而非传统 Web 的替代品。

← 返回首页