DNS 是什麼：網域、主機、信箱怎麼串在一起

DNS（網域名稱系統）是網路上的查詢系統：有人打開你的網址、寄信到公司信箱時，DNS 負責回答「網站放在哪台主機」「這個網域的信要送到哪台郵件伺服器」。網域、DNS、網站主機與企業信箱其實是四樣東西，可以分別交給不同廠商；把它們串起來的，是網域上設定的名稱伺服器（NS），以及名稱伺服器裡的一筆筆 DNS 記錄。搞清楚每一樣在誰手上、帳號登記在誰名下，換廠商或出狀況時，才知道該找誰、去哪裡改。

以下是幾種常見情況的示意，不是真實客戶案例，用來幫你判斷該先讀哪一段、先做哪件事。

• 會計師事務所的行政人員，被新網站廠商要求「去改 DNS」：一間十人左右的事務所委託新廠商重做官網，廠商請行政把 DNS 指到新主機。行政不知道 DNS 在哪裡設定，最怕改錯後收不到客戶寄來的報稅資料。先讀「名稱伺服器與 DNS 記錄」那段，查出目前名稱伺服器在哪一家，再請廠商講清楚要改的是哪一筆記錄，而不是直接把整組名稱伺服器換掉。
• 食品進口商想把信箱換成雲端郵件，網站留在原主機：一家二十多人的進口貿易公司，業務常抱怨信箱容量不夠，老闆想改用雲端郵件，但官網剛改版，他擔心換信箱會讓網站跟著停擺。先讀「為什麼網站和信箱可以放在不同家」，了解收信是由 MX 記錄決定，換信箱只動郵件相關的記錄，再確認舊的 MX 怎麼收尾。
• 設計工作室老闆發現網域和 DNS 都在離職同事的帳號下：一間五人的室內設計工作室，當初由一位同事用自己的帳號申請網域、設定 DNS，後來他離職了。老闆想新增一個子網域放作品集，才發現沒人登得進去。先讀「DNS 該交給誰管、帳號要在誰名下」，接著用「公司網路資產對照表」盤點還有哪些服務綁在個人帳號上。

電腦靠一串數字的 IP 位址找到彼此，人記得住的卻是網址，DNS 就負責兩者之間的對照。IETF 的 DNS 基礎規範 RFC 1034 把 DNS 分成三個部分：以樹狀結構組織的名稱與記錄、保存這些資料的名稱伺服器，以及替使用者程式向名稱伺服器查資料的解析器。對照到日常操作，一次查詢大致是這樣走的：

1. 先問解析器：電腦或手機把網址交給解析器，通常由公司網路或電信業者提供。
2. 從根伺服器問起：解析器手上沒有現成答案時，先問根伺服器。根伺服器不知道你網站的位址，但知道 .tw、.com 這些頂級網域由哪些名稱伺服器負責。
3. 頂級網域指路：頂級網域的名稱伺服器回答「這個網域由哪幾台名稱伺服器負責」。這份資料，就是你在註冊商設定的名稱伺服器。
4. 權威名稱伺服器給答案：負責你網域的名稱伺服器回覆網站位址、收信伺服器等記錄。RFC 1034 稱這類伺服器是該區域的權威（authority），資料以它為準。
5. 答案被暫存：解析器把答案放進快取，下次有人問同一個網址就直接回答，不必重查。

第五步說明了很多人遇過的現象：DNS 改完後，有人看到新網站、有人還看到舊的。RFC 1034 把 TTL 定義為一筆資料可以留在快取中的時間上限，各地解析器暫存的時間點不同，所以變更是陸續生效，不會一按儲存就全世界同步。只要其中某一環斷掉，例如網域到期被停止解析、名稱伺服器沒人維護，網站和信箱就會同時「找不到」。

小公司常由一家廠商包辦，角色容易混在一起；要換廠商或排除問題時，就得分清楚每一層歸誰管：

依 ICANN 對註冊流程的說明，註冊人要修改網域設定，是向註冊商提出，再由註冊商送到註冊管理機構；註冊條件、費用與續約，都由你和註冊商之間的註冊協議決定。所以網域的事幾乎都找註冊商。容易混淆的是經銷商：你付錢的對象可能只是代賣網域的廠商，背後另有註冊商。ICANN 說明經銷商受它與註冊商之間的合約約束，本身不經 ICANN 認可。查詢結果顯示的註冊商名稱和你付款的公司不同，多半就是這種情況。

這一段只要記住一句話：DNS 記錄要改在名稱伺服器指向的那一家，不一定是你付網域費用的那一家。

名稱伺服器設定在註冊商後台，經由註冊商送到註冊管理機構，對外宣告「這個網域的資料去問這幾台」。RFC 1034 把上層區域用來標示下層由誰負責的 NS 記錄，視為授權的分界。網站、收信、驗證用的各筆記錄，則放在那幾台名稱伺服器上，由營運它們的 DNS 代管服務管理。換句話說，名稱伺服器決定「誰說了算」，DNS 記錄決定「說了什麼」。這個分層，造成三種常見誤會：

• 在甲家改了記錄，網站卻沒變：註冊商後台多半也有 DNS 管理畫面，但名稱伺服器若已指到主機商，這邊改的記錄沒有人會讀。先查名稱伺服器，再到對應的後台修改。
• 只想換網站主機，卻把名稱伺服器整組換掉：新主機商常請客戶把名稱伺服器改成它的。這等於把整個網域的 DNS 搬家，舊名稱伺服器上的收信記錄與各種驗證記錄，若沒有先在新家建好，信箱和其他服務會一起中斷。只換網站時，保留原名稱伺服器、只改網站那筆記錄，影響範圍較小。
• 以為名稱伺服器只有一台：RFC 2182 指出，DNS 規範與註冊規則要求每個區域至少兩台名稱伺服器，並應分散在不同網路與地點，多數組織層級的網域建議三台。所以看到兩組以上是正常的，修改時要整組一起換。

怎麼查目前的名稱伺服器？.com 等通用網域可用 ICANN 的查詢服務 lookup.icann.org，2025 年 1 月 28 日起 RDAP 已是通用網域註冊資料的正式來源；.tw 網域可用 TWNIC 的 WHOIS（whois.twnic.net.tw）。查詢結果中的 Name Server 欄位就是答案，名稱伺服器的網址通常帶著服務商自己的網域，可以藉此判斷 DNS 實際在哪一家。

DNS 裡不同用途的記錄彼此獨立，所以網站和信箱可以分別交給不同廠商，互不干擾。RFC 1034 對兩種最關鍵的記錄寫得很清楚：A 記錄是主機位址，MX 記錄指出替這個網域收信的郵件交換伺服器。

因此「網站放虛擬主機、信箱用雲端郵件」是很常見的安排：A 記錄指向網站主機，MX 記錄指向郵件服務，兩邊各改各的。以 Google Workspace 為例，Google 的說明是用一筆 TXT 記錄驗證網域；Let's Encrypt 這類憑證機構，也有以 DNS 的 TXT 記錄確認網域控制權的驗證方式。

分家時有兩個容易踩的坑。第一，MX 可以有好幾筆，依 RFC 5321，寄件端會依優先值排序，數字越小越優先；換郵件服務時，舊的 MX 要確實移除，否則部分信件可能仍被送往舊伺服器。第二，MX 不是刪掉就沒事：RFC 5321 規定，查不到任何 MX 時，寄件端會把網域本身當成收信主機，信件可能因此送到網站主機。網站主機沒開信箱，信就會被退回或下落不明。換信箱或停用信箱，請先確認新的 MX 已經建好並生效，再處理舊的。

DNS 代管沒有標準答案，常見三種安排各有取捨：

選擇時先想清楚：以後最常改 DNS 的是誰？哪天要離開，能不能完整匯出所有記錄？

比「交給誰」更重要的，是帳號歸屬。網域的註冊人應該是公司，而不是員工或外包廠商；ICANN 也要求註冊人提供正確的聯絡資料、資料變動時即時更新、在 15 天內回覆註冊商的詢問，使用自動續約的話要維持付款資訊有效。DNS 代管、主機、信箱的管理帳號，最好用公司長期有人收信的共用信箱開設，再把操作權限開給負責的同事或廠商，不要讓廠商用自己的名義持有帳號。如果網域或 DNS 已經卡在離職員工、失聯廠商手上，請參考外包廠商失聯時拿回網域與主機管理權的處理步驟。不確定現況該怎麼調整，也可以請我們協助評估。

各項服務的帳號、到期日與窗口不同，最實用的做法是在試算表整理成一張表：

每一列再加兩欄：公司內的負責人，以及外部廠商窗口。填表的順序建議如下：

1. 列出所有網域：只做轉址或保護品牌的網域最容易被遺忘。
2. 逐一查註冊資料：註冊人不是公司的，標成優先處理。
3. 依名稱伺服器找到 DNS 後台：登入確認帳號還能用，把所有記錄匯出或完整截圖存檔。
4. 替每筆記錄標上用途：網站、收信、哪個服務的驗證。看不懂的記錄先保留，不要因為「好像沒用」就刪掉，它可能是某個服務正在使用的驗證。
5. 對照合約與帳單：補上主機、信箱、憑證的到期日，順便確認續約通知會寄到誰。
6. 定期更新：換廠商或人員異動時更新；密碼不要寫在表上，另用密碼管理工具保存。

不論是要釐清現況、換信箱，還是把分散的服務收攏，先備好下面這些資料，討論時才能直接判斷要動哪一層：

• 公司所有網域的清單，以及你查到的註冊商、到期日與名稱伺服器。
• 能登入的後台有哪些：註冊商、DNS 代管、主機控制台、信箱管理後台，各由誰保管。
• DNS 後台目前所有記錄的匯出檔或截圖，看不懂的記錄也一併附上。
• 網站與信箱各在哪家服務商、合約何時到期。
• 這次想達成的目標，例如只換信箱、只換網站主機，或把網域與 DNS 轉回公司名下。
• 有沒有其他服務曾要求在 DNS 加驗證記錄，例如雲端郵件、網站分析或廣告工具。
• 若網站或收信已經異常，開始的大約時間與錯誤畫面截圖。
• 公司內誰有權決定更換名稱伺服器或郵件服務，避免改到一半卡在內部確認。

凱斯騰可以協助的範圍包括：透過網域註冊與 DNS 代管整理網域與記錄、把網站放上虛擬主機，以及規劃企業郵件或雲端郵件的切換順序，讓網站和信箱在調整過程中盡量不受影響。資料整理好之後，請填寫聯絡表單，或來信 [email protected]，說明你的網域與想處理的事項。

• DNS 記錄設定教學：A、CNAME、MX、TXT 怎麼設
• 換主機後網站或信箱異常：DNS 生效時間與排查順序
• 網域註冊：網域申請、續約與 DNS 代管
• 企業郵件：用公司網域收發信，MX 設定有人負責
• 網域到期沒續約：停止解析、贖回期與被搶註
• 拿回網域管理權：外包廠商失聯時的處理步驟