瀏覽器如何把網域名稱轉換成 IP？
在人類世界中，人跟人會透過語言溝通，也會呼叫對方的名字。但在電腦世界裡，裝置真正連線時使用的是 IP 位址。
然而，要人類記住一長串數字實在太困難了！所以我們平常會使用網域名稱，再由 DNS 將它解析成 IP 位址。等瀏覽器取得可用的 IP 位址後，才有辦法繼續建立連線並傳輸資料。
這個章節就是要探討這一系列的轉換如何進行，最終又是怎麼得到 IP 位址的。那我們就接著開始吧！
本機與 DNS server 的 cache
一開始，如果瀏覽器的 host resolver cache 已經有可用的解析結果，通常就能省下後續的 DNS 查詢。以 Chrome 來說，可以開啟 chrome://net-internals/#dns，輸入網域名稱後手動執行 lookup；這個頁面也提供清除 Chrome host cache 的功能。下圖是查詢 youtube.com 後得到的結果：
如果瀏覽器沒有可用的 cache，接下來會依瀏覽器、作業系統與網路設定繼續解析，例如查找 hosts 檔案、作業系統 cache，或向設定好的 DNS server 發出查詢。這台 DNS server 可能是家用 router、ISP 提供的 resolver、公司或 VPN 內部的 resolver，也可能是自己指定的 public DNS；使用 DoH（DNS over HTTPS）時，瀏覽器還可能直接向指定的服務查詢。
想確認目前 nslookup 會詢問哪一台 DNS server，以及它回傳的解析結果，可以執行：
nslookup google.comnslookup 會直接詢問指定或系統預設的 DNS server，並不是用來查看本機 DNS cache。以下圖來說，我的電腦會顯示這些資料：
可以先看一下 Server 與第一個 Address：
Server：這次查詢使用的 DNS server。圖中是192.168.213.1，代表我的電腦把家用 router 當成 DNS server，但其他網路環境不一定相同。Address：DNS server 的 IP 位址與 port。圖中的192.168.213.1#53表示使用192.168.213.1的 port 53。
下面的 Name 與 Address 則是查詢結果，告訴你網域名稱解析到哪個 IP 位址。Non-authoritative answer 表示這份回應不是由該網域的 Authoritative Name Server 直接回答，而是由目前詢問的 recursive resolver 或 forwarding resolver 回傳；它可能直接命中 cache，也可能剛向上游完成查詢，因此不能只靠這行文字判斷是否命中 cache。
所以，一般使用者的電腦不需要自己運行一套完整的 recursive DNS server，而是透過本機的 stub resolver，把查詢交給設定好的 DNS server。若家用 router 扮演 forwarding resolver，它通常會再把查詢轉送給上游的 recursive resolver；這些 resolver 也可能有自己的 cache，如果 cache 裡沒有可用資料，才需要繼續往 DNS 階層查找！
這兩種 resolver 的工作方式不太一樣：
- forwarding resolver：收到查詢後，不會自己沿著 Root、TLD 與 Authoritative Name Server 逐層尋找答案，而是把查詢轉送給預先設定的上游 resolver，再將結果回傳給用戶端。家用 router 提供的 DNS proxy 經常扮演這個角色；至於會不會保存 cache，則取決於實作與設定。
- recursive resolver：負責替用戶端取得最終答案。它會先查找自己的 cache；cache miss 時，如果由它自己執行解析，就會從 Root Name Server 開始進行 iterative query，依序找到 TLD 與 Authoritative Name Server，直到取得答案或確認查詢失敗。
forwarding resolver 與 recursive resolver 描述的是處理查詢的角色，不一定代表兩套獨立的軟體或兩台不同的主機。同一套 DNS server 可以同時具備 forwarding、recursive 與 caching 等能力，實際行為仍要看服務的設定。
DNS resolver
當 recursive resolver 的 cache 也找不到答案時，實際路徑就會像抽絲剝繭一樣：先從 Root Name Server 取得 TLD Name Server 的位置，再向 TLD Name Server 取得目標網域的 Authoritative Name Server，最後查到 A、AAAA 或 CNAME 等 DNS record。recursive resolver 取得結果後會回傳給用戶端，瀏覽器才能接著往解析出的 IP 位址建立連線！
recursive resolver 常見的來源包含：
- ISP（Internet Service Provider）
- Public DNS provider，例如 Google Public DNS（
8.8.8.8）與 Cloudflare（1.1.1.1）
這裡是說 recursive resolver 可以由不同服務提供，實際上會依系統或瀏覽器設定選用 resolver，並不是每次同時向圖中的三個服務查詢。
那下圖就是 cache miss 後的分層查找流程，接著繼續細講。圖中的 IP 僅是流程示意，不代表 google.com 的實際解析結果。
Root Name Server
假如說我要查找 blog.itskylen.com 時，完整網域名稱可以寫成 blog.itskylen.com.，最後面的 . 代表 DNS root。recursive resolver 會先詢問 Root Name Server，取得負責 .com 的 TLD Name Server 資訊，才有辦法進行下一階段的查找。
TLD Name Server（Top-Level Domain Name Server）
有了上一階段的結果後，就準備向 .com 的 TLD Name Server 查詢 itskylen.com 由哪些 Authoritative Name Server 負責。目前常見的 TLD 類型包含：
- gTLD（Generic Top-Level Domain，通用頂級網域）：例如
.com、.org、.net，後來也陸續加入.app、.blog等新通用頂級網域。 - ccTLD（Country Code Top-Level Domain，國家及地區頂級網域）：代表特定國家或地區，例如
.uk代表英國、.cn代表中國、.jp代表日本。ccTLD 通常由相應國家或地區的註冊管理機構管理，也可能有特定的註冊與使用要求。 - sTLD（Sponsored Top-Level Domain，贊助類頂級網域）：由特定社群或組織贊助及管理，例如
.gov由美國政府管理，供符合資格的美國政府機構使用；.edu則有特定的教育機構資格限制。
所以，跟 .com 的 TLD Name Server 溝通後，recursive resolver 會得到 itskylen.com 的 NS record，以及必要時用來找到這些 Name Server 的 IP 位址。這些 Name Server 才是下一階段要詢問的對象。
Authoritative Name Server
在這個階段，Authoritative Name Server 會依自己管理的 zone 回答 blog.itskylen.com 對應的 DNS record。A record 會指向 IPv4 位址，AAAA record 會指向 IPv6 位址；如果查到的是 CNAME，則代表它是另一個網域名稱的別名，recursive resolver 還要繼續解析該名稱，最後才取得可用的 IP 位址。
我們平常在 DNS provider 後台設定 A、AAAA 或 CNAME record，就是在維護這個 zone 的授權資料。recursive resolver 取得最終結果後，會把答案一路回傳給本機，並依 DNS record 的 TTL cache 一段時間，讓後續查詢不必每次都從 Root Name Server 重新開始。
TTL（Time to Live）不是另一種 cache，而是 DNS record 附帶的 cache 有效時間，通常以秒為單位。例如 TTL 設為 300，代表 resolver 最多可以在 300 秒內重複使用這份結果；時間到了之後，並不是網域名稱或 IP 位址立刻失效，而是 resolver 不能再直接信任舊的 cache，下一次收到查詢時需要重新解析並取得最新資料。
TTL 設得較長，可以減少重複查詢與 DNS server 的負擔，但修改 DNS record 後，舊結果也可能在 cache 裡停留比較久；TTL 設得較短，變更通常能更快反映，代價則是 resolver 需要更頻繁地重新查詢。因此在調整 DNS record 時，也要一起考量查詢量與變更生效速度！
總結
所以，當我們在瀏覽器輸入網域名稱時，瀏覽器並不是每次都會立刻從 Root Name Server 開始查找。它會先確認自己的 host resolver cache，再依瀏覽器、作業系統與網路設定，透過 stub resolver 將查詢交給指定的 DNS server。如果家用 router 扮演 forwarding resolver，它會把請求轉送給上游；真正負責取得最終答案的 recursive resolver 也會先檢查自己的 cache。
只有在前面的 cache 都找不到可用結果，而且 recursive resolver 需要自己執行解析時，才會依序詢問 Root、TLD 與 Authoritative Name Server，最後取得 A、AAAA 或 CNAME 等 DNS record。取得結果後，recursive resolver 會依 TTL cache 一段時間，瀏覽器與作業系統也可能依自己的規則保存結果，讓後續查詢可以更快完成。
也就是說，DNS resolution 不是單純把網域名稱換成 IP 而已，而是由不同角色分工，再搭配多層 cache 完成的查找流程。等瀏覽器拿到可用的 IP 位址後，接下來才會進入建立連線與傳輸資料的階段！