DNS 是什麼？DNS 查詢、運作原理與設定完整指南

DNS 是什麼？用電話簿與導航一次聽懂

DNS（Domain Name System，網域名稱系統）是一套把「網域名稱」對應到「IP 位址」的分散式資料庫系統。人在網路上其實是用名字在認路，例如 www.example.com；但電腦與網路設備之間是靠數字溝通，例如 192.0.2.1。這兩個世界中間的翻譯工作，就是由 DNS 負責。

會需要 DNS，最根本的原因是「記憶」。IPv4 的位址是一串數字，IPv6 更長更難記，但現代人每天要開的網站可能有十幾個，不可能全部背下來。DNS 讓每個網站都能用一個有意義的名字來代表，就像電話簿把「某某公司」對應到「某支電話號碼」，你不用記號碼，只要講得出名字就找得到人。

DNS 就像網際網路的導航

也有人把 DNS 比喻成 GPS 導航。你輸入「台北 101」這個地標名稱，導航幫你算出實際的座標與路線；你輸入網址，DNS 幫你查出實際的 IP，瀏覽器才知道資料要送去哪裡。差別在於，這個「查座標」的動作每次上網都要做，只是大部分時候被快取起來，快到你看不見。

網域、IP、主機三者關係

搞懂 DNS 之前，先分清楚三個常被混著講的名詞：網域是網站的名字，IP 位址是伺服器在網路上的實際住址，主機則是真正存放網站檔案、提供服務的那台機器或空間。DNS 的工作，就是把「網域」指向正確的「主機 IP」。如果你還想更完整了解網域本身是什麼、怎麼挑、怎麼申請，可以先看我們整理的 網域申請與購買完全指南。

關於 DNS 的 3 個常見誤解

DNS 查詢怎麼運作？完整解析流程 6 步驟

當你在瀏覽器輸入網址按下 Enter，背後其實是一連串「層層往上問、再層層回答」的過程。這段過程專業上叫做 DNS 解析（DNS resolution），而我們平常說的 DNS 查詢，就是指這個把名稱換成 IP 的動作。流程大致如下：

1. 先查自己的快取 瀏覽器與作業系統都會先看自己有沒有記過這個網域對應的 IP。如果有，而且還沒過期，就直接拿來用，完全不用對外查詢。
2. 問遞迴解析器（Recursive Resolver） 快取沒有，就交給 DNS 遞迴解析器。它通常由你的網路服務供應商（ISP）提供，也可能是你手動指定的公共 DNS，例如 1.1.1.1 或 8.8.8.8。
3. 遞迴解析器問根名稱伺服器 根名稱伺服器（Root Server）不會直接給答案，而是告訴解析器：「要查 .com 的話，去問 .com 的伺服器。」
4. TLD 名稱伺服器接手 負責管理頂級網域（例如 .com、.net、.tw）的 TLD 伺服器，會再指出這個網域的權威名稱伺服器是誰。
5. 權威名稱伺服器給出最終答案 權威名稱伺服器（Authoritative Name Server）持有該網域最正確的 DNS 記錄，這裡回傳的 IP 就是最終答案，可信度最高。
6. 回傳並快取，瀏覽器開始連線 解析器把 IP 回給你的裝置，同時依 TTL 設定快取一段時間。瀏覽器拿到 IP 後，才正式向該主機發出網頁請求。

整個流程在正常情況下通常只花幾十毫秒，快到你根本不會注意到。但如果某一段出錯、伺服器逾時，或記錄設錯，你就會看到「找不到網站」或連線很久沒反應。想更深入理解每一種記錄該怎麼填、設定時有哪些細節，可以延伸閱讀 DNS 設定完整教學。

DNS 記錄類型有哪些？A、CNAME、MX 一次看懂

DNS 之所以能同時管網址、信箱、驗證等多種用途，靠的是不同種類的「記錄（Record）」。每一筆記錄負責一件事，在 DNS 後台看到密密麻麻的欄位，其實只是這幾種常見類型在排列組合。

對一般企業網站來說，最常動到的其實只有 A 記錄（網站指向）、CNAME 記錄（子網域）與 MX／TXT 記錄（信箱與驗證）。設定時最常見的錯誤，就是把 CNAME 設在同一個名稱又有 A 記錄的地方，導致衝突；或是搬家時只改了網站主機，卻忘了同步更新 MX，結果信箱收不到信。

新手檢查 DNS 記錄的 3 個重點

• 同一個主機名稱不要同時有 A 與 CNAME：兩者會打架，多數系統會直接報錯或忽略其中一筆。
• 根網域通常用 A 記錄：很多服務不允許在根網域（例如 example.com）直接設 CNAME，改用 A 記錄或別名（ALIAS／ANAME）較保險。
• @ 代表根網域、www 是子網域：後台欄位裡的 @ 與 www 常讓人混淆，設定前先確認你改的是哪一個。

免費公共 DNS 推薦與比較

你上網時使用的 DNS，預設通常是 ISP 提供的。有些人會手動換成「公共 DNS」，動機不外乎：原本的解析太慢或不穩、想加強隱私、想擋廣告或惡意網站，或是覺得連線品質會變好。以下是幾個常見選項：

要提醒的是：換公共 DNS 不會「無腦變快」。如果你的 ISP 原本的 DNS 已經很順，換過去差異可能非常小；真正有感的通常是原本經常解析失敗、被導向廣告頁，或某些網站連不上的情況。另外，公共 DNS 主要是加速「查名字」這一步，實際網頁下載速度仍取決於你的頻寬與目標網站本身。

提到的 Cloudflare 也有完整的 DNS 學習資源，說明解析原理與各種記錄的用途，可作為理解原理的補充來源（見文末參考來源）。若你正在架站，刊登主機後通常會拿到主機商指定的 DNS 或 A 記錄，這時重點不是「換哪個公共 DNS」，而是把記錄設對。

DNS 查詢工具與指令教學

想知道一個網域目前指向哪裡、有沒有設錯，最直接的方法就是自己做一次 DNS 查詢。不用懂程式，以下三種方法就能涵蓋大部分需求。

方法一：線上 DNS 查詢工具（最推薦）

只要打開網站、輸入網域就能查，適合不想碰指令的人。常見工具包括 Google Admin Toolbox 的 Dig、DNS Checker、MXToolbox、whatsmydns 等。它們能顯示 A、AAAA、CNAME、MX、TXT 等記錄，也能一次看全球多地節點的解析結果，很適合確認「DNS 是否已經全球生效」。

方法二：作業系統指令 nslookup 與 dig

Windows 的「命令提示字元」輸入 nslookup moon-d.com，Mac 或 Linux 的終端機輸入 dig moon-d.com，就能直接看到解析結果。想指定用某一台 DNS 查詢，可以加上伺服器參數，例如比較 1.1.1.1 與 8.8.8.8 的結果有沒有差異。這招在排查「為什麼只有某些人連不上」特別好用。

方法三：DNS 管理後台

如果你本來就是這個網域的管理者，登入註冊商或主機商的 DNS 後台，就能看到所有記錄的原始設定，這也是修改設定的地方。要提醒的是，後台「設定值」與「實際生效值」可能因快取而不同，修改後建議再用線上工具從外部查一次確認。

另外，如果你對網域名稱、子網域與網站空間之間的關係還不太清楚，建議一併看懂 網址與網站空間的差異，這會幫助你判讀查詢結果。

DNS 設定與 TTL：網站搬家的關鍵

DNS 設定本身不難，難的是「時間差」。當你把網域指向新的主機，變更不會立刻傳遍全世界，而是等各地的快取逐一過期。這個快取存留時間就是 TTL（Time To Live），單位是秒。

常見的網站搬遷流程是：先在新主機把網站架好並測試 → 把 TTL 調短 → 切換 DNS 指向 → 從多個地點確認解析正確 → 觀察幾天後把 TTL 調回。切記不要在新站還沒測好之前就先把 DNS 切過去，否則訪客會直接看到壞掉的網站，對 SEO 與客戶信任都是傷害。

DNS 安全：污染、劫持與 DNSSEC

DNS 因為是每次上網的必經之路，自然也成了攻擊目標。常見的風險包括：

• DNS 快取污染（Cache Poisoning）：攻擊者把錯誤的 IP 塞進解析器的快取，讓使用者被導向假網站。
• DNS 劫持（Hijacking）：在傳輸過程中攔截查詢並回傳偽造結果，常見於不安全的公共 Wi-Fi。
• 網域註冊被盜：註冊商帳號被入侵後，攻擊者把 DNS 指向自己的伺服器，整站被接管。
• DDoS 攻擊：大量偽造查詢灌爆名稱伺服器，讓正常使用者查不到網址。

要降低風險，可以從幾個方向著手：DNSSEC 透過數位簽章驗證 DNS 回應是否被竄改；DoH／DoT 把 DNS 查詢加密，避免中途被看光或篡改；註冊商帳號務必開啟兩步驟驗證，並鎖定網域轉移。對企業來說，這些防護已經不是選配，而是基本功。

DNS 對 SEO 與 AI 搜尋的影響

很多人以為 DNS 跟 SEO 沒關係，其實兩者有間接但明確的連結。搜尋引擎與 AI 爬蟲要收錄你的網站，第一步就是先解析你的網域；如果 DNS 不穩、經常逾時或指向錯誤，爬蟲可能根本進不來，連帶影響收錄與排名。

一、解析速度影響載入體驗

DNS 查詢是網頁載入的第一步，解析慢會拖慢整體的首位元組時間（TTFB）與載入速度。雖然單次差異只有幾十毫秒，但慢速連線或行動網路上會放大感受。載入速度是 Google 評估使用者體驗的訊號之一，因此選擇穩定、低延遲的 DNS，對效能有正面幫助。

二、穩定性影響收錄與信任

如果網站因為 DNS 問題經常無法連線，搜尋引擎會降低對你的信任，AI 摘要也更不願意引用一個「常常打不開」的來源。維持 DNS 的穩定性與正確指向，是網站可被穩定收錄的基本條件。

三、結構化資料讓 AI 更容易引用

當 DNS 把訪客與爬蟲正確帶到你的網站後，接下來能不能被 AI 摘要引用，就取決於內容品質與結構。清楚的小標、明確的答案、可查證的來源，還有 FAQPage、Article 等結構化資料，都能提高被引用的機率。想讓 AI 主動推薦你的網頁，可以參考我們整理的 GEO Schema 關鍵技術；打好 SEO 底子則可閱讀 SEO 具體作法。

真實案例：把 DNS 調對之後發生什麼事

以下案例來自我們實際協助客戶處理的經驗，數字為約略值，用來呈現調整前後的差別，並非保證成效。

這兩個案例的共同點是：問題往往不在「網站程式」，而在「解析這一層」。DNS 出狀況時，網站可能完全正常，但使用者就是進不來。學會看 DNS 記錄，往往能省下大量的排查時間。

若你遇到「網站連不上」的狀況，不妨依序檢查：先確認伺服器本身能不能開，再用線上工具查 DNS 有沒有正確指向，最後才懷疑程式或防火牆。把 DNS 這一層先排除掉，後續找人協助時也能講得更精準，減少來回猜測的時間。

常見問題 FAQ