買一個網域,背後發生了什麼事?
從「我付了 300 元」到「全世界都能找到我的網站」,一次搞懂網域、註冊商與 DNS¶
很多人都在 Cloudflare、GoDaddy、Gandi 這類網站買過網域,一年幾百塊,按幾下就到手了。但仔細想想會冒出很多問題:這筆錢到底付給誰?如果賣我網域的公司倒了,網域會不會跟著消失?別人在瀏覽器打出我的網址時,電腦又是怎麼知道要連去哪裡?
這篇文章用一個 .com 網域當例子,把整個流程從頭講一遍。
一、你買到的其實是「租約」,不是「產權」¶
先說一個常被誤會的觀念:網域沒辦法「買斷」。你每年付的錢,買的是這個名字一年的註冊權。只要按時續約,它就一直是你的;忘了續約,過了寬限期就會被釋出,別人可以搶註。
所以與其說「我買了一個網域」,比較精確的說法是:「我向某個單位登記了這個名字,每年續租。」
二、你到底是跟誰買的?¶
網域的管理是一條四層的鏈:
ICANN(全球總管:訂規則、發執照)
└─ Registry 註冊局(管理某一個頂級網域,例如 .com 由 Verisign 負責)
└─ Registrar 註冊商(零售商,例如 Cloudflare、GoDaddy)
└─ Registrant 註冊人(你)
- ICANN:非營利的國際組織,負責整個網域系統的規則,並且核發執照給註冊局和註冊商。
- 註冊局(Registry):某個頂級網域的「正本保管者」。
.com和.net由美國公司 Verisign 管理,.tw由台灣網路資訊中心(TWNIC)管理,.dev則由 Google 管理。「這個名字屬於誰、要去哪裡找它」的權威紀錄就存在註冊局的資料庫裡。 - 註冊商(Registrar):面對一般使用者的零售通路。你在 Cloudflare 填資料、刷卡,Cloudflare 再把你的登記送進 Verisign 的資料庫,之後也幫你處理續約。
- 註冊人(Registrant):也就是你。
以 Cloudflare 一個 .com 網域為例,一年大約 10 美元出頭,錢大致這樣分:
- 絕大部分付給 Verisign:這是註冊局的批發價。
- 0.20 美元付給 ICANN:每個網域每年固定收取的管理費。
- Cloudflare 本身幾乎不賺:他們標榜「以成本價(at-cost)」銷售,靠其他服務獲利。這也是 Cloudflare 通常比其他註冊商便宜的原因。
想確認自己的網域登記在哪裡,可以到 lookup.icann.org 輸入網域。查詢結果會列出註冊商、到期日,以及 Name Server(下面會解釋)。這套公開查詢系統叫做 WHOIS,新版稱為 RDAP。
三、如果註冊商倒了,網域會不見嗎?¶
簡短的答案是:網域本身不會不見,但網站可能暫時連不上。這兩件事要分開看。
1. 網域的所有權有制度保障¶
- 紀錄不在註冊商手上:權威紀錄在註冊局(Verisign),不在註冊商手上。註冊商倒了,Verisign 的資料庫裡仍然寫著這個網域屬於你。
- 第三方資料備份(Data Escrow):ICANN 規定每一家註冊商都必須定期把客戶資料備份到獨立的第三方託管機構,這個機制叫 data escrow。萬一註冊商倒閉或被撤銷執照,ICANN 有一套標準程序,會把這家註冊商名下的所有網域整批轉移給另一家合格的註冊商,你再到新的註冊商那裡認領就可以了。
歷史背景:這套保護機制並不是憑空設計出來的。2007 年,一家叫 RegisterFly 的註冊商經營失當並倒閉,當時許多客戶差點失去自己的網域,ICANN 之後才大幅強化了相關規範。
2. 網站可能斷線,是因為 DNS 也在同一家¶
真正的風險在另一個地方。很多註冊商除了賣網域,也提供 DNS 服務,也就是負責回答「這個網址對應到哪個 IP」。Cloudflare 更是規定,在它那裡註冊的網域一定要使用 Cloudflare 的 DNS。
這代表如果 Cloudflare 整個停擺,負責指路的 DNS 也會跟著消失。網域還是你的,但別人查不到它該連去哪裡,網站就會連不上,要等你把網域轉到新的註冊商、重新設定 DNS 後才會恢復。
3. 幾個實用的自保習慣¶
- 聯絡信箱要填一個長期會用的:轉移、到期、驗證等通知都會寄到這裡,換工作或停用信箱時記得更新。
- 知道轉移碼(Auth Code)在哪裡拿:網域剛註冊或剛轉入的 60 天內不能轉出,過了之後隨時可以搬到其他註冊商。
- 開啟自動續約,並留意到期日:實際上最常讓人失去網域的原因不是註冊商倒閉,而是忘記續費。
四、全世界是怎麼找到你的網站的?¶
假設有人在瀏覽器輸入 [www.example.com](https://www.example.com),背後會發生下面這段「問路」的過程。
先說明一個小細節:www 並不是什麼特殊的東西,它只是網域底下的一個子名稱,跟 blog.example.com、api.example.com 的 blog、api 是同一類,都是你自己在 DNS 裡設定的。
一層一層往下問¶
- 第一步:問附近的 DNS 解析器(Resolver)
你的電腦會先去問一台 DNS 解析器,通常是網路業者提供的,或是 Google 的8.8.8.8、Cloudflare 的1.1.1.1。如果它最近剛查過這個網址,就直接回答;沒有的話,它會替你往下問。 - 第二步:問根伺服器(Root Server)
解析器問:「.com歸誰管?」根伺服器回答:「去問 Verisign 的.com伺服器。」全世界的根伺服器只有 13 組名稱,但每組背後都有分散在世界各地的大量實體機器。 -
第三步:問
.com的註冊局
解析器接著問 Verisign:「example.com歸誰管?」Verisign 查了自己的登記資料後回答:「這個網域的 Name Server 是xxx.ns.cloudflare.com,去問它。」核心價值:你每年付的那筆錢,買到的核心價值就在這一步——讓 Verisign 的資料庫裡有一筆紀錄,寫著「這個名字,請去問這台 Name Server」。
-
第四步:問網域自己的 Name Server
解析器最後問 Cloudflare:「[www.example.com](https://www.example.com)的 IP 是多少?」Cloudflare 照你在後台設定的紀錄回答,例如203.0.113.10。 - 第五步:連線
瀏覽器拿到 IP 之後,就直接連到那台主機,把網頁抓回來。
整趟問路通常只花幾十毫秒,而且答案會被快取一段時間,所以並不是每次開網頁都要從頭問一遍。
五、IP 是 DNS 供應商給的嗎?會永遠固定嗎?¶
這是另一個常見的誤解。DNS 供應商並不提供 IP,它只負責記住並回答你設定的對應關係。
可以把 DNS 想成一本通訊錄。你在 Cloudflare 後台寫下「www → 203.0.113.10」,Cloudflare 就照抄這筆資料,回答所有來問的人。至於 203.0.113.10 這個位址是誰的、會不會變,要看你的網站實際放在哪裡:
- 租用雲端主機(AWS、GCP、Azure 等):IP 由主機商分配。申請固定 IP(例如 AWS 的 Elastic IP)就不會變;一般 IP 則可能在主機重啟或重建時換掉。
- 用家裡的網路架站:IP 由網路業者分配。一般家用網路大多是浮動 IP,數據機重開機或業者調整時都可能改變。這時可以申請固定 IP,或者使用 DDNS,由程式自動偵測 IP 變動並更新 DNS 紀錄。
- 開啟 Cloudflare 的代理模式(後台那朵橘色雲):外界查到的不是你主機的真實 IP,而是 Cloudflare 自己的 IP。訪客先連到 Cloudflare,再由 Cloudflare 轉給你的主機。這組 IP 由 Cloudflare 維護,你不需要操心。
所以 IP 會不會變,取決於 IP 真正的主人,DNS 供應商不會自己去改你寫的紀錄。
六、改了 DNS 紀錄後,大家多久會知道?¶
這就要講到 TTL(Time To Live,存活時間)。
每一筆 DNS 紀錄都附帶一個 TTL 值,意思是「這個答案可以記住多久」。假設 TTL 設為 300 秒:
- 某台解析器查到「
www→203.0.113.10」之後,接下來 5 分鐘都會直接用這個答案,不會再去問 Cloudflare。 - 5 分鐘到了,快取過期。下一次有人要連這個網站時,解析器才會回頭重新查詢。
- 如果你在這段期間改了 IP,新的答案就是在這時候被取得的。
因此,改完紀錄之後,全世界並不是同一秒切換過去,而是在一個 TTL 的時間內陸續更新。會「重新去問」的也不是網站本身,而是散布在世界各地、各自倒數計時的 DNS 解析器。
Cloudflare 預設的 TTL 是「自動」,大約 5 分鐘,算是很短。網路上常說「DNS 生效要等 24 到 48 小時」,通常有兩個原因:
- 早期的 TTL 普遍設得很長。
- 那指的是更換 Name Server。更換 Name Server 改的是註冊局那一層的紀錄,
.com這一層的 TTL 長達兩天。
結語¶
把整件事串起來:你每年付的幾百塊,是透過註冊商這個零售通路,向註冊局續租一筆登記,內容是「這個名字,請去問這台 Name Server」。Name Server 再依照你的設定,告訴全世界這個名字對應到哪個 IP。IP 屬於真正放網站的主機,而 TTL 決定了這些答案會被記住多久。
搞懂這幾層分工之後,很多問題就有答案了:
- 註冊商倒了不必驚慌:因為名字還是你的。
- 網站突然連不上:可以先檢查 IP 是不是變了。
- 改了紀錄沒有馬上生效:等一個 TTL 就好。
- 最實際的一點:記得開啟自動續約!
Comments
Loading comments…
Leave a Comment