有一天，你的某個子網域開始提供攻擊者的內容，而沒有人碰過你的伺服器。修補程式、驗證和監控在這裡都幫不上忙。原因不是入侵，而是你忘了刪除的東西。
實際上發生了什麼（三個階段）
1. 建立
你建立一個帶有完整網域名稱（app-xxxx.<服務商網域>）的雲端資源，並在你的區域中新增 CNAME 紀錄，讓sub.example.com指向它。2. 除役（只做了一半）
不再需要時，資源被刪除了。這時sub.example.com的 CNAME 也應該一起移除，但沒有。它仍被當作有效的網域公告，卻指向不存在的東西：這就是懸置的 DNS 紀錄（dangling DNS）。3. 接管
攻擊者發現了這個懸置的子網域，並建立一個與你過去控制的相同 FQDN 的資源。從此之後，送往sub.example.com的流量都抵達他們的資源，內容由他們決定。
你的 DNS 區域（沒有變更）
sub.example.com CNAME→ app-xxxx.provider.example
↓ 只有目標被移除
雲端資源：已刪除
這個名稱回到任何人都能取得的狀態
↓ 攻擊者建立同名資源
攻擊者的資源（他們的帳號）
sub.example.com 提供什麼由他們決定。你的伺服器從未被碰過
CNAME 是弱點，因為它指向的是名稱
A 紀錄指向位址，而 CNAME 指向名稱，在許多雲端服務上，那個名稱是先搶先贏的。你一放手，別人就能拿走。文件說 CNAME 紀錄「特別容易受到這種威脅」。同樣的道理也適用於 MX 紀錄，結果是寄往那個子網域的郵件可能被別人收走。
損害不只是一個看起來很假的頁面
- 失去子網域的控制權
- 你沒有管理的內容從你自己的網域提供，造成品牌損害和信任流失
- 收集 Cookie
- 網頁應用程式常透過萬用字元（
*.example.com）把工作階段 Cookie 開放給子網域，任何子網域都能存取。被接管的子網域上一個逼真的頁面，就能從訪客那裡收集它們，包括標記為 Secure 的 Cookie - 用於網路釣魚
- 因為網域查證起來是真的，從那裡發出的網路釣魚說服力高得多
最大的誤解：「有 HTTPS，我們有憑證」
文件把這點列為常見的誤解並加以否定：持有被接管子網域的攻擊者，可以申請並取得該子網域的有效憑證。網域驗證型憑證檢查的是申請者在那一刻是否控制著那個名稱，所以它不會偵測到控制權易手。
結果是，有效的憑證反而幫了攻擊者：出現鎖頭圖示、標記為 Secure 的 Cookie 照樣送出，假網站看起來更正當，而不是更可疑。請把憑證理解為「誰持有這個名稱」，而不是「我在跟誰說話」。
如何預防：把先移除 DNS 紀錄寫進程序
原因不是技術上很難，而是除役步驟的順序。如果先刪資源、之後才刪 DNS，子網域就可能在這段期間被接管。
會出事的順序
刪除資源 → 之後再處理 DNS → 忘了
這段期間 DNS 一直公告著一個運作中的正當子網域。監控不會告訴你有伺服器停了，因為根本沒有東西停掉。
安全的順序
先移除 DNS 紀錄 → 再刪除資源
文件建議對有自訂 DNS 項目的資源套用刪除鎖定，因為鎖定本身就提醒在資源除役前必須先移除對應；同時也指出，這類措施只有搭配內部教育才有效。
把「移除 DNS 項目」列入除役檢查清單
這是文件提出的第一個預防步驟：把它列入服務除役時的必要檢查項目，並教導開發人員在刪除資源時一併移除 DNS 紀錄。重點是不要把順序交給任何人的記憶。
讓紀錄的生命週期與資源綁定
有些服務商提供與資源本身綁定的紀錄類型（別名紀錄等）。刪除資源後，紀錄會變成空集合，所以不會留下指向不存在之物的紀錄。適用範圍限於部分服務，但能用的地方就用：它用設計而不是程序來防止忘記刪除紀錄。
要求證明擁有權
有些服務允許你為自訂網域發布用來驗證擁有權的 TXT 紀錄。有這種紀錄時，其他訂閱就無法驗證或接管那個自訂網域。它擋不住別人建立同名資源，但無法證明擁有權就收不到你的流量。只有能證明擁有權的人才能使用那個名稱，而不是先搶到的人。
定期檢查 DNS 區域：它存在嗎？是你的嗎？
文件提出兩項檢查：目標是否存在、是否為你所擁有。第二項最重要，因為**「有回應所以沒問題」不算檢查**，來自別人資源的回應正是這種攻擊。請維護一份把 FQDN 端點對應到負責人的服務目錄，並定期匯出，作為資產盤點的一部分。
發現時，不要只刪除紀錄就結束
修復步驟還要更進一步：更新應用程式碼中過時的子網域參照、調查是否發生了入侵，並找出除役時為什麼沒有移除紀錄，避免再次發生。特別是如果你的應用程式邏輯曾把 OAuth 認證資訊等機密或涉及隱私的資訊送到那個懸置的子網域，這些資料可能已經暴露給第三方。
本站的看法：暴露更常來自你停用的東西，而不是你建立的東西
資安討論往往集中在正在建立的東西上，而入侵卻常從已經退役、被遺留下來的東西開始。沒人在用的子網域、離職同事的帳號、為一次實驗建立的測試環境、解約後仍保留的會員資料，它們的共同點是「已經不用了」會悄悄地讓某樣東西脫離監控和審查。停用的東西在被刪除之前，仍然是資產。所以我們主張盤點的範圍要涵蓋你曾經建立的所有東西，而不只是目前在運作的。解約後才發現自己仍在服務商外洩範圍內的人，就是同一個問題的例子（主機服務商遭入侵時該怎麼做）。
資料來源（一手資料）
- Microsoft「Prevent dangling DNS entries and avoid subdomain takeover」（Microsoft Learn／Azure 安全性基礎）— learn.microsoft.com（三個階段、CNAME 特別容易受害的原因、Cookie 收集與 MX 紀錄、對憑證誤解的否定，以及預防與修復步驟：刪除鎖定、別名紀錄、擁有權驗證、定期檢查，全部出自這份文件）
接著讀
FAQ
Q子網域被接管，代表我的伺服器被入侵了嗎？
不是，這正是麻煩的地方。被接管的是 DNS 指向的地方，而不是你的伺服器。如果你刪除了雲端資源，卻把 CNAME 紀錄留在 DNS 區域中，第三方只要在自己的訂閱下建立相同完整網域名稱的資源，原本要送到你子網域的流量就會抵達他們那裡。修補程式、驗證和監控在這裡都幫不上忙，因為它們都沒有參與其中。
QHTTPS 不能防止這件事嗎？有憑證應該就安全了吧？
不能，而且 Microsoft 的文件直接把這點列為常見的誤解：持有被接管子網域的人，可以申請並取得該子網域的有效憑證。網域驗證型憑證只證明持有者此刻控制著那個名稱，它不說明對方是誰，也不會偵測到控制權易手。有效的憑證反而對攻擊者有利，讓假網站看起來更正當。
Q如果只影響外觀，損害應該有限吧？
工作階段會外洩。網頁應用程式常透過萬用字元（*.example.com）把工作階段 Cookie 開放給子網域，這種情況下任何子網域都能讀取。如果能把使用者引導到被接管的子網域，即使是標記為 Secure 的 Cookie 也可能落入攻擊者手中。而懸置的 MX 紀錄，代表寄往那個子網域的郵件可能被別人收走。
Q實際上要怎麼預防？
把刪除順序變成程序和機制，而不是靠人記得。文件建議：把「移除 DNS 項目」列入服務除役時的必要檢查清單；對有自訂 DNS 項目的資源套用刪除鎖定，讓鎖定本身提醒必須先處理 DNS；在可用時使用生命週期與資源綁定的紀錄類型；並定期檢查 DNS 區域，確認每個目標都存在、而且是你擁有的。