AWS企業帳號購買 如何配置 Route 53 子域名權限授權

前言：你到底在做「權限授權」的哪一種事

很多人說「Route 53 子域名權限授權」，但實務上你通常是在做 DNS 委派（delegation）。委派的意義很單純：父網域（例如 example.com）把某個子網域（例如 dev.example.com）的權威 DNS 權交出去，讓子網域改由另一套 DNS 服務來回答查詢。這不是在控制「誰有存取權」，而是讓解析（resolution）走向正確的權威來源。

因此，你會遇到兩種常見需求：第一種是你不想自己管理子域名的 DNS，由別人（另一個 AWS 帳號、另一套 DNS 供應商或公司）管理；第二種是你雖然在 Route 53 上管理，但需要把權限授予給其他 AWS 帳號去改某些資源。兩者都能說成「授權」，只是技術落點不同。

接下來的文章會用「委派」作為主軸，並在合適的位置補上「IAM/跨帳號權限」該怎麼配，讓你能在真實專案裡把事情做對。

核心概念：父域、子域與權威

父域委派子域：NS 記錄才是關鍵

DNS 的信任鍊是從根（root）一路下來。當你在瀏覽器輸入 app.dev.example.com，遞迴解析器最後會問：誰負責 dev.example.com？答案在父域的 DNS 決定，也就是父域要為子域放上 NS 記錄。NS 指向某些權威名稱伺服器（nameserver），例如：

dev.example.com 的 NS 可能是：

ns-123.awsdns-45.net
ns-456.awsdns-12.org
ns-789.awsdns-78.co.uk
ns-1011.awsdns-90.com

只要父域的 NS 正確，後續查詢就會把責任交給被指派的那組權威伺服器。

「權限授權」常被誤解成 IAM

很多團隊以為「授權」就是給另一個帳號能不能在 Route 53 改設定。可是 Route 53 的委派流程在 DNS 層面並不依賴 IAM。要讓另一個帳號自己管理子域，你要做兩件事：

1）在父域設定 NS，告訴世界「dev.example.com 交給那邊管」。
2）在那個「那邊」的 AWS 帳號中，確保它真的能新增/修改 dev.example.com 的 Route 53 資源（IAM、信任關係、或資源共享）。

換句話說：DNS 委派解決「解析去哪裡」，IAM 解決「能不能改內容」。兩者缺一不可，但時間線可以分開。

你需要準備的資訊清單

AWS企業帳號購買 開始前先把資訊準備好，避免在設定中途卡住。

• 父網域的 Route 53 托管型態：你的 example.com 是否在 Route 53？如果是，你就能直接改 NS。
• 子網域的規劃：例如要委派 dev.example.com、staging.example.com 或 api.partner.example.com。
• 被委派方提供的權威名稱伺服器：通常以一組 NS（或 AWS Hosted Zone 的 NS）提供。
• 委派方是否啟用 DNSSEC：若父域與子域都要做 DNSSEC，需要 DS 記錄。
• TTL 策略：NS 與 DS 記錄通常可以使用預設 TTL，但你要知道變更後會有緩存延遲。
• 跨帳號權限需求（可選）：若你希望另一個 AWS 帳號在 Route 53 建置子域記錄，你要準備 IAM/角色/資源共享的方式。

場景一：你委派子域給其他管理者（最常見）

步驟 1：在「被委派方」建立子域的 Hosted Zone

假設你要把 dev.example.com 交給另一個 AWS 帳號或另一套 DNS 管理系統。被委派方需要為 dev.example.com 建立自己的 DNS 權威（在 AWS 就是建立 Hosted Zone）。建立後，你會拿到一組 NS。

在 AWS Route 53 中，你可以在 Hosted Zone 的詳細資訊看到 NS。通常會有四個。你把它們完整抄下來，勿漏。

步驟 2：在父域 example.com 建立子域的 NS 記錄

回到父域（example.com）的 Route 53 控制台：

• 進入 Hosted Zone：example.com
• 新增記錄（Create record）
• 類型（Record type）選擇：NS
• 名稱（Name）填：dev.example.com
• 把被委派方提供的 4 個 NS 值全部填入
• 儲存

重點是：你只要把 NS 配對對，子域的內容就會由對方的權威 DNS 決定。父域不必再替 dev.example.com 建 A/AAAA/CNAME 等細節記錄，除非你要做覆蓋（不建議在委派後混用）。

步驟 3：等待 DNS 傳播與驗證

NS 變更後，快取可能讓你看到短暫不一致。你可以用以下方法驗證：

• 查詢 NS：看 dev.example.com 的 NS 是否指向對方提供的伺服器
• 查詢子域的目標記錄：例如 A 查 app.dev.example.com
• 用不同解析器測試（例如本機與外網）

如果你長期看到解析仍在你預期之外，第一個要檢查的是父域 NS 是否正確、拼字是否一致、以及 Hosted Zone 是否真的存在。

場景二：你自己在 Route 53 管理子域，但要「授權另一個團隊」

這個場景的委派仍然存在，但你可能不需要把解析委派出去。你只是希望不同團隊能在同一個 Route 53 環境下修改各自的內容。此時問題多半落在「跨帳號或跨角色權限」以及「資源級控制」。

方式 A：同帳號分權（推薦起步）

如果你有同一個 AWS 帳號，最清楚的做法是用 IAM 群組/角色把 Route 53 的操作限制在特定 Hosted Zone。

原則是：

• 只允許必要的 Route 53 動作（例如 List/Get/ChangeResourceRecordSets）
• 用 Hosted Zone ARN 做資源限制
• 必要時限制「只能變更某個 zone」，不能對所有 zone 操作

這能避免「誤刪 NS 委派」這類災難性錯誤。很多事故不是因為不會操作，而是因為權限過大。

方式 B：跨帳號管理（你要先談好邊界）

如果子域的 Hosted Zone 在另一個 AWS 帳號裡，你又希望本帳號的團隊能改它的記錄，那就要安排跨帳號信任與資源存取。常見作法包括建立可假設的 IAM 角色（跨帳號 AssumeRole）或使用 AWS Resource Access Manager（視情境）。

不論你採哪種方式，建議你先定義：

• 誰能修改 NS/DS（通常只交給 DNS 管理者）
• 誰能修改 A/AAAA/CNAME（可交給應用團隊）
• 是否允許刪除記錄（盡量不要給過高權限）

AWS企業帳號購買 然後才來寫政策與信任關係。這樣做的好處是：你不會在做委派時順手把權威鍊破壞。

AWS企業帳號購買 場景三：委派同時要考慮 DNSSEC（進階但常被忽略）

當你啟用 DNSSEC 時，父域需要對子域做額外的信任落地：在父域加入 DS 記錄，用來指向子域公開的金鑰（key signing）資訊。

什麼時候你需要 DS

如果子域 Hosted Zone 啟用了 DNSSEC，且你希望整個鏈路驗證成立，那父域就必須有 DS。反過來，如果你父域沒配 DS，驗證鏈可能在一些解析環境中失敗，造成「看起來像 DNS 壞掉」但其實是驗證不通過。

請注意：DNSSEC 的部署會牽涉金鑰輪替與狀態管理，建議先在測試域驗證流程，再上生產。

在父域加入 DS 的流程

在 Route 53 中：

• 先確認子域 Hosted Zone 的 DNSSEC 狀態
• 在子域的 Hosted Zone 準備好 DS 資訊（AWS 通常可直接提供）
• 回到父域 example.com，新增 Record type 選擇：DS
• Name 填：dev.example.com（或你委派的子域名稱）
• 輸入 DS 的參數（Key tag、Algorithm、Digest type、Digest）
• 儲存並等待傳播

如果你正在做 DNSSEC，但來源資訊不完整或貼錯，常見結果是驗證失敗。這時候與其反覆猜，不如先回到子域確認 DS 內容是否正確。

設定細節：TTL、記錄重複與常見踩雷點

NS 記錄一旦改錯，影響範圍往往非常大

NS 是信任鍊的樞紐。你在父域把 dev.example.com 的 NS 指向錯誤的權威伺服器，那整個子域後續 A/AAAA/CNAME 解析都會跟著跑掉。建議做任何 NS 變更時：

• 先在測試子域（例如 dev2.example.com）驗證流程
• 確認拼字完全一致（多一個字母或漏掉底線都可能失敗）
• 在變更前截圖或記錄原始 NS，方便快速回滾

避免在委派後同時管理子域細節（除非你知道你在做什麼）

AWS企業帳號購買 委派後，父域應該只負責 NS（以及必要的 DS）。如果你在父域又為 dev.example.com 建了 A 記錄，那會造成兩套答案來源混雜。一般情況下，遞迴解析器會走向權威來源，但不同解析行為在邊界情境可能讓你看到不一致，增加除錯成本。

AWS企業帳號購買 TTL 設太低只會讓你更難排查

有些人覺得 TTL 越低越快生效，結果就是變更頻率上升、快取切換更頻繁。對 NS 和 DS 這類影響範圍大的記錄，保持合理 TTL（例如預設）更好。你要的是穩定，而不是每次測試都讓整個解析系統一直重算。

權限授權與委派的時間順序：如何避免「半吊子」狀態

實務上常見的錯誤是：先在父域把 NS 改掉，但被委派方的 Hosted Zone 還沒建立或內容不完整。此時，世界上已經開始問新的權威，但新的權威還答不出你需要的記錄，造成解析失敗。

更穩健的順序通常是：

1. 被委派方先建立子域 Hosted Zone（並完成必要記錄，如 A/AAAA/CNAME）
2. 確認被委派方的權威查詢正常（先用外部工具或在內網測）
3. 在父域新增或更新 NS（並加入 DS 若使用 DNSSEC）
4. 觀察一段時間確認沒有解析回饋

若你只能在短時間內同步完成，至少要確保被委派方的 DNS 在你切 NS 前已可用。

驗證：你不該只相信控制台的顯示

三個你應該檢查的層次

• 層次一：父域 NS 是否正確
  確認 dev.example.com 的 NS 是否指向預期的名稱伺服器。
• AWS企業帳號購買 層次二：子域權威是否回應
  確認對方權威伺服器能回應你需要的記錄（A/AAAA/CNAME）。
• 層次三：從外部角度是否能解析
  用不同網路與解析器檢查。內網 DNS 可能快取，讓你誤以為變更成功。

排錯思路：先看「在哪一段斷掉」

如果解析失敗，先不要急著改一堆地方。你可以按順序縮小範圍：

• 若 NS 指向錯誤或不存在：回到父域修 NS。
• 若 NS 正確但子域記錄不存在：回到被委派方補齊記錄。
• 若 NS 與記錄都正確但仍失敗：檢查 DNSSEC（是否少 DS、DS 是否正確、key tag/algorithm 是否匹配）。
• 若只有部分地區/部分解析器失敗：大概率是快取或 DNSSEC 驗證差異。

這樣的順序能讓你把不確定性降到最低。

最佳實務：把「委派」做成可重複的流程

當你開始規模化（例如每個環境 dev/staging/prod 都要委派給不同團隊或不同帳號），單次操作的手動流程會變得脆弱。建議你把流程整理成清單或表格，包含：

• 要委派的子域名稱與對應的 Hosted Zone
• 被委派方的 NS（固定保存來源與時間）
• 是否使用 DNSSEC、DS 的版本與檢查點
• 切 NS 的時間與回滾方案
• 驗證指標（例如 app 子域解析結果、健康檢查域名）

此外，若團隊經常變更，責任邊界也要寫清楚：誰能改父域 NS、誰能改子域記錄。權限一旦超出，事故就會更快發生。

結語：把委派當作「信任鍊轉移」來看待

Route 53 子域名權限授權，真正的核心在於「委派」。你不是在給對方一張可操作的通行證，而是在 DNS 信任鍊上把責任移交到另一套權威。當 NS（必要時含 DS）設對了，解析就會自然落在正確的地方；當 IAM 或跨帳號權限設定得當，對方也才有能力維護自己的 DNS 內容。

AWS企業帳號購買 只要你遵守穩健的順序：先讓子域權威準備好，再切 NS（與 DS），最後用外部視角驗證，就能把「看起來像玄學」的 DNS 問題變成可控的工程流程。