多數人以為網站被入侵，原因不出後台密碼被猜中、外掛出現漏洞，或主機遭到攻擊這幾種。但其實有一類事故完全不在這份清單裡，問題不在你的網站程式碼，也不在主機安全，而在一個大多數人根本不會去看的地方，DNS 裡一筆早就沒在用、卻沒有人記得刪掉的紀錄。
公司網站底下常常會多出一些「另外指去別的地方」的子網域，辦活動用的落地頁、串接的客服系統、試用過的行銷工具，都會在 DNS 設一筆 CNAME 紀錄，把子網域指到某個第三方服務。等到活動結束、試用到期，多數人會記得去把那個服務的帳號關掉，卻很少有人想到，DNS 那筆紀錄也要一起清掉。這種被留下來、指向已經不存在資源的紀錄，就是子網域接管（Subdomain Takeover）發生的起點，任何人只要在同一個服務上申請到跟你之前一樣的名稱，就能把你子網域的內容整個換成他控制的東西，不需要駭進你的主機，也不需要猜中任何密碼。
這種風險其實可以靠免費、不需要工程背景的方法自己先檢查一輪，真的出事了也有清楚的處理順序可循。
子網域接管是什麼？被遺忘的 CNAME 紀錄留下的破口
要看懂子網域接管，得先弄懂 CNAME 紀錄在做什麼。一般人比較熟悉的 A 紀錄，是把一個網域名稱指到一組 IP 位址；CNAME 紀錄不一樣，它指的是另一個網域名稱，等於幫子網域取一個「別名」，告訴瀏覽器這個子網域的內容，實際上要去問另一個網址。像是把 promo.你的網域.com 這個子網域，用一筆 CNAME 指到某個第三方服務（落地頁工具、客服系統、部落格平台）幫你代管的網址上，訪客打開 promo.你的網域.com，實際上看到的內容，就是那個第三方服務生成的。
問題出在這筆指向關係用完卻沒收。你把服務退租、帳號取消，那個第三方服務底下原本代管內容的網址就會跟著失效或被回收，但 DNS 裡那筆 CNAME 紀錄不會自己消失，它繼續指著一個已經不存在的目的地，安安靜靜地留在那裡。這種還在生效、卻指向已下架或不存在資源的紀錄，業界稱為「懸置 DNS」（dangling DNS）。
懸置紀錄本身還不算被接管，真正的接管要等到第三步。Microsoft 官方文件把整個流程拆成 3 段：第一段是「建立」，你在第三方平台佈建一個資源，再用 CNAME 把子網域指過去；第二段是「取消佈建」，那個資源被刪除或停用，這時候應該同步移除 CNAME，沒做就變成懸置；第三段是「接管」，有心人用相同的名稱在同一個服務上重新申請一個資源，流量因此被導到他手上。3 段走完，子網域顯示的內容就不再由你決定。
這裡要特別提醒一件事，子網域接管跟主機被駭、外掛出現漏洞是完全不同層次的問題。主機安全處理的是你的伺服器、你的程式碼夠不夠牢固；子網域接管完全繞開這一層，它動的是 DNS 這個更上游的環節，跟你的網站架設在哪、用了什麼 CMS、外掛更新到第幾版都沒有關係。就算你的主機固若金湯、外掛全部更新到最新版，只要 DNS 裡留著一筆懸置的 CNAME，一樣有機會被接管。也正因為它跟平常談的網站安全不是同一套邏輯，很多站主根本不會想到要去檢查這一塊。
行銷活動網頁與到期試用留下的懸置紀錄
懸置紀錄會出現，通常不是因為誰技術沒做好，而是「收尾」這個步驟本身從來沒有人真的負責。申請子網域、把 CNAME 設好是一次性的動作，通常做得很順手；但要停用一項服務的時候，記得去取消訂閱的人，往往不會同時想到 DNS 那邊也要處理。這是因為 DNS 設定多半放在網域註冊商或 Cloudflare 這類服務的後台，跟辦活動或簽約 SaaS 用的平台後台是兩個完全不同的系統，常常也不是同一個人在管。負責行銷活動的同事把工具退租了，不代表他有權限，甚至根本不知道還要去改 DNS。以下幾種情境，是台灣中小企業站主最容易踩到的。
活動結束後沒人收尾的行銷落地頁
辦活動、推新品、辦講座時，不少公司會另外申請一個好記的子網域，例如 campaign.你的網域.com，指到外部的落地頁工具或行銷平台去代管內容。這麼做的好處是網址一看就知道是官方活動，也不用動用工程資源在自己主機上另外架頁面。
問題是活動一結束，網頁多半就直接下架，但那筆指向外部工具的 CNAME 紀錄常常沒人記得清。這類臨時性的頁面代管服務，大多允許任何新使用者用還沒被佔用的名稱重新申請，一旦你原本用過的名稱被放掉，任何人都能重新申請到同一個名稱，把你的子網域接管過去。也因為活動頁多半上線幾週就完成階段任務，這類懸置紀錄反而是最常出現、卻最少被回頭檢查的一種。
到期或退租後留下 CNAME 的免費試用服務
申請客服系統、電商平台、行銷自動化工具的免費試用時，廠商常會要求你先設定自訂網域，把 CNAME 指過去，才能把品牌識別接進你自己的網域下，而不是用一長串陌生的網址。這一步通常是廠商引導你一步步做完的，設定起來很順手。
問題出在試用期滿之後。如果沒有繼續訂閱，帳號多半會被系統自動關閉或凍結，你自己申請的那個服務實例也會跟著被回收，但 DNS 裡幫你把子網域指過去的那筆 CNAME，不會被廠商同步清掉，也很少有人會想到要自己回頭刪。這種紀錄放著放著，就變成一筆等在那裡的懸置紀錄。挑選任何會用到自訂網域的第三方服務時，值得先留意一件事，這家廠商允不允許別人重新申請到你曾經用過的名稱，這個問題的答案，某種程度上就決定了你之後的風險高低。
搬家或換主機後沒清掉的舊指向
換主機商、換 CDN，或是把原本外包給第三方服務的某個功能搬回自己主機管理，是另一種常見情境。這種時候大家通常會很仔細地處理主網域的 A 紀錄，確認網站搬過去之後能正常連上，卻容易漏掉當初為了某個子功能，另外設的那筆子網域紀錄。
原因不難理解，搬家是件大工程，主網域關係到整個網站能不能打開，自然會被放在最優先的位置盯著；至於某個子網域幾年前為了什麼功能設過一筆 CNAME，可能連經手的人都已經不記得，更別說是接手的新團隊。這類舊指向留下的懸置紀錄，往往要等到很久之後，有人無意間打開那個子網域，才會被發現。
用完忘記關閉的內部測試和 demo 頁面
工程師或外包廠商為了測試新功能、跑簡報 demo，常會臨時申請一個子網域接到雲端服務，把成果展示給團隊或客戶看。這種頁面通常帶著臨時的性質，一開始就沒被排進任何正式的上線或下架流程。
事後多半沒人會特別追蹤這種非正式建立的子網域。開發人員可能只是做完展示就把資源砍掉，轉頭去忙下一個專案，而管理 DNS 的人根本不知道有這筆紀錄存在，更不知道對應的資源已經被移除。這種「影子 IT」（shadow IT）式的臨時建置，正是懸置紀錄持續出現的常見成因之一，根本原因在於建立資源的團隊常常沒有 DNS 管理權限，管理 DNS 的人也不知道資源已經被拆掉，兩邊的資訊完全對不上。
懸置的子網域足以讓攻擊者冒充你的網站行騙
如果子網域被接管的後果只是打開會看到一頁奇怪的錯誤訊息，問題其實不大。真正麻煩的是，攻擊者拿到的不只是一個網址，而是你網域名稱本身帶來的信任。
接管之後，對方能做的事情不只一種。最直接的是置換內容，把子網域的畫面換成他想放的任何東西，毀掉品牌形象。2017 年 2 月，美國前總統川普的競選募款網站底下，有一個子網域被駭客接管，對方把整個頁面換成自己的入侵宣告，貼上一張戴帽人物的圖片與駭客代號的文字。事件雖然很快被處理掉，還是造成了公開的難堪與品牌傷害。
更危險的用法是架釣魚頁。因為網址列顯示的就是你自己的網域，讀者根本沒有理由懷疑，加上攻擊者還能用這個被接管的子網域，申請到一張合法有效的 SSL 憑證，瀏覽器一樣會顯示綠色鎖頭。這點恰好戳破一個常見的誤解，很多人以為看到鎖頭圖示就代表網站安全，但 Microsoft 官方文件說得很直接，威脅行為者一樣可以使用被綁架的子網域來申請並取得有效的 SSL 憑證，而有效的 SSL 憑證能讓他們存取安全 Cookie，還會讓人更加相信這個惡意網站合法可信。
Cookie 這件事即使不懂技術也能理解它的原理。瀏覽器判斷要不要把某個 Cookie 送給一個網址，靠的只是網域名稱對不對得上，不會去分辨這是不是原本的你。如果你的網站把登入用的 Cookie 設定成整個根網域下的所有子網域共用，瀏覽器就會把這個 Cookie 一併送給被接管的那個子網域，就算這個 Cookie 標了只能透過加密連線傳送，也擋不住，因為被接管的子網域本身一樣有合法的 HTTPS。
同樣的信任機制，也可能讓只檢查請求是不是來自同一個網域的防護機制、或是設定給整個子網域範圍使用的安全政策，一起跟著失守。如果這個子網域還牽涉到收信，例如設過 MX 紀錄，攻擊者甚至能收到原本要寄給這個子網域的信件。
懸置紀錄最讓人心慌的一點，是它可能放著好幾年都沒人發現，不是設定完隔天就會出事，但也正因為不會馬上出事，才更容易被忽略。國際資安研究公司 Guardio Labs 在 2024 年 2 月發布的一份調查報告，揭露一起大規模的子網域挾持垃圾郵件行動，鎖定超過 8000 個網域、13000 個子網域，受害品牌包含 MSN、VMware、McAfee、The Economist、康乃爾大學、CBS、Marvel、eBay 等知名機構，整起行動每天發送超過 500 萬封惡意郵件。
報告裡最能說明懸置紀錄可以放多久沒人發現的，是 MSN 底下一個叫 marthastewart.msn.com 的子網域。它的 CNAME 早在 2001 年一場行銷活動結束後就被放著沒人管，整整 21 年沒有人處理，直到 2022 年 9 月才被攻擊者重新申請取得控制權，並藉此偽造出寄件網域就是 msn.com、還能通過 SPF、DKIM、DMARC 驗證的詐騙郵件，讓這些信被信箱系統判定為合法來信，直接送進收件人的主要信箱。
檢查懸置子網域的 3 個免費方法
知道原理之後，下一步是怎麼確認自己的網域底下有沒有中標。好消息是，這件事完全不用買任何資安服務，也不需要懂程式，靠 3 個免費、由淺入深的方法就能先做一輪初步檢查。
先盤點網域底下所有子網域紀錄
很多中小企業其實根本不清楚自己網域底下設了幾個子網域，不少是幾年前某次活動、或是已經離職的人設下的，連現在的團隊都不知道存在。檢查的第一步，永遠是先把清單列出來，登入你的網域註冊商或 DNS 服務（如 Cloudflare、GoDaddy）後台，把 DNS 區域裡所有的 CNAME 紀錄整理成一張表，記下這個子網域指到哪裡、是哪個部門或哪個人在用。
盤點時多記幾件事，比只列出名字有用得多。國際資安組織 OWASP 的防範指南建議，至少要記錄 4 件事：這筆紀錄指到什麼資源、哪個團隊擁有這個資源、屬於哪個專案或服務、以及什麼時候建立、預計何時該下架。文件裡特別提到，對規模不大的組織來說，一份簡單的試算表就足夠，不需要正式導入複雜的管理系統。把這份清單做出來，後面兩步才知道要檢查哪些網址。
打開子網域網址，錯誤訊息就是最直接的線索
清單列出來之後，把每一個子網域網址直接貼到瀏覽器打開，看它回應什麼畫面。如果看到的不是你熟悉的正常頁面，而是某種「找不到」、「這個帳號不存在」之類的服務商錯誤頁，那就是「DNS 還指著、但資源已經不在了」最直接的訊號。這是判斷懸置紀錄最直覺、也不需要任何工具的方法。
不同服務被刪除之後，顯示的錯誤訊息各有固定的樣子，認得這些訊息能幫你更快判斷。OWASP 整理出一張常見服務的錯誤訊息對照表：AWS 的雲端儲存服務 S3 會顯示「找不到指定的儲存空間」；GitHub Pages 顯示「這裡沒有 GitHub Pages 網站」；Heroku 顯示「沒有這個應用程式」；Azure 的網頁服務回應「找不到這個網站」；Shopify 顯示「抱歉，這間商店目前無法使用」；Netlify 顯示「找不到」，並附一組請求編號；Zendesk 的說明中心顯示「說明中心已關閉」。看到這類頁面，就代表該資源已經被刪除、但 DNS 紀錄還留著，是最該優先處理的訊號。
用系統內建指令揪出解析失敗的 CNAME
如果你想再多驗證一次、更放心，Windows 與 Mac 都內建可以查詢 DNS 的指令，像是 nslookup 或 dig。做法是先查子網域網址，看它的 CNAME 實際指到哪個目的地，再拿那個目的地本身去查一次。如果查不到結果、系統回應「找不到這個網域」之類的訊息，就代表 CNAME 指向的目標已經不存在，是懸置狀態。這一步可以跟前一步的肉眼判斷互相印證，避免只看網頁畫面就誤判。
資安廠商 CrowdStrike 官方部落格提到，攻擊者實際上就是用被動與主動掃描技術找出一個組織的子網域，再逐一比對 DNS 紀錄，判斷哪些還在使用、哪些已經棄置，換句話說，你自己也可以用同一套邏輯先一步檢查。OWASP 的測試指南把判斷準則寫得更精確，用 dig 這類工具查詢時，如果得到 NXDOMAIN（表示這個網域根本不存在）、SERVFAIL 或 REFUSED 這幾種回應，就是懸置紀錄的訊號，代表 CNAME 指向的目標已經失效。
移除 CNAME 早於關閉服務，才能堵住這段空窗
查出自己有懸置紀錄、但還沒被接管的情況，接下來要處理的重點不是急著清掉，而是順序要對。多數人的直覺是先去把不用的服務、帳號取消掉，這個順序剛好是錯的，會留下一段空窗期讓別人有機可乘。
正確的做法反過來，先處理 DNS，服務留到最後才關。AWS 的資安部落格把這個原則寫成一條很清楚的鐵律，永遠先刪除 DNS 紀錄、等待 TTL 過期，才刪除底層資源，這個順序能消除懸置紀錄可能被利用的空窗期。原因跟 DNS 快取有關，DNS 解析器會把紀錄快取一段時間，也就是 TTL，如果設定的 TTL 是 3600 秒，代表解析器最多可能繼續使用舊紀錄長達一小時。如果在 TTL 還沒過期前就先刪掉資源，即使 DNS 紀錄本身也同時被刪除，仍可能有人透過快取的舊紀錄接觸到那段空窗，而這正是攻擊者可以趁虛而入的時機。
OWASP 的防範指南把這個原則拆成更完整的步驟，先在該子網域顯示一個維護頁面或做轉址，避免使用者突然看到打不開的畫面；接著更新或移除指向該資源的 DNS 紀錄；然後等待 DNS 傳播，通常要等 300 到 3600 秒的 TTL 時間；最後才真正下架雲端資源、取消訂閱服務。文中特別點名最常見的錯誤做法，就是順序顛倒，先刪除雲端資源，這樣會立刻製造一段可被接管的空窗，一路持續到有人發現懸置紀錄為止。
還有幾件實務上的細節值得留意。如果一查就急著把資源整個刪掉，反而是最危險的動作，寧可先把子網域轉往一個你自己控制的位置，確認安全之後再慢慢處理。如果這個子網域其實還有用，只是換了一個新的服務，做法應該是直接把 CNAME 更新指向新的正確目的地，而不是刪掉之後晾在那裡等你之後再想。
處理完之後，記得再用前面教的方法查一次，確認這個子網域確實已經不再指向任何懸置的目標。整個 DNS 設定牽涉的東西不少，如果你自己不熟悉怎麼操作後台，交給網站維運的工程師或主機商協助處理，會比自己憑印象亂刪一筆紀錄、甚至誤刪整個 DNS 區域安全得多。
移除紀錄是接管發生後最快的止血動作
如果打開子網域看到的已經不是你原本的內容，或是已經有人反映收到疑似從這個網域寄出的可疑信，代表可能已經被接管，這時候動作要快，但不必自亂陣腳。
第一步永遠是立刻移除或更新那筆 DNS 紀錄，這是切斷攻擊者存取管道最快、也最直接的方式。如果暫時沒辦法馬上處理刪除，先把它改指向你自己控制的位置，至少先讓攻擊者拿不到內容的主導權。
接下來要查一下，這段被接管的期間，有沒有人用這個子網域申請到 SSL 憑證。這件事任何人都可以自己動手查，透過免費公開的憑證透明度紀錄工具，就能查到某個網域名稱底下核發過哪些憑證，如果發現有核發給不明對象的憑證，視情況要求憑證單位撤銷。
再來要回頭評估這個子網域過去有沒有牽涉登入功能、會不會跟主網站共用 Cookie。如果有，就要比照帳號有風險時的處理方式，提醒使用者、必要時協助重設密碼，不能因為只是一個子網域出事，就當作跟主站的使用者資料無關。如果有證據顯示使用者資料、帳密或連線階段真的被暴露，也要通知受影響的使用者。
最後兩件事同樣重要，卻最容易被忽略。一是檢討這次事故的根本原因，找出當初讓這筆紀錄變成懸置狀態的流程漏洞在哪裡，而不是處理完這一個子網域就結束。二是回頭掃一遍同一個網域底下，還有沒有其他懸置的子網域，造成這次疏忽的流程問題，很可能同樣存在於其他子網域上，同樣的錯誤往往不會只發生一次。整個處理過程建議找懂 DNS 與資安的人一起確認，尤其是憑證撤銷與影響評估這幾步，自己判斷容易漏掉一些細節。
收站清單、定期健檢杜絕接管重演
把前面各節的做法收斂成幾件可以持續執行、不需要專職資安人力也做得到的習慣，重點不是花錢買工具，而是把 DNS 收尾這個步驟正式排進日常流程裡。
先建立好資源，再把 CNAME 接上去
佈建一個新子網域時，順序值得反過來想。多數人習慣先把 DNS 設好、等著之後再慢慢把資源建起來，正確的做法應該相反，先在第三方平台把服務建好、確認能正常運作，最後一步才去設定 DNS 指過去。下架的時候邏輯同樣相反，先動 DNS、資源留到最後才關。單單把這個順序調過來，就能大幅縮小可能被接管的時間窗口。
挑選任何會用到自訂子網域的第三方服務時，也該把這一點納入評估標準，這家廠商會不會讓別人重新申請到你曾經用過的名稱。開發者資安部落格 Honeybadger 引用資安研究者 James Kettle 的提醒，很多公司的子網域指向由第三方代管，但那些第三方的資安做法並不嚴謹。與其事後才發現問題，不如把每一個允許自訂網域的外部服務，都當成一項需要持續管理的風險來看待，而不是設定完就不再過問。
收站先移除紀錄，服務留到最後才關
把前面提到的正確順序，變成收尾時的固定習慣。服務不用了、活動結束了，第一個動作永遠是回頭檢查並清掉對應的 DNS 紀錄，而不是在後台按下「取消訂閱」或「刪除」就當作結束了。
一份完整的下架流程，大致包含以下幾個環節：
- 找出這個服務相關的所有 DNS 紀錄，包括 CNAME、A、MX、NS
- 視情況先導向一個維護頁面，避免使用者看到打不開的畫面
- 移除或更新 DNS 紀錄
- 等待 TTL 過期
- 才真正下架資源
- 讓核發過的憑證自然過期，或主動申請撤銷
- 更新自己的子網域清單紀錄
- 把這個子網域從任何登入授權清單、安全政策設定裡一併移除
- 確認子網域已經不再回應原本的內容
- 用前面教過的方法再測一次，確認它已經無法被任何人接管
這幾個環節看起來瑣碎，但每一項都對應著前面提過的某個風險，做完一輪，才算真正把尾收乾淨。
一份簡單清單，記錄每個子網域的負責人與到期時間
延續前面盤點做出來的那份紀錄，把它變成一份長期在用的文件，而不是查過一次就丟著。每新增一個子網域就加進這份紀錄，每次要辦新活動、申請新服務前，也先看一眼這份紀錄裡有沒有可以重複利用的舊子網域。固定一個頻率，例如每一季，重新檢查一次整份紀錄，對照看看有沒有已經不再使用、卻還留在 DNS 裡的紀錄。
如果你用的平台本身有提供網域驗證機制，申請的時候就順手一併設好。這通常是額外多加一筆 TXT 紀錄，用來證明這個網域確實是你的，即使日後不再使用這項服務，也建議把這筆驗證紀錄留著，避免別人的帳號之後能夠重新聲稱這個網域。OWASP 的防範指南提醒，在沒有提供網域驗證機制的服務上，DNS 紀錄本身就是唯一的防線，下架時能不能確實移除，是保護自己的唯一辦法。
子網域接管之所以容易被忽略，不是因為技術上有多難防範，而是因為它躲在一個多數人根本不會定期回頭看的角落。DNS 設定完成之後，很少有人會再打開後台去看那些早就用不到的紀錄還在不在，這也是它能一放好幾年都沒人發現的原因。真正能防住這件事的，從來不是某個高深的資安工具，而是把「用完就收」這個習慣，確實落實到 DNS 這一層，跟關掉服務帳號同樣認真。花一次時間把清單整理出來，之後每一季花十分鐘檢查一次，子網域接管這種本來可以完全避免的風險，基本上就與你無緣了。