1983 - DNS 域名系統（給網路一個記憶的方式）#

案件摘要#

1983 年，Paul Mockapetris 設計了 DNS（Domain Name System）—— 把人類可讀的網址 www.example.com 對應到 IP 位址，並支援分散式、階層式的名稱解析：

\[ \text{名稱} \xrightarrow{\text{DNS}} \text{位址}, \qquad \text{全球階層式資料庫 + 快取}. \]

互聯網從「只能記 IP」的機器時代，進入「可以記名字」的人類時代—— DNS 是互聯網可用性的最後一塊拼圖。

前因 -- 為什麼會有這個案子#

1983 前的慘況：全網只有一份 /etc/hosts 主機名對照表（手寫，位於每台機器）：
網路擴張到數千台主機 → 手寫表無法維護、不同步、延遲生效。
Stanford 網路（1981 起多網互連）是人類極限的盡頭——名字空間無法分散。
ARPANET 轉 TCP/IP（1983 Flag Day）之後的緊迫感：全球主機快速增加，IP 位址由網路號 + 主機號構成，完全平坦——

\[ \text{IP} = \underbrace{126.96.\dots}_{\text{網路號}}.\underbrace{\dots}_{\text{主機號}}. \]

沒有組織結構，無法按單位（公司、學校）分配 → 管理混亂。 - Mockapetris 的偵探直覺：把人類的組織結構（.edu、.gov、國家域名）映射進名稱系統：

\[ \text{遞迴解析：} \text{www.某公司.com} \to \text{.com 伺服器} \to \text{該公司 DNS}. \]

線索與推理 -- 數學式、程式、理論#

第一條線索：遞迴 + 迭代查詢（DNS 的核心結構）#

DNS 有兩種查詢機制： - 遞迴查詢 (recursive)：客戶端向本地 DNS 請求「給我答案」——本地 DNS 負責到底。 - 迭代查詢 (iterative)：本地 DNS依次問根伺服器、TLD 伺服器、權威伺服器。

\[ \text{解析流程：} \quad \text{客戶端} \to \text{本地 DNS} \to \text{根} \to \text{.com TLD} \to \text{權威 DNS} \to \text{答案}. \]

第二條線索：階層分散（DNS 的分散式設計）#

DNS 是全球分散式資料庫，透過委派 (delegation)： - 根 (root) → TLD（.com, .edu, .org, 國家碼）→ 二級域 → 子域。 - 每一層只知道自己往下（授權鏈）——沒有中央登記。

\[ \text{查詢複雜度} = O(\text{層數}) = O(3\text{–}5) \quad \text{（與全球主機數無關）}. \]

這是分散式聯邦的經典設計——與區塊鏈、聯邦式學習同源。

第三條線索：快取與 TTL（可擴充性的秘密）#

每個 DNS 伺服器快取記錄直到 TTL (Time-To-Live) 到期：

\[ \text{快取命中率} = \frac{\text{快取命中數}}{\text{總查詢數}} \quad \text{（典型 } 95\%\text{–}99\%）}. \]

DNS 根伺服器只處理 5% 的查詢（其餘由 TLD 快取）——13 台根伺服器（anycast）服務全球。
TTL 讓更新能傳播——沒有 TTL，DNS 將是僵硬的。

Python：DNS 解析的遞迴-迭代流程#

import socket

def resolve(domain):
    """模擬 DNS 解析（本機直接用系統解析器）"""
    # 1. 檢查本地 /etc/hosts 與快取
    # 2. 迭代查詢：根 → TLD → 權威（實際由 stub resolver 完成）
    # 3. 回傳 IP
    ip = socket.gethostbyname(domain)
    return ip

# 展示 DNS 查詢工具
import subprocess
def dig_domain(domain):
    r = subprocess.run(["dig","+short",domain], capture_output=True, text=True)
    return r.stdout.strip() or "（本機 dig 不可用）"

print("解析 www.google.com:", resolve("www.google.com"))
print("查詢根 DNS 伺服器之一 a.root-servers.net:", dig_domain("a.root-servers.net"))
print("查詢 TLD .com 的權威 DNS:", dig_domain("com"))

輸出（典型結果）：

解析 www.google.com: 142.250.XXX.XXX
查詢根 DNS 伺服器之一 a.root-servers.net: 198.97.190.53
查詢 TLD .com 的權威 DNS: 192.5.6.30

（根伺服器在 1983 年還只有 13 台實體（1970s）與 13 個 IP（1990s 擴展），今天透過 anycast 與全球 CDN 擴展到數千個節點。）

結案 -- 後果與影響#

WWW 時代的必要條件（1991，見「1991-全球資訊網WWW.md」）：網址的可讀性（www.x.com vs 192.0.2.1）讓互聯網普及到非工程師。
今日的數位基礎設施：DNS 是全球最廣泛的分散式系統——每個 HTTP 請求都先查 DNS。
DNS 擴展的演化：
DNSSEC（2010）：數位簽名防偽——解決 DNS 劫持/spoofing。
DNS over HTTPS (DoH, 2018) / DNS over TLS (DoT)：加密 DNS 查詢——隱私 + 防中間人。
CDN 與 GeoDNS（2000s）：依使用者地理位置導流——DNS 成為流量調度層（Cloudflare, Akamai）。
DNS 攻擊的歷史：DNS 根伺服器攻擊（2007, 2018）、DDoS 反射放大（2000s）——開源的信任體系的代價。
IPv4 vs IPv6 的名稱化推遲：DNS 讓 IPv4/IPv6 過渡多了一层名稱→位址的解耦（同一網址可切換 IPv4/IPv6）——DNS 是 IPv6 過渡能漸進的根本原因之一。
歷史定位：Paul Mockapetris 原本在 BBN 做 DNS，是因為領導認為 DNS 是「小題大做」而被降職（據他自述，他因此申請了早退）。30 年後 DNS 成了互聯網最重要的應用層基礎設施之一。

關鍵人物與文獻#

P. Mockapetris：RFC 882/883，DNS 設計 (1983)。
J. Postel：RFC 編輯（RFC 1, 1969）——互聯網標準的守護者 (until 1998)。
R. Klena / P. Vixie：BIND 工具 (1980s-90s)；RFC 4033-4035：DNSSEC (2010)。
相關案件：1974-TCPIP協定.md、1991-全球資訊網WWW.md。