> 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-tw/concepts/how-dns-works.md).

# DNS 的運作方式

從你的瀏覽器到根伺服器：網站名稱如何變成 IP 位址、由誰來回答這個問題，以及流程在哪裡出錯。

你輸入 `example.com` 然後頁面就出現了。但電腦是依數字而非名稱來路由資料。誰負責翻譯，而你能信任這個答案嗎？

這個翻譯就是網域名稱系統，簡稱 DNS。它是網際網路上最古老、也最具基礎性的部分之一，而你在網路上所做的幾乎一切，都是從一次 DNS 查詢開始。

## 電話簿比喻

想像一本印刷版電話簿。你知道某人的名字；你需要他們的號碼。你查找名字，找到號碼，然後撥出電話。

DNS 在網際網路上也做同樣的事。你知道 `example.com`；你的電腦需要 `93.184.215.14`。DNS 是查詢步驟，而且它會在與網站建立任何連線之前發生。

不同之處在於，這本電話簿大到任何一本書都裝不下。沒有任何一台機器掌握網際網路上的所有名稱。所以這個系統被分成多層，而查詢會一路往下走。

## 誰回答這個問題

在一次查詢中會出現四種參與者。

* **你自己機器上的快取。** 你的瀏覽器會保留最近的答案，作業系統也是如此。如果答案已經在那裡，就根本不會有任何查詢離開你的裝置。
* **遞迴解析器。** 這是替你做繁瑣工作的助理。你的裝置只向它問一個問題，並期待一個答案。它通常由你的網際網路服務供應商提供，但也可能是公開服務，或是你自己架設的服務。
* **根伺服器與 TLD 伺服器。** 這些伺服器不知道最終答案。它們知道下一步該問誰。根伺服器知道誰負責 `.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-tw/diagnose/am-i-leaking-my-real-ip.md).
* **單純的中斷。** 如果你的解析器停止回應，即使你的連線正常，一切看起來也都會壞掉。「網際網路掛了」常常其實是「DNS 掛了」。

## 常見誤解

**「HTTPS 會保護我的 DNS 查詢。」** 不會。HTTPS 是在 *之後* 查詢才開始的。除非你使用加密 DNS，否則你造訪的名稱都是明文傳輸。

**「變更 DNS 會讓瀏覽更快。」** 有時候會稍微快一點，因為更近或快取更好的解析器會更快回應。但 DNS 只佔頁面載入時間的一小部分，而地理位置遙遠的解析器，反而可能因為把你送到更遠的網站副本而讓情況變糟。

**「不同的答案表示有人正在攻擊我。」** 不一定。大型網站本來就會回傳不同位址。要找不合理的答案，而不只是不同的答案。

**「私密瀏覽會隱藏我的查詢。」** 它只會清除本機歷史紀錄。這些查詢仍然會送到同一個解析器。

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

[DNS 解析器](/knowledge-base/zh-tw/lookup-privacy/dns-resolver.md) 會同時向世界各地一組知名解析器查詢同一個網域，並將答案並排比較。如果某個地區的答案和其他地區完全不像，你看到的是干擾，而不是一般的負載平衡。

如果你懷疑有人正在改寫你的答案， [我的 DNS 是否被劫持或污染？](/knowledge-base/zh-tw/diagnose/is-my-dns-hijacked.md) 會依序帶你檢查各項步驟。
{% endhint %}

## 相關概念

* [什麼是 ASN？](/knowledge-base/zh-tw/concepts/what-is-an-asn.md) — 你的查詢所經過的網路
* [GeoIP：IP 地理位置定位如何運作](/knowledge-base/zh-tw/concepts/geoip-explained.md) — 為什麼會替你選擇附近的伺服器
* [瀏覽器指紋識別說明](/knowledge-base/zh-tw/concepts/browser-fingerprinting.md) — 不使用 cookie 也能辨識你的另一種方式
* [DNS 洩漏測試](/knowledge-base/zh-tw/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-tw/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.