DNS 域名系統完全指南:從解析原理到實戰指令 | Networking

2026/05/13

DNS(Domain Name System,域名系統)是網際網路的核心基礎設施之一,負責將人類可讀的 域名(如 www.example.com)轉換為機器可用的 IP 位址(如 93.184.216.34)。沒有 DNS,我們就得記住每個網站的 IP 位址才能上網。本文從 DNS 的階層架構、記錄類型、解析流程、快取機制,到 dignslookup 等實戰診斷工具,帶你完整掌握 DNS 的核心知識。

DNS 是什麼?網際網路的電話簿

想像你要打電話給一位朋友,你不需要記住他的電話號碼,只要在通訊錄裡搜尋他的名字就好。DNS 在網際網路中扮演的角色就像這本電話簿——你只需要輸入 www.google.com,DNS 就會幫你找到對應的 IP 位址 142.250.185.78,讓你的瀏覽器能順利連上伺服器。

DNS 運作在 OSI 模型的第七層——應用層(Application Layer),查詢預設使用 UDP 端口 53(追求快速),而區域傳送(Zone Transfer)則使用 TCP 端口 53(確保大量資料的可靠傳輸)。


DNS 的階層架構

DNS 採用分散式階層樹狀結構,從根域到具體主機層層委派,這也是 DNS 能夠高效運作的關鍵設計。

                          ┌─────────┐
                          │  Root   │  根域(.)
                          │ Servers │  全球 13 組根伺服器
                          └────┬────┘
                ┌──────────────┼──────────────┐
                ↓              ↓              ↓
          ┌─────────┐   ┌─────────┐   ┌─────────┐
          │  .com   │   │  .org   │   │  .tw    │   TLD 頂級域伺服器
          └────┬────┘   └────┬────┘   └─────────┘
               ↓              ↓
         ┌──────────┐  ┌──────────┐
         │ example  │  │ wikipedia│                  權威名稱伺服器
         │  .com    │  │  .org    │
         └────┬─────┘  └──────────┘
              ↓
        ┌──────────┐
        │   www    │                                 主機記錄
        │.example  │
        │  .com    │
        └──────────┘

各層級說明

層級說明範例
Root Zone(根域)DNS 階層最頂端,全球 13 組根伺服器(a.root-servers.net ~ m.root-servers.net),透過 Anycast 技術分布數百個節點.
TLD(頂級域)分為通用 gTLD(.com, .org, .net)、國碼 ccTLD(.tw, .jp, .uk)、新 gTLD(.app, .dev, .io.com, .tw
Second-Level Domain(二級域)組織或個人註冊的域名example.com
Subdomain(子域)組織內部自行管理的子域名www.example.com

四種 DNS 伺服器角色

  1. 根伺服器(Root Server):DNS 查詢的起點,負責指引到正確的 TLD 伺服器。
  2. TLD 伺服器(Top-Level Domain Server):管理如 .com.tw 等頂級域,指引到對應的權威伺服器。
  3. 權威名稱伺服器(Authoritative Name Server):儲存域名的實際 DNS 記錄,提供最終答案。
  4. 遞迴解析器(Recursive Resolver):通常由 ISP 或公共 DNS 提供(如 Google 8.8.8.8、Cloudflare 1.1.1.1),負責代替客戶端完成整個查詢流程。

DNS 記錄類型

DNS 記錄定義了域名與各種資源之間的對應關係。以下是最常見的記錄類型:

A 記錄與 AAAA 記錄

A 記錄(Address Record)是最基本的 DNS 記錄,將域名對應到 IPv4 位址。AAAA 記錄(Quad-A Record)則對應到 IPv6 位址。

# 查詢 A 記錄(IPv4)
dig example.com A +short
# 預期輸出:
# 93.184.216.34

# 查詢 AAAA 記錄(IPv6)
dig example.com AAAA +short
# 預期輸出:
# 2606:2800:21f:cb07:6820:80da:af6b:8b2c

CNAME 記錄

CNAME 記錄(Canonical Name Record)是域名別名,將一個域名指向另一個域名。常用於讓 www.example.com 指向 example.com

# 查詢 CNAME 記錄
dig www.example.com CNAME +short
# 預期輸出:
# example.com.

注意:CNAME 不能與其他記錄類型共存於同一域名。例如根域名(example.com)若已有 MX 記錄,就不能再設定 CNAME。

MX 記錄

MX 記錄(Mail Exchange Record)指定處理該域名電子郵件的郵件伺服器,包含一個優先順序數值(數字越小優先權越高)。

# 查詢 MX 記錄
dig google.com MX +short
# 預期輸出:
# 10 smtp.google.com.
# 20 smtp2.google.com.
# 30 smtp3.google.com.

TXT 記錄

TXT 記錄(Text Record)儲存任意文字資訊,廣泛用於 SPF(寄件者政策框架)、DKIM(域名金鑰識別郵件)、域名驗證等。

# 查詢 TXT 記錄(常見的 SPF 設定)
dig example.com TXT +short
# 預期輸出:
# "v=spf1 include:_spf.google.com ~all"

其他常見記錄類型

記錄類型全名說明範例
NSName Server委派給特定的名稱伺服器example.com. NS ns1.example.com.
SOAStart of Authority區域的權威資訊(主伺服器、序號、更新間隔)見下方說明
PTRPointerIP 到域名的反向解析34.216.184.93.in-addr.arpa. PTR example.com.
SRVService指定服務的主機與端口_sip._tcp.example.com. SRV 10 60 5060 sip.example.com.
CAACertification Authority Authorization指定允許簽發 SSL 憑證的 CAexample.com. CAA 0 issue "letsencrypt.org"

SOA 記錄範例:

example.com. IN SOA ns1.example.com. admin.example.com. (
    2026042101  ; Serial(序號,通常用日期格式 YYYYMMDDNN)
    3600        ; Refresh(從伺服器查詢主伺服器間隔:1 小時)
    900         ; Retry(查詢失敗後重試間隔:15 分鐘)
    604800      ; Expire(從伺服器認為資料過期時間:7 天)
    86400       ; Minimum TTL(否定快取 TTL:1 天)
)

DNS 解析完整流程

當你在瀏覽器輸入 www.example.com 並按下 Enter,背後會經歷一連串的 DNS 查詢過程。以下是完整流程:

逐步解析

  1. 瀏覽器 DNS 快取 — 瀏覽器先檢查自己的 DNS 快取,看看有沒有之前查過的記錄。
  2. 作業系統 DNS 快取 — 快取未命中,瀏覽器詢問作業系統的 DNS 快取。
  3. 本機 hosts 檔案 — 作業系統檢查 /etc/hosts 有沒有手動設定的對應。
  4. DNS Resolver(遞迴解析器) — 以上都沒命中,作業系統將查詢送到設定的 DNS Resolver(例如 8.8.8.8)。
  5. Root Server — Resolver 的快取也沒有結果,向根伺服器詢問。根伺服器回覆:「去問 .com 的 TLD 伺服器」。
  6. TLD Server — Resolver 向 .com TLD 伺服器詢問。TLD 伺服器回覆:「去問 example.com 的權威伺服器」。
  7. Authoritative Server — Resolver 向 example.com 的權威伺服器詢問,取得最終答案:www.example.com 的 A 記錄是 93.184.216.34
  8. 回覆與快取 — Resolver 將結果快取並回覆給作業系統,作業系統也快取後回覆瀏覽器。
  9. 建立連線 — 瀏覽器使用取得的 IP 位址建立 TCP 連線,開始載入網頁。

遞迴查詢 vs 迭代查詢

類型說明使用場景
遞迴查詢(Recursive Query)客戶端要求 Resolver「幫我查到最終答案」,Resolver 負責全部工作客戶端 → Resolver
迭代查詢(Iterative Query)Resolver 逐級詢問,每個伺服器只回覆「我不知道,你去問 X」Resolver → 各級 DNS 伺服器

大多數情況下,客戶端到 Resolver 是遞迴查詢(客戶端只想要最終答案),而 Resolver 到各級 DNS 伺服器 是迭代查詢(Resolver 自己逐級查詢)。


DNS 快取與 TTL 機制

TTL(Time To Live,存活時間)決定 DNS 記錄可以被快取多久,單位是秒。

example.com.    3600    IN    A    93.184.216.34
                ↑
            TTL = 3600 秒(1 小時)

快取層級

快取層級說明典型 TTL
瀏覽器快取Chrome、Firefox 內建的 DNS 快取60 秒(Chrome 預設)
作業系統快取systemd-resolved / mDNSResponder依 TTL
Resolver 快取ISP 或公共 DNS(如 8.8.8.8)的快取依 TTL
否定快取「域名不存在」的快取(NXDOMAIN)SOA Minimum TTL

TTL 設定策略

場景建議 TTL原因
穩定的服務3600 ~ 86400 秒減少 DNS 查詢負載
CDN 或負載平衡60 ~ 300 秒需要快速切換節點
準備遷移60 ~ 300 秒遷移時能快速生效
災難復原30 ~ 60 秒故障時能快速切換

實務經驗:計畫做伺服器遷移前,建議提前 24-48 小時把 TTL 從長時間(如 86400 秒)降低到 60-300 秒,這樣在切換 IP 時舊快取能快速過期。

清除 DNS 快取

當你修改了 DNS 記錄卻看不到變化時,可能是本機快取的問題。以下是各平台清除快取的方式:

# macOS:清除 DNS 快取
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux(systemd-resolved):清除 DNS 快取
sudo systemd-resolve --flush-caches

# Linux:查看 systemd-resolved 快取統計
systemd-resolve --statistics

# Windows:清除 DNS 快取
ipconfig /flushdns

# Windows:查看 DNS 快取內容
ipconfig /displaydns

實用診斷工具

DNS 排查是網路管理的日常工作,以下三個指令是最常用的 DNS 診斷工具。

dig — 最強大的 DNS 查詢工具

dig(DNS Information Groper)是功能最完整的 DNS 查詢工具,輸出詳細且適合腳本解析。

# 基本 A 記錄查詢
dig example.com

輸出範例:

; <<>> DiG 9.18.12 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34

;; Query time: 25 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Tue May 13 10:00:00 CST 2026
;; MSG SIZE  rcvd: 56
# 精簡輸出(只顯示結果,適合腳本使用)
dig +short example.com
# 預期輸出:
# 93.184.216.34

# 查詢特定記錄類型
dig example.com MX +short       # 郵件伺服器記錄
dig example.com NS +short       # 名稱伺服器記錄
dig example.com TXT +short      # TXT 記錄
dig example.com SOA +short      # SOA 記錄

# 指定 DNS 伺服器查詢(用 @ 指定)
dig @8.8.8.8 example.com        # 使用 Google DNS 查詢
dig @1.1.1.1 example.com        # 使用 Cloudflare DNS 查詢

# 只顯示 ANSWER 段落(去掉額外資訊)
dig example.com +noall +answer
# 預期輸出:
# example.com.        3600    IN    A    93.184.216.34

# 反向解析(IP → 域名)
dig -x 93.184.216.34
# 預期輸出的 ANSWER SECTION 會顯示 PTR 記錄

dig +trace 是非常實用的除錯指令,它會顯示從根伺服器開始的完整解析路徑:

# 追蹤完整解析路徑
dig +trace example.com
# 輸出會依序顯示:
# .                 → 根伺服器回覆 .com 的 NS
# .com.             → TLD 伺服器回覆 example.com 的 NS
# example.com.      → 權威伺服器回覆最終 A 記錄

nslookup — 跨平台通用工具

nslookup 在 Windows、macOS、Linux 上都可以使用,適合快速查詢。

# 基本查詢
nslookup example.com
# 預期輸出:
# Server:     8.8.8.8
# Address:    8.8.8.8#53
#
# Non-authoritative answer:
# Name:   example.com
# Address: 93.184.216.34

# 指定 DNS 伺服器查詢
nslookup example.com 8.8.8.8

# 查詢 MX 記錄
nslookup -type=MX google.com
# 預期輸出:
# google.com  mail exchanger = 10 smtp.google.com.

# 查詢 NS 記錄
nslookup -type=NS example.com

# 反向查詢(IP → 域名)
nslookup 93.184.216.34

host — 簡潔快速查詢

host 指令輸出最簡潔,適合快速確認。

# 基本查詢
host example.com
# 預期輸出:
# example.com has address 93.184.216.34
# example.com has IPv6 address 2606:2800:21f:cb07:6820:80da:af6b:8b2c
# example.com mail is handled by 0 .

# 查詢特定記錄類型
host -t MX google.com           # 郵件伺服器記錄
host -t NS example.com          # 名稱伺服器記錄
host -t TXT example.com         # TXT 記錄

# 反向查詢
host 93.184.216.34

# 指定 DNS 伺服器查詢
host example.com 8.8.8.8

常見公共 DNS 伺服器

提供者IPv4特色
Google Public DNS8.8.8.88.8.4.4全球最大公共 DNS,穩定可靠
Cloudflare1.1.1.11.0.0.1主打隱私與速度
Quad99.9.9.9內建威脅情報過濾
OpenDNS208.67.222.222Cisco 旗下,支援內容過濾

DNS 安全

DNS 協定最初設計時並未考慮安全性,查詢和回應都是明文傳輸,容易遭到竊聽和篡改。以下是三種主要的 DNS 安全強化機制。

DNSSEC(DNS Security Extensions)

DNSSEC(DNS 安全擴充)透過數位簽章驗證 DNS 回應的真實性,建立一條從根域到目標域名的信任鏈(Chain of Trust),防止 DNS 偽造攻擊(DNS Spoofing)。

DNSSEC 引入的主要記錄類型:

記錄說明
RRSIG資源記錄的數位簽章
DNSKEY區域的公鑰(KSK 與 ZSK)
DSDelegation Signer,父區域對子區域 DNSKEY 的雜湊
NSEC / NSEC3證明某記錄不存在(否定存在證明)
# 查詢 DNSSEC 相關記錄
dig example.com +dnssec +multi

# 檢查 DS 記錄
dig example.com DS +short

DNS over HTTPS(DoH)

DoH 將 DNS 查詢封裝在 HTTPS 中(TCP 443),與一般 HTTPS 流量混在一起,使第三方難以辨識和攔截 DNS 查詢。

# 使用 curl 進行 DoH 查詢(Cloudflare)
curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq
# 預期輸出:
# {
#   "Status": 0,
#   "Answer": [
#     {
#       "name": "example.com",
#       "type": 1,
#       "TTL": 3600,
#       "data": "93.184.216.34"
#     }
#   ]
# }

DNS over TLS(DoT)

DoT 將 DNS 查詢封裝在 TLS 中(TCP 853),使用專用端口。相較於 DoH,DoT 更容易被網路管理者識別和管理,適合企業環境。

# 使用 kdig(knot-dns 工具)進行 DoT 查詢
kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com

DNS 與 Kubernetes:CoreDNS 簡介

在 Kubernetes 叢集中,CoreDNS 負責叢集內部的服務發現(Service Discovery)。每個 Service 和 Pod 都會自動獲得一個 DNS 記錄,讓服務之間可以透過名稱互相呼叫,而不需要硬編碼 IP 位址。

Kubernetes DNS 記錄的格式如下:

# Service 的 DNS 記錄格式
# <service-name>.<namespace>.svc.cluster.local
# 範例:
# my-service.default.svc.cluster.local → 10.96.0.100

# 從 Pod 內測試 DNS 解析
kubectl exec -it dnsutils -- nslookup my-service.default.svc.cluster.local
# 預期輸出:
# Server:    10.96.0.10
# Address:   10.96.0.10#53
#
# Name:   my-service.default.svc.cluster.local
# Address: 10.96.0.100

如果你正在使用 Kubernetes,了解 CoreDNS 的運作方式對於排查服務連線問題非常重要。


總結

DNS 是網際網路運作的基石,雖然日常使用中幾乎感受不到它的存在,但理解 DNS 的運作原理對網路管理、問題排查、安全防護都至關重要。讓我們回顧本文的重點:

  • DNS 階層架構:根伺服器 → TLD 伺服器 → 權威名稱伺服器,層層委派、分散管理。
  • DNS 記錄類型:A / AAAA 對應 IP、CNAME 做別名、MX 處理郵件、TXT 用於驗證與安全策略。
  • 解析流程:瀏覽器快取 → 作業系統快取 → hosts → Resolver → Root → TLD → Authoritative,最終取得 IP 位址。
  • TTL 與快取:合理設定 TTL 能兼顧效能與彈性,遷移前記得提前降低 TTL。
  • 診斷工具dig 功能最強大、nslookup 跨平台通用、host 簡潔快速。
  • 安全機制:DNSSEC 驗證回應真實性、DoH / DoT 加密查詢流量,保護隱私安全。

下次當你遇到「網站打不開」的問題時,不妨先用 dignslookup 確認 DNS 解析是否正常——很多時候,問題就出在 DNS 上。