Route 53 DNS — 公開、私有與混合架構

ANS-C01 考試中的 DNS 是任何全球架構的承重支柱，而 Route 53 遠不止是一個名稱到 IP 的查詢服務 — 它是一個可編寫程式的流量控制平台，Specialty 考試期望你能像操縱樂器一樣熟練地使用它。一典型題目描述：一個在全球五個區域部署了區域 ALB 的應用程式，預設需使用延遲路由，並在最低延遲區域不健康時容錯移轉到較近的區域，同時為監管排除區設定基於地理位置的覆蓋，並在每個區域內進行加權藍綠部署 — 詢問如何在 60 秒內表達這種組合。這是一個設計問題，涉及公有託管區域、所有七種路由策略、別名 (Alias) 記錄、健康檢查 (端點、計算、CloudWatch 警示)、作為組合器的流量策略、用於完整性的 DNSSEC 以及用於可觀測性的查詢記錄 — ANS-C01 通常會在單個五行字的情境中測試上述所有組件。

本主題完全涵蓋網域 1 (網路設計，佔考試 30%) 的任務陳述 1.2。官方 ANS-C01 考試指南逐字列出了相關知識點：「DNS 協定」、「DNS 記錄與監控」、「Amazon Route 53 功能 (別名記錄、流量策略、解析器、健康檢查)」、「Route 53 與其他 AWS 網路服務的整合」、「Route 53 與混合、多帳戶及多區域選項的整合」以及「網域註冊」。65 題考試中約有 6 到 9 題涉及此範疇。

為什麼 Route 53 是 ANS-C01 網域 1 的基石

DNS 是全球架構與使用者交匯的地方。網域 1 中的所有其他主題 — 負載平衡器、邊緣服務、混合連線 — 都依賴於 DNS 來進行客戶端解析。如果 DNS 將使用者路由到了錯誤的區域，那麼精心設計的 ALB 與極速的 CloudFront 快取都將付諸流水。Specialty 考試之所以測試 Route 53，是因為現實中的網路工程師將 DNS 視為一等公民系統，而 Specialty 認證正是將網路工程師與通才解決方案架構師區分開來的標準。

考試獎勵的心理模型是 Route 53 作為可編寫程式的全球流量管理平面，而不僅僅是一個扁平的名稱到 IP 的資料庫。路由策略與健康檢查組合；健康檢查與流量策略組合；流量策略再與 DNSSEC 和查詢記錄結合。ANS-C01 會為這種分層思考提供滿分；若候選人將 Route 53 僅視為「一般的 DNS」，則會在路由策略干擾項中失分。

白話文解釋 Route 53 DNS 設計

Route 53 結合了 DNS 協定機制、AWS 專有功能 (別名、流量策略、健康檢查)、七種路由策略、混合解析器端點以及 DNSSEC。以下三個類比錨定了這些活動組件。

類比一：具備智能分揀辦公室的郵政系統

將 Route 53 想像成一個國家郵政系統。託管區域 (Hosted zone) 是城市的通訊錄目錄 — 每一位收件人 (網域) 都註冊了其交付地址 (IP)。公有託管區域是任何人都可以查閱的公開電話簿；私有託管區域是只有辦公室內員工 (VPC 內部) 才能讀取的公司內部目錄。A 記錄是直接地址 (「主街 123 號」)；CNAME 記錄是轉寄地址 (「所有寄給 John 的信請轉寄到其在橡樹街 456 號的新地址」)；別名 (Alias) 記錄是 AWS 管理的智能轉寄 (郵局知道你的轉寄鏈並會自動更新，且沒有 TTL 偏差)。TTL 是地址卡上的有效期限 — 收件人在再次詢問前會將地址快取這麼久。路由策略是智能分揀辦公室的規則：簡單路由是「按卡片上的地址投遞」，加權路由是「65% 投遞到地址 A，35% 投遞到地址 B 以進行藍綠測試」，延遲路由是「投遞到最近的分揀中心」，容錯移轉路由是「如果中心 A 關閉，則重新導向至中心 B」，地理位置路由是「歐洲客戶去歐洲中心」，地理接近路由是「歐洲中心，但對亞洲中心有 30% 的權重偏移」，多值回答路由是「給客戶 8 個不同的有效地址讓其輪詢」，基於 IP 路由是「VIP 客戶去快速中心」。健康檢查是每 30 秒自動撥打一次確認電話，以確認分揀中心仍在運作；如果電話不通，分揀中心會將該地址從備選名單中移除。流量策略是編排嵌套規則的視覺化流程圖編輯器。DNSSEC 是目錄條目上的防篡改蠟封 — 收件人可以驗證郵局已簽署該地址。

類比二：餐廳預約系統

一個網域就像一個連鎖餐廳品牌 (例如「BurgerCorp」)。託管區域是中央預約資料庫。NS 記錄是品牌的餐廳電話清單 — 當客戶撥打 104 查詢 BurgerCorp 電話時，電信業者會返回這些號碼。A 記錄是特定的餐廳地址 (「我們市中心分店在松樹街 100 號」)。別名記錄則具備 AWS 感知能力 — 它們指向 AWS 資源 (ALB, CloudFront, S3 網站)，AWS 會自動解析底層 IP，即便 IP 變更也無妨 — 就像說「將客戶送到排隊最短的分店」。CNAME 是轉接號碼 — 「市中心 BurgerCorp 今天轉接到上城區 BurgerCorp」。延遲路由是根據郵遞區號將客戶連接到最近分店的通話路由。地理位置路由是文化在地化規則，不論距離遠近，德國客戶總是去提供德語菜單的餐廳。容錯移轉是主店關閉時路由到另一家店的自動備選方案。加權路由是 A/B 菜單測試，將 90% 的客戶導向標準菜單，10% 導向新菜單。多值回答是同時給客戶 4 個不同的餐廳電話，讓其手機隨機撥打一個 (基礎的輪詢 DNS)。健康檢查是秘密客，確認每家分店都在營業並正常服務。

類比三：空中交通管制 (ATC) 塔台

DNS 就像空中交通管制。託管區域是每架飛機 (客戶端) 都會諮詢的飛行計畫資料庫。A 記錄是直接目的地 (「LAX 到 JFK 航班 8 號航廈 23 號登機門」)。別名記錄是機場管理的動態登機門分配。CNAME 是「原本的登機門滿了，請滑行到備用登機門」。延遲路由是分配飛行時間最短的機場。地理位置路由是監管轄區規則 (歐盟航班必須降落在歐盟海關機場)。容錯移轉是主機場起霧時的備降機場。健康檢查是持續的 ATC ping 訊號，確認每個塔台都有回應。DNSSEC 是 ATC 握手上的加密身份驗證 — 飛行員可以驗證塔台真實存在而非冒充。流量策略是將所有這些規則組合成單一決策樹的飛行計畫合成器。

DNS 協定精要 — 記錄、TTL 與負面快取

DNS 是一個層級式、分散式且具備快取機制的協定。Route 53 在規模化層面實作了它，但協定基礎 (記錄類型、TTL 語意、負面快取、區域委派) 本身也是考試重點。

你必須知道的記錄類型

• A — IPv4 位址 (4 位元組，「1.2.3.4」)。
• AAAA — IPv6 位址 (16 位元組)。
• CNAME — 規範名稱 (指向另一個 DNS 名稱)；不能存在於區域頂點 (Zone apex)。
• MX — 郵件交換器 (具備優先級)；用於 SMTP 路由。
• TXT — 文字記錄 (用於 SPF, DKIM, 網域驗證)。
• NS — 名稱伺服器 (列出區域的權威 DNS 伺服器)。
• SOA — 權威記錄起始 (區域元數據、序號、重新整理/重試/到期/最小 TTL)。
• PTR — 反向 DNS (IP 到名稱)；在 Route 53 公有區域中較少管理。
• CAA — 憑證授權單位授權 (哪些 CA 可以為該網域簽發憑證)。
• ALIAS (Route 53 專有) — AWS 資源的別名；行為類似 A/AAAA，但會自動追蹤資源的 IP。

TTL 與傳播

TTL (存活時間) 是解析器在重新詢問前快取該記錄的秒數。較低的 TTL 意味著傳播更快，但 Route 53 的查詢負擔更高；較高的 TTL 降低了成本，但會減慢容錯移轉。常見預設值：穩定狀態下為 300 秒 (5 分鐘)；需要主動容錯移轉時為 60 秒。

負面快取 (Negative caching) 是解析器對「此記錄不存在」(NXDOMAIN 回應) 的快取。受 SOA 記錄的最小 TTL 欄位控制，負面快取意味著即使你建立記錄後，拼錯的 DNS 名稱在負面快取期間仍會持續失敗。

區域委派與 NS 記錄

父區域 (例如 .com) 透過在父區域中放置子區域的 NS 記錄 來委派給子區域 (例如 example.com)。NS 記錄列出了子區域的權威名稱伺服器。解析器遍歷鏈條 — 根區域 → TLD 區域 → 二級區域 — 最終獲得權威答案。

建立 Route 53 公有託管區域時，AWS 會分配四個 NS 記錄 (分別來自全球四個不同的 AWS DNS 解析器)。你必須在網域註冊商處更新 NS 記錄指向這四個值 — 這是「委派」步驟。

公有託管區域 — 網域註冊與委派

Route 53 中的公有託管區域是 DNS 記錄的容器，可從公有網際網路解析。它是你為公有網域執行 BIND, NSD 或 PowerDNS 的 AWS 受管替代方案。

網域註冊

Route 53 同時也作為註冊商營運 — 你可以直接購買網域。註冊商支付註冊費用 (例如 .com 給 Verisign)，處理 WHOIS，並建立具備預設 NS 記錄的託管區域。你也可以使用第三方註冊商 (GoDaddy, Namecheap) 並將其 NS 記錄指向 Route 53 — 結果是完全一樣的，只是分散在兩個供應商。

黏附 (Glue) 記錄與區域外 NS

Route 53 的 NS 記錄使用 AWS 擁有的名稱，如 ns-1234.awsdns-12.org。TLD 區域提供 Glue 記錄 (針對 AWS NS 主機名稱的 A 記錄)，以便解析器不會陷入循環。這對大多數營運人員是不可見的，但網路工程師應理解其機制。

區域頂點 (Apex zone) 約束

區域頂點 (例如 example.com 本身，而非 www.example.com) 不能擁有 CNAME。RFC 1034 禁止這樣做，因為頂點處的 CNAME 會與隱含的 NS 和 SOA 記錄衝突。Route 53 透過別名 (Alias) 記錄解決了這個問題 — 在頂點處使用指向 ALB, CloudFront, S3 網站或其他 AWS 資源的別名是標準模式。標準 CNAME 僅在子網域中有效。

私有託管區域 — 水平分割與 VPC 關聯

私有託管區域 (PHZ) 是 DNS 記錄的容器，僅能從關聯的 VPC 內部解析 — 對公有網際網路不可見。PHZ 是在 AWS 上執行在地內部 DNS 的受管替代方案，也是 SCS-C02 / ANS-C01 認可的 VPC 內部命名模式。

VPC 關聯

PHZ 與任何 AWS 帳戶中的一個或多個 VPC 相關聯。關聯 VPC 內部的資源查詢 AmazonProvidedDNS 解析器 (每個子網路中的 .2 位址)；解析器優先諮詢 PHZ，對非 PHZ 名稱則回退到公有 DNS。

跨帳戶 PHZ 關聯

透過在帳戶 A 中建立授權 (Authorization) 並在帳戶 B 中建立關聯 (Association) (兩步式 API)，可以將帳戶 A 中的 PHZ 與帳戶 B 中的 VPC 相關聯。這是多帳戶 DNS 模式。

水平分割 (Split-horizon) DNS

同一個網域名稱 (例如 api.example.com) 根據解析器的不同可以解析為不同的 IP。公有託管區域為網際網路客戶端返回公有 IP；私有託管區域為 VPC 客戶端返回私有 RFC 1918 IP。由於解析器的查詢順序，PHZ 對於 VPC 解析器查詢具有優先權。這是規範化的「內部 API 端點」模式。

來自在地環境的條件轉發

混合 DNS (在 Route 53 Resolver — 混合 DNS 主題中詳述) 透過 Resolver 傳入 (Inbound) 端點將 PHZ 解析擴展到在地客戶端。在地 DNS 伺服器設有條件轉發規則：「對於 internal.aws.example.com，轉發至 AWS Resolver 傳入端點 IP」。傳入端點接收到在地查詢，將其交給 VPC 解析器，後者諮詢 PHZ 並返回私有 IP。

別名記錄 vs CNAME — 測試頻率最高的一對

別名 (Alias) 與 CNAME 的區別是 ANS-C01 測試最頻繁的一對。兩者都將流量轉發到另一個 DNS 名稱，但它們在約束、成本與使用案例上有所不同。

標準 CNAME

CNAME 將一個 DNS 名稱指向另一個。解析器跟隨鏈條直到最後的 A/AAAA 記錄。約束：不能存在於區域頂點，不能與同名的其他記錄共存 (例如不能同時擁有同名的 CNAME 和 TXT)。按查詢次數收費 (Route 53 定價)。

別名 (Alias) 記錄 (僅限 Route 53)

別名記錄是指向 AWS 資源的 AWS 專有擴展。約束：目標必須是 AWS 資源 (ALB, NLB, CloudFront 分發, S3 網站, API Gateway, Elastic Beanstalk 環境, VPC 介面端點, Global Accelerator 或同區域內的另一個 Route 53 記錄)。優點：不收取別名查詢費用 (由 Route 53 吸收)，可以存在於區域頂點，並與健康檢查整合以進行容錯移轉路由。

健康檢查整合

別名記錄可以具備「評估目標健康狀況 (Evaluate Target Health)」旗標 — 如果啟用，Route 53 在回答查詢時會考慮目標的健康狀況 (例如 ALB 的執行個體健康狀況)。標準 CNAME 無法做到這一點 — 對 CNAME 的健康檢查需要顯式的健康檢查資源。

路由策略 — 所有七種類型

Route 53 支援七種截然不同的路由策略。每種都針對特定的流量管理需求，ANS-C01 期望你能在 30 秒內將場景映射到正確的策略。

簡單路由 (Simple routing)

單一記錄，單一答案 (如果記錄包含多個值，則在解析器層級為多值，但 Route 53 會返回所有值)。最簡單的預設策略。記錄本身沒有健康檢查整合 (僅能透過別名記錄的 Evaluate Target Health)。用於靜態的單目標 DNS。

加權路由 (Weighted routing)

同名多條記錄，每條配備一個權重 (0–255)。Route 53 按權重比例返回記錄。用於 A/B 測試、藍綠部署以及逐漸遷移流量。權重 0 不發送流量至該記錄 (用於優雅停機)。

延遲路由 (Latency-based routing)

多條記錄，每條標記一個區域。Route 53 返回與解析器延遲最低的區域對應的記錄。延遲數據由 AWS 在各區域與解析器 IP 之間持續測量。

容錯移轉路由 (Failover routing)

兩條記錄 — 主要 (Primary) 與次要 (Secondary)。在主要記錄上設定健康檢查；若健康，則返回主要記錄；若不健康，則返回次要記錄。主從式容錯移轉模式。結合健康檢查評估可實現完全的可靠性。

地理位置路由 (Geolocation routing)

多條記錄，每條標記洲、國家或美國州。Route 53 返回與解析器位置匹配的記錄。預設記錄 (無位置過濾器) 捕捉所有未明確匹配的查詢。用於監管合規 (歐盟使用者 → 歐盟伺服器) 與內容在地化。

地理接近路由 (Geoproximity routing，僅限流量控制)

類似地理位置路由但具備偏差 (Bias) — 你可以按百分比將流量移向或移離某個區域。僅在流量策略 (Traffic Policy) 中可用 (不作為獨立記錄)。用於災害場景或容量重平衡期間的精細流量塑形。

多值回答路由 (Multi-value answer routing)

多條記錄 (最多 8 條)，每條可選配健康檢查。Route 53 返回所有健康的記錄 (最多 8 條)，由解析器隨機選擇一個。類似於具備健康檢查過濾功能的輪詢 (Round-robin) DNS。用於無需負載平衡器的韌性設計。

基於 IP 路由 (IP-based routing)

多條記錄，每條標記一個或多個 CIDR 區塊。Route 53 返回與解析器 IP 匹配的記錄。用於明確的按 ISP 或按客戶路由。較新的功能，雖然較少測試但仍在範疇內。

健康檢查 — 端點、計算與 CloudWatch 警示

Route 53 健康檢查是路由策略背後的誠信層。分為三種類型。

端點健康檢查 (Endpoint health checks)

定期 (每 10 或 30 秒) 向目標端點發送 HTTP, HTTPS, TCP 或帶有 SNI 的 HTTPS 請求。根據回應代碼或 TCP 連線成功與否判定通過/失敗。失敗閾值 (例如連續 3 次失敗) 決定健康狀態。

端點檢查來自全球 15 個以上的 AWS 健康檢查位置。每個位置獨立評估；整體健康狀況預設為「如果 18% 或以上的位置失敗，則判定為失敗」。可透過 Service Quotas 調整。

計算健康檢查 (Calculated health checks)

使用 AND/OR 邏輯組合最多 256 個子健康檢查。如果 N 個子檢查中有 N 個通過，則判定為通過。用於「若 ALB 健康且 RDS 健康且 DNS 解析器健康，則此區域健康」。

CloudWatch 警示健康檢查

健康檢查狀態鏡像 CloudWatch 警示。當警示為 OK 時通過；當警示處於 ALARM 時失敗。用於「若我們的 SLO 錯誤率低於 1%，則此區域健康」 — 基於應用層指標而非網路可達性。

別名記錄中的健康檢查評估

別名記錄可以使用 Evaluate Target Health 旗標來考慮目標的內在健康狀況 (例如 ALB 的執行個體計數、執行個體健康狀況)。這是免費的 (無需單獨的健康檢查資源)，但僅適用於 AWS 資源目標。

DNSSEC — DNS 的加密身分驗證

DNSSEC (DNS 安全擴充功能) 對 DNS 回應進行加密簽名，允許解析器偵測篡改。Route 53 支援使用 AWS KMS 非對稱金鑰 為公有託管區域進行 DNSSEC 簽名。

DNSSEC 的運作方式

託管區域擁有者生成一個作為 KMS 非對稱金鑰儲存的金鑰簽名金鑰 (KSK)。KSK 簽署區域簽名金鑰 (ZSK)，ZSK 則簽署區域內的所有記錄。KSK 的公有部分作為 DS (委派簽署者) 記錄 發佈在父區域中，作為信任錨。

解析器沿著 DNS 鏈條驗證每個簽名；如果任何檢查失敗，回應將被丟棄。這防止了快取汙染 (Cache poisoning)、路徑上篡改以及基於 BGP 劫持的 DNS 冒充。

在 Route 53 上啟用 DNSSEC

透過主控台或 API 在公有託管區域上啟用。Route 53 生成 KSK (採用 ECC_NIST_P256 演算法的 KMS 非對稱金鑰)，自動簽署記錄，並暴露 DS 記錄供上傳至註冊商。一旦註冊商發佈了 DS 記錄，信任鏈就錨定完成了。

金鑰輪換

KSK 輪換要求在註冊商處更新 DS 記錄 — 這是一項非零風險的操作。AWS 建議每 1-2 年輪換一次，並提供了文件化的滾動輪換程序。ZSK 的輪換則是自動且頻繁的 (不需要變更 DS 記錄)。

流量策略 — 複雜路由的視覺化編輯器

流量策略 (Traffic policies) 是 Route 53 用於編排多步驟路由決策的視覺化流程圖編輯器。策略是規則 (地理位置、延遲、加權、多值、容錯移轉、地理接近) 的有向圖，為每次查詢生成最終答案。

為什麼需要流量策略

若不使用流量策略，表達「以延遲路由作為預設，搭配區域容錯移轉，且在每個區域內進行 10% 藍綠部署」需要極易出錯的手動嵌套記錄集。流量策略將此表達為一個單一的視覺化圖形：頂層延遲分割 → 區域容錯移轉 → 區域內加權。

版本控制與策略記錄

每個策略都有帶版本的快照。你建立一個策略記錄，將策略版本與 DNS 名稱綁定。更新策略會建立新版本；復原則是簡單地將策略指向先前的版本。這比手動編輯記錄集在營運上更安全。

使用流量策略進行 A/B 測試

常見模式：透過加權策略進行 1% 的藍綠測試，並在數小時內逐步升級至 10%、50%、100%。流量策略持有權重；更新策略中的權重即可更新流量分佈，而無需觸及底層記錄。

查詢記錄 — DNS 可見性

查詢記錄 (Query logging) 擷取由 Route 53 託管區域處理的每筆 DNS 查詢，並寫入 CloudWatch Logs。對於安全性分析 (偵測透過 DNS 的資料外洩)、除錯 (哪些用戶端在查詢哪些記錄) 以及合規性非常有用。

啟用方式

在公有託管區域透過主控台或 API 配置。Route 53 將日誌發送至指定的 CloudWatch 日誌群組。每筆日誌記錄包含：查詢名稱、查詢類型、回應代碼、處理查詢的邊緣位置、解析器 IP 以及協定 (UDP 或 TCP)。

成本與保留

日誌功能本身免費；CloudWatch Logs 的擷取與儲存則需付費。對於高流量區域，擷取成本會迅速累積 — 建議透過訂閱篩選器將日誌分區至 S3，並使用 Athena 進行高成本效益的查詢。

查詢記錄不擷取的內容

私有託管區域的查詢是透過 Resolver 查詢記錄 (解析器上的一個獨立功能，而非託管區域上的) 擷取的。公有託管區域查詢日誌僅擷取來自公有解析器的查詢 — 來自 VPC 內部對公有記錄的查詢同樣由 Resolver 查詢記錄擷取。

常見陷阱總結 — ANS-C01 中的 Route 53

陷阱 1：區域頂點處使用 CNAME

錯。頂點處禁止 CNAME；請使用別名 (Alias)。

陷阱 2：別名記錄適用於非 AWS 目標

錯。別名僅指向 AWS 資源或同區域內的另一個記錄。

陷阱 3：地理位置比對使用者端 IP 所在地

部分錯誤。地理位置比對的是解析器 IP 的所在地，而非最終使用者的。EDNS Client Subnet (ECS) 雖然擴展了可視性，但並非所有解析器都會發送它。公共 DNS 解析器 (如 Google 8.8.8.8) 通常會發送 ECS，但若缺失，Route 53 使用的是解析器的地理位置。

陷阱 4：容錯移轉健康檢查必須在主要記錄上

主要記錄需要健康檢查 (或別名記錄的 Evaluate Target Health 旗標)。次要記錄嚴格來說不一定需要，但為了連鎖容錯移轉應配置一個。

陷阱 5：多值回答等同於負載平衡

錯。多值回答返回最多 8 個健康的記錄；由用戶端選擇一個。它是帶有健康過濾的輪詢 DNS，而非負載平衡 — 並沒有智能的流量分配。

陷阱 6：流量策略取代了託管區域

錯。流量策略在託管區域內部建立策略記錄。兩者共存。

陷阱 7：DNSSEC 無需註冊商處的 DS 記錄即可工作

錯。缺少 DS 記錄會導致信任鏈斷裂，解析器會將該區域視為未簽署。

陷阱 8：Route 53 健康檢查來自單一位置

錯。它們來自全球 15 個以上的 AWS 健康檢查區域，由多數票決決定整體健康狀態。

陷阱 9：TTL 為 0 會停用快取

部分正確。TTL 為 0 告訴解析器不要快取，但大多數公有解析器無論如何都會強制執行 30-60 秒的最小 TTL。即便設定 TTL 為 0，仍應考慮到一定的快取。

陷阱 10：私有託管區域會自動在在地環境解析

錯。PHZ 僅能從關聯的 VPC 解析。在地解析需要 Route 53 Resolver 傳入端點 (在「解析器混合 DNS」主題中涵蓋)。

陷阱 11：地理接近路由是記錄級別的路由策略

錯。地理接近路由僅在流量策略內部可用，不作為記錄上的獨立策略。

陷阱 12：延遲路由考慮了應用程式延遲

錯。Route 53 測量的是從解析器 IP 到 AWS 區域的網路延遲。應用程式層級的延遲 (慢速資料庫、慢速 Lambda) 對 Route 53 是不可見的。

FAQ — ANS-C01 中的 Route 53

Q1：我何時該在多區域容錯移轉中使用加權路由 vs 延遲路由？

延遲路由 將每位使用者引導至延遲最低的區域，優化使用者體驗。加權路由 按固定百分比向每個區域發送流量，不考慮延遲。對於多區域容錯移轉，延遲路由加上健康檢查評估是標準模式：使用者獲得最近的健康區域。加權路由則是藍綠部署 (90% 到舊版，10% 到新版) 或漸進式遷移的正確答案。Specialty 考試會同時用到這兩種模式；針對「使用者體驗」或「全球覆蓋」選延遲，針對「受控發佈」或「A/B 測試」選加權。

Q2：別名記錄中的健康檢查評估與獨立健康檢查有何不同？

別名記錄的 Evaluate Target Health 旗標利用了 AWS 對目標的內在健康感知 — 例如，ALB 的別名會檢查 ALB 是否有任何健康的註冊目標。獨立健康檢查 是一個單獨的 Route 53 資源，定期輪詢自訂端點 (HTTP, HTTPS, TCP)。別名評估是免費的、AWS 受管且即時的；獨立健康檢查則按檢查次數收費且需要顯式配置。對於 AWS 資源的別名記錄，應始終使用 Evaluate Target Health。對於非 AWS 目標 (在地 URL、第三方 SaaS)，獨立健康檢查是唯一選擇。

Q3：為什麼區域頂點需要別名記錄而非 CNAME？

DNS 標準 (RFC 1034) 禁止在頂點處使用 CNAME，因為頂點必須與該區域強制性的 NS 和 SOA 記錄共存，而 CNAME 是排他性的 — 具有 CNAME 的名稱不能有其他記錄類型。別名記錄透過在協定層級模擬 A 或 AAAA 記錄 (解析器看到的是帶有解析 IP 的 A 回應) 同時由 AWS 在內部追蹤目標，從而規避了這一點。因此別名在保留頂點 NS/SOA 的同時，提供了類 CNAME 的間接功能。若不使用別名，你必須在頂點 A 記錄中硬編碼目標 IP — 這很脆弱，因為 AWS 受管服務 (ALB, CloudFront) 的 IP 會變動。

Q4：Route 53 延遲路由是如何測量延遲的？

Route 53 維護一個從各個解析器 IP (取樣) 到每個 AWS 區域的持續更新的延遲資料庫。測量是透過 AWS 邊緣與公有 DNS 解析器樣本之間的內部探針進行的。資料是統計性的，而非每筆查詢即時測量的 — Route 53 返回的是從你的解析器網路鄰里實測延遲最低的區域。這意味著延遲路由反映的是來自你 ISP 解析器的平均網路延遲，而非你手機當下具體的 Wi-Fi 鏈路。ANS-C01 獎勵你能識別出這一點 — 延遲路由並非即時的 RTT 測量。

Q5：地理位置路由與地理接近路由有什麼區別？

地理位置 (Geolocation) 路由是離散且排他的比對 — 你為每條記錄標記洲、國家或美國州，Route 53 精確返回與解析器位置匹配的記錄。對於「無匹配」情況設有預設記錄。地理接近 (Geoproximity) 路由是連續且可加權比對 — Route 53 計算從解析器到 AWS 區域 (或指定地理座標) 的大圓距離，你可以套用偏差百分比來偏好或冷落特定區域。地理接近僅在流量策略中可用。地理位置用於法規路由 (歐盟使用者 → 歐盟伺服器，不被覆蓋)；地理接近用於災害期間的容量感知路由 (區域受損時將 30% 美東流量移向美西)。

Q6：如何設置跨兩個區域的主從式 (Active-Passive) 容錯移轉？

建立兩個同名的 A 記錄 (例如 api.example.com)，路由策略設為「容錯移轉」，一個為主，一個為從。為主要記錄的底層端點 (ALB, NLB 或自訂 URL) 附加健康檢查；健康檢查評估決定主要記錄是否健康。若主要健康，Route 53 返回主要記錄；若故障，返回次要記錄。針對 AWS 資源目標，使用帶有 Evaluate Target Health 的別名記錄，以避免為單獨的健康檢查付費。將 TTL 設低 (60 秒) 以確保快速的解析器端容錯移轉。總容錯移轉時間：健康檢查失敗閾值 × 間隔 + TTL ≈ 典型配置下 90-180 秒。ANS-C01 獎勵此模式作為規範化的「主從式多區域」答案。

Q7：我能否使用 Route 53 在在地環境解析內部的 AWS 資源？

可以，透過 Route 53 Resolver 傳入 (Inbound) 端點。VPC 中的 PHZ 包含內部記錄；傳入端點是該 VPC 中基於 ENI 的解析器。在地 DNS 伺服器配置條件轉發規則：「對於 internal.aws.example.com，將查詢轉發至 AWS Resolver 傳入端點 IP」。混合 DNS 解析流程為：在地 → Resolver 傳入端點 → VPC 解析器 → PHZ → 答案。相關內容在「解析器混合 DNS」主題中有詳盡介紹。

Q8：生產系統實務上的 TTL 建議是多少？

對於需要具備主動容錯移轉能力的記錄 (指向 ALB 的別名記錄、主要容錯移轉記錄)，60 秒 是現代 AWS 推薦的 TTL。對於穩定的記錄 (CDN 別名、靜態站點)，300 秒 (5 分鐘) 即可。對於極其穩定的記錄 (一年沒換過 ALB 的區域頂點)，86400 秒 (1 天) 也行，但會讓基於 DNS 的遷移變得極慢。TTL 為 0 很少有用 — 大多數公有解析器無論如何都會強制執行 30-60 秒的最小值。ANS-C01 獎勵 60 秒作為「最小化容錯移轉時間」的答案；較長的 TTL 則適用於「最小化 DNS 查詢成本」的情境。

Q9：如何零停機將區域從第三方 DNS 遷移到 Route 53？

第一步：在 Route 53 建立公有託管區域並複製所有記錄 (使用 cli53 或 AWS CLI 批量導入)。第二步：使用 dig @ns-XXX.awsdns-XX.org example.com (直接查詢 Route 53) 驗證區域解析正確。第三步：在註冊商處，將 NS 記錄更新為四個 Route 53 NS 值。第四步：等待父區域 NS 委派的 TTL (通常 24 小時) 到期，以便解析器開始使用 Route 53。第五步：待 Route 53 獲得權威後，方可刪除第三方服務商的記錄。關鍵：在 NS 遷移完全傳播前，切勿刪除第三方記錄 — 過渡期間的 DNS 分裂是常見事故。ANS-C01 期望你能識別出此多步模式。

Q10：DNSSEC 對於合規性是強制性的嗎？它會影響效能嗎？

並非總是強制。某些監管體系 (美國聯邦政府、特定歐盟部門) 要求 .gov 或政府附屬網域使用 DNSSEC。對於大多數商業部署，DNSSEC 是建議做法但非強制。效能影響：DNSSEC 簽名發生在伺服器端 (由 Route 53 處理)；解析器端驗證在首次查詢時會增加 5-20ms，隨後會被快取。權衡點在於營運風險 — DNSSEC 配置錯誤 (簽名過期、DS 鏈斷裂、KSK 錯誤) 會導致全線斷網。應在非生產區域充分測試後再啟用；ANS-C01 獎勵「啟用了具備監控與驗證失敗警示的 DNSSEC」作為成熟的答案。

進階閱讀與相關營運模式

• Amazon Route 53 開發者指南
• 使用私有託管區域
• 選擇路由策略
• 配置 DNS 容錯移轉
• Amazon Route 53 如何為你的網域路由流量
• 為網域配置 DNSSEC
• 建立流量策略
• 記錄 DNS 查詢

建立 Route 53 公有/私有/混合 DNS 架構後，ANS-C01 下一個營運層級為：用於在地與 AWS 間雙向解析的 Route 53 Resolver — 混合 DNS 與條件轉發；位於使用者與 ALB 之間且依賴 DNS 進行客戶端解析的邊緣架構 — CloudFront 與 Global Accelerator；DNS 平面下方的 IP 平面 VPC 架構、CIDR 設計與子網路劃分；以及覆蓋整個堆疊的網路監控、疑難排解與成本優化。

• Route 53 Resolver — 混合 DNS 與條件轉發 — ANS-C01 學習筆記
• 邊緣架構 — CloudFront 與 Global Accelerator — ANS-C01 學習筆記
• VPC 架構、CIDR 設計與子網路劃分 — ANS-C01 學習筆記
• 網路監控、疑難排解與成本優化 — ANS-C01 學習筆記