> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/knowledge-base/zh/concepts/how-dns-works.md).

# DNS 的工作原理

你输入 `example.com` 然后页面就出现了。但计算机是按编号而不是按名称路由数据的。是谁在做这项翻译，你又能信任这个答案吗？

这种翻译就是域名系统，简称 DNS。它是互联网中最古老、最关键的组成部分之一，而你在网上做的几乎每一件事，都始于一次 DNS 查询。

## 电话簿的类比

想想一本纸质电话簿。你知道一个人的名字；你需要他们的号码。你查找名字，找到号码，然后拨打电话。

DNS 在互联网中也起同样作用。你知道 `example.com`；你的计算机需要 `93.184.215.14`。DNS 是查询步骤，而且它发生在与网站建立任何连接之前。

区别在于，这本电话簿大得任何一本书都容不下。没有任何一台机器掌握互联网上的所有名称。所以系统被分成了多个层级，查询会沿着这些层级向下进行。

## 是谁在回答这个问题

一次查询中会出现四类参与者。

* **你自己设备上的缓存。** 浏览器会保留最近的答案，操作系统也是如此。如果答案已经在本地，就根本不会有任何问题离开你的设备。
* **递归解析器。** 这是替你跑腿的助手。你的设备只向它问一个问题，并期待一个答案。它通常由你的互联网服务提供商运行，但也可以是公共服务，或者你自己运行的服务。
* **根服务器和顶级域服务器。** 它们并不知道最终答案。它们知道接下来该问谁。根服务器知道谁负责 `.com`, `.org`, `.de` 以及其他所有顶级域名。这些 `.com` 服务器知道谁负责每个 `.com` 名称。
* **权威服务器。** 由域名运营方发布、真正保存该域名记录的那台服务器。

以下是你的解析器从未见过的一个名称所经历的完整链路：

```mermaid
sequenceDiagram
    participant B as 你的浏览器
    participant R as 递归解析器
    participant Ro as 根服务器
    participant T as .com 服务器
    participant A as example.com<br/>权威服务器
    B->>R: example.com 在哪里？
    R->>Ro: example.com 在哪里？
    Ro-->>R: 去问 .com 服务器
    R->>T: example.com 在哪里？
    T-->>R: 去问 example.com 自己的服务器
    R->>A: example.com 在哪里？
    A-->>R: 93.184.215.14
    R-->>B: 93.184.215.14
```

直到现在，你的浏览器才会与网站建立连接。

整个交换通常在不到一秒的时间内完成，而且大多数时候比图中显示的还要快得多——这是因为缓存。

## 缓存和 TTL

每次都查询完整链路会很浪费。因此每个答案都会附带一个过期时间，称为 **TTL** ——生存时间，以秒为单位。

当解析器收到一个 TTL 为 300 的答案时，它会在接下来的五分钟里直接复用这个答案，而无需再次查询。你的操作系统和浏览器也是如此。热门名称几乎无处不在地被缓存，所以大多数查询都感觉瞬时完成。

TTL 也是域名变更不会立刻生效的原因。当网站迁移到新地址时，旧答案会一直从缓存中提供，直到过期。这才是“DNS 传播”的真正含义——并没有什么东西在传播，旧答案只是会在不同地方、不同时间逐渐过期。

这也解释了一个常见的困惑：在你更改 DNS 设置后，你的设备可能还会继续使用旧答案一段时间。清空缓存，或者 უბრალოდ等待，就能解决。

## 你的解析器通常是谁

除非你改过什么，否则你的递归解析器就是你的 **互联网服务提供商的**。你的路由器会在连接建立时自动获取它的地址，并把它提供给你家中的每台设备。

这很方便，而且通常很快，因为解析器离你很近。这也意味着你的服务提供商会按顺序、带时间戳地看到你查询的每一个域名——即使是你通过 HTTPS 访问的网站也是如此，因为查询发生在加密连接开始之前。

替代方案是由其他运营方运行的公共解析器，或者由你自己运行的解析器。更改解析器会改变 *谁* 能看到你的查询。它不会让它们隐形。

## 加密 DNS：DoH 和 DoT

传统 DNS 以明文形式传输。路径上的任何人——本地网络、服务提供商——都能读取这些问题，并且原则上也能篡改答案。两个标准通过把 DNS 包进加密层来解决“读取”问题： **通过 HTTPS 的 DNS** （DoH），它让查询看起来像普通的网页流量，以及 **通过 TLS 的 DNS** （DoT），它使用专用的加密通道。大多数现代浏览器和操作系统至少支持其中一种，有时甚至默认开启。这两种方式都能保护你和解析器之间的观察者看不到你的查询，也都大大增加了篡改难度——但它们都无法对解析器本身隐藏任何内容，因为解析器仍然能看到你问的每一个问题。加密 DNS 关乎 *谁* 谁能看见，而不是是否有人能看见。

## 问题会出在哪里

DNS 是一条信任链，而每一环都可能失效或受到干扰。

* **劫持。** 路径上的某个东西代替你选择的解析器作答。酒店网络把你重定向到登录页面，就是一种无害版本。某个网络悄悄把所有查询都重定向到自己的解析器，就没那么无害了——你精心设置的解析器选项会被直接忽略。
* **污染或投毒。** 返回的答案是故意错误的，把你指向一个拦截页面、一个失效地址，或者完全不同的服务器。这是一种常见的审查手段，因为它成本低，而且能同时作用于所有设备。
* **分裂答案。** 同一个名称会根据提问者不同而合法地返回不同地址。大型服务会刻意这样做，把你引导到更近的服务器。所以两个解析器不一致，并不自动意味着遭到了篡改——但如果答案离谱得不合常理，比如一个国外网站突然解析成本地地址，那通常就意味着有问题。
* **泄漏。** 你连接了 VPN，但你的 DNS 查询仍然发往隧道外你服务提供商的解析器。流量是受保护的；你查过的名称列表却不是。参见 [我是否泄露了真实 IP？](/knowledge-base/zh/diagnose/am-i-leaking-my-real-ip.md).
* **普通故障。** 如果你的解析器停止响应，一切看起来都会坏掉，尽管你的连接其实没问题。所谓“互联网挂了”，常常其实是“DNS 挂了”。

## 常见误解

**“HTTPS 可以保护我的 DNS 查询。”** 不会。HTTPS 开始于 *之后* 查询结束。除非你使用加密 DNS，否则你访问的名称会明文传输。

**“更改 DNS 会让浏览更快。”** 有时会略微快一些，因为更近或缓存更好的解析器会更快给出答案。但 DNS 只占页面加载时间的一小部分，而且地理位置很远的解析器还可能通过把你送到一个遥远的网站副本而让情况更糟。

**“不同的答案就意味着有人在攻击我。”** 不一定。大型网站会按设计返回不同地址。要留意不合常理的答案，而不只是不同的答案。

**“隐私浏览会隐藏我的查询。”** 它只会清除本地历史。查询仍然会发送到同一个解析器。

{% hint style="info" %}
**在 MyIP 上亲自看看**

[DNS 解析器](/knowledge-base/zh/lookup-privacy/dns-resolver.md) 它会同时从世界各地的一组知名解析器查询同一个域名，并把答案并排展示。如果某个地区的答案与其他地区完全不同，你看到的是干扰，而不是普通的负载均衡。

如果你怀疑有人在改写你的答案， [我的 DNS 被劫持或污染了吗？](/knowledge-base/zh/diagnose/is-my-dns-hijacked.md) 会按顺序带你检查这些步骤。
{% endhint %}

## 相关概念

* [什么是 ASN？](/knowledge-base/zh/concepts/what-is-an-asn.md) ——你的查询经过的网络
* [GeoIP：IP 定位如何工作](/knowledge-base/zh/concepts/geoip-explained.md) ——为什么会为你选择附近的服务器
* [浏览器指纹识别详解](/knowledge-base/zh/concepts/browser-fingerprinting.md) ——另一种无需 Cookie 也能识别你的方式
* [DNS 泄漏测试](/knowledge-base/zh/connection-tools/dns-leak-test.md) ——检查你实际在使用哪个解析器


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/knowledge-base/zh/concepts/how-dns-works.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.