DNS是什麼？從網域名稱查出IP位址的運作

生活中的例子

打開網站時，我們會輸入「www.example.com」這樣的名稱，或是點一下連結。電子郵件的收件地址，也是在「@」後面接著名稱。幾乎不會直接輸入數字的號碼。

另一方面，也常聽到「改了DNS設定，卻還是出現舊網站」「DNS故障讓大型服務停擺」這類消息。名稱的背後，到底發生了什麼事呢？

為什麼要有名稱和號碼2種

網際網路會把資料分成小塊（封包）傳送。封包的目的地，只能寫上稱為IP位址的號碼。號碼的運作方式，在「IP位址是什麼？」中說明。

不過，「203.0.113.10」這樣的數字，人很難記住。而且網站搬到別台伺服器時，號碼就會改變。只要用名稱當窗口，即使號碼變了，使用者也能用同一個名稱連上。

於是，人們做出了查詢名稱與號碼對應的機制。這稱為DNS（網域名稱系統）。現在這種形式的基礎，是在1987年制定的。

在DNS之前，所有名稱與號碼的對應表都集中在1個檔案裡，由各台電腦複製使用。電腦變多之後，更新就跟不上了。DNS把這張表拆開，交由各自的擁有者管理。

網域名稱要從右邊讀

像「www.example.com」這樣用點分隔的名稱，稱為網域名稱。網域名稱越往右，代表越大的區塊。臺灣的地址依「縣市、區、路、號」由大到小書寫，網域名稱的方向剛好相反。不過和地址不同，網域名稱並不代表地點。

最右邊的「com」或「jp」這類區塊，稱為頂級網域（TLD）。「com」原本是給公司用的，「jp」是給日本用的。它左邊的「example」，是組織或個人申請後使用的部分。最左邊的「www」，是擁有者自由取的名稱，這裡指的是網頁伺服器。

在日本常見的「example.co.jp」中，「co」（日本公司用）是第2層，組織的名稱放在它的左邊。

其實，網域名稱的最右邊，還有一個平常省略的點。正式寫法是「www.example.com.」，最後的點代表所有名稱的起點。這個起點稱為根。所有的名稱，構成一棵以根為基礎、往下分枝的樹。

從名稱查出號碼的流程

從名稱查出號碼，稱為「名稱解析」。名稱解析有3種角色不同的負責者參與。

第1種，是在手機或電腦裡面的負責者。它是內建在作業系統裡的小機制，只會向固定的對象詢問「這個名稱的號碼是多少？」。它自己不會到處查詢。這稱為存根解析器。要詢問的對象，通常是連上Wi-Fi時，由DHCP自動告知。

第2種，是接受這個詢問、代替我們到處查詢的伺服器。大多由網路服務供應商或公司準備，也有任何人都能用的公開伺服器。這種伺服器稱為遞迴解析器（完整服務解析器），也叫快取DNS伺服器。以下簡稱「解析器」。

第3種，是持有答案來源的伺服器。example.com的名稱與號碼的對應，寫在它的擁有者準備的伺服器上。像這樣，對某個區塊擁有正式答案的伺服器，稱為權威DNS伺服器。

解析器會先詢問負責根的伺服器。這稱為根伺服器。根伺服器不知道答案，但會指引「com的事，請問com的伺服器」。com的伺服器（頂級網域的伺服器）會指引「example.com，請問這台伺服器」。最後，example.com的權威DNS伺服器回答「是203.0.113.10」。

每台伺服器只知道自己區塊裡的事，以及下一層區塊該去問誰。所以，不需要在1個地方存放全世界的名稱。

把答案記下來：快取與TTL

如果每次都從根開始依序詢問，會很花時間，查詢也會集中到根伺服器。所以，解析器會把得到的答案記住一段時間。這種「暫時記住」的做法，以及存放的地方，稱為快取。手機和瀏覽器也有小小的快取。

要記住多久，由網域的擁有者決定，並附在答案裡回傳。這段時間稱為存活時間（TTL，Time To Live），以秒為單位。例如TTL是3600，就會在1小時內使用記住的答案，之後再重新詢問。

「com的伺服器在哪裡」這類指引也會同樣記住，所以詢問根伺服器的次數很少。常用的名稱，只靠解析器的快取就能回答。

這個機制也有反面。伺服器搬家而改了號碼，全世界的解析器在TTL到期前，仍會使用舊的答案。常聽到「改了DNS要等它傳播、生效」，就是這個原因。實際上，並不是有什麼東西依序傳遍全世界，而是在等各地的快取到期。所以，搬家前先把TTL縮短，是常見的準備。

根伺服器只有13台？

根伺服器有從a到m的13個名稱。營運的是12個組織，美國的Verisign公司負責A和J。M由日本的WIDE Project營運。

不過，並不是「全世界只有13台」。每個名稱的背後，都有許多放在世界各地的複本。根據各營運組織共同公開的root-servers.org，2026年時約有2,000個地點。

各地的複本，同時使用相同的號碼。途中的路由器會把送往這個號碼的封包，送到路徑上最近的複本。這種送法稱為任播（anycast）。就算有1個地點故障或遭受攻擊，其他地點也能繼續回答。

DNS裡登記的資訊：主要的記錄

權威DNS伺服器上，每個名稱都登記了標示「是哪種資訊」的資料行。這一行一行稱為記錄。

IPv6的號碼長度是IPv4的4倍（128位元）。差異可以在「IPv4與IPv6的差異」的表格中看到。

CNAME用在把傳送交給CDN（從各地的伺服器代為傳送內容的服務）等的時候。只要設成對方名稱的別名，對方改了號碼，自己的設定也不必修改。

寄送郵件的伺服器，會查詢收件地址「@」後面名稱的MX記錄，找出要送到哪裡。

DNS與隱私

傳統方式的DNS查詢，是不加密就送出。所以，在同一個Wi-Fi的人或途中的電信業者，都能讀出你查了哪個名稱。

就像在「HTTPS是什麼？」看到的，即使用HTTPS保護了內容，想看哪個網站仍可以從這裡看出來。

於是，出現了把DNS查詢本身加密的方式。用和HTTPS相同的TLS包起來送出的方式，稱為DNS over TLS（DoT），在2016年成為標準。當作HTTPS通訊送出的方式，稱為DNS over HTTPS（DoH），在2018年成為標準。兩者在許多瀏覽器和作業系統上都能使用。

不過，加密的只有自己的設備和解析器之間。解析器本身知道查了哪些名稱。從解析器到權威DNS伺服器的查詢，大多也還沒加密。選擇用哪個解析器，也等於選擇「把查詢的紀錄交給誰」。

針對DNS的攻擊與防護

讓解析器記住假答案：快取汙染

讓解析器記住假答案的攻擊，稱為DNS快取汙染。攻擊成功時，使用者即使輸入正確的名稱，也會被帶到假伺服器。假答案被記住的期間，所有使用這個解析器的人都會受到影響。

解析器會把和查詢時所附號碼（ID）相同的回答，當作真的答案。這個ID是16位元，只有65,536種。攻擊者會搶在真答案之前，大量送出猜測ID的假答案。

2008年，研究人員丹·卡明斯基（Dan Kaminsky）找到讓這種攻擊更容易成功的方法。方法是讓解析器接連查詢不存在的名稱，就能一再重試。同年7月8日，美國的資安應變機構CERT/CC公布此事，許多DNS軟體同時修正。修正的重點，是讓連接埠號碼也每次隨機改變，增加必須猜中的組合。

替答案加上簽章：DNSSEC

更根本的對策是DNSSEC。網域的擁有者替記錄蓋上電子印章（數位簽章）。解析器從根開始依序追溯簽章，確認答案是真的、途中沒有被竄改。根從2010年7月起就加上了簽章。

不過，DNSSEC也有做不到的事。它不會把答案加密，所以無法隱藏查了哪個名稱（那是DoH和DoT的工作）。沒有加簽章的網域，或不確認簽章的解析器，就沒有效果。它也防不了用大量通訊讓對方停擺的攻擊（DDoS）。

另一道防護是HTTPS。即使被帶到假伺服器，那台伺服器通常沒有這個名稱的正確憑證。所以瀏覽器會顯示警告。出現警告時，不要繼續前往，這一點很重要。

DNS停擺時：2021年的Facebook故障

2021年10月4日，Facebook、Instagram、WhatsApp有超過6小時無法連線。以下是營運公司（現在的Meta公司）隔天公開的說明摘要。

起因是公司內部線路的維護作業。原本是為了調查線路容量而下的指令，卻切斷了連接全世界資料中心的所有線路。本來應該擋下這種錯誤的檢查工具，也有缺陷。

該公司的權威DNS伺服器被設計成：和資料中心聯絡不上時，就判斷連線有問題。這時，它會停止向網際網路發出「這些號碼請往這邊」的路線指引。交換這種路線指引的規則，稱為BGP。結果，DNS伺服器本身雖然還在運作，外面卻到不了它。

全世界的解析器都查不到facebook.com等的號碼。就算服務的伺服器還在運作，不知道號碼，使用者也連不上。公司內部的工具也依賴同一個網路，所以由技術人員親自前往資料中心修復。Meta表示，這次故障不是攻擊造成的。

自己試試看

名稱解析可以在電腦上實際看到。在Windows的命令提示字元或Mac的終端機，輸入「nslookup example.com」。畫面會顯示號碼，以及回答的解析器。

在Mac等電腦上輸入「dig +trace example.com」，還能看到從根依序查下去的過程。兩者都只是查詢，不會改變設定。

常見的誤解

從數字來看

進一步學習

• 用表格看差異：TCP與UDP的差異（DNS查詢主要使用UDP的原因）
• 路線指引的機制：OSPF與BGP的差異（Facebook故障中出現的BGP的定位）
• 用計算試試看：可用率計算工具（放置多台伺服器就更不容易停擺的計算）
• 下一步的名詞：URL（包含網域名稱、表示網頁位置的寫法）
• 查到名稱之後的流程：「網際網路怎麼傳送資料？」