examhub .cc 用最有效率的方法，考取最有價值的認證
Vol. I
本篇導覽 約 36 分鐘

Route 53 Resolver 與地端 DNS 整合

7,120 字 · 約 36 分鐘閱讀

什麼是 AWS Hybrid DNS Resolver？

Hybrid DNS resolver 是名稱解析層，負責讓 VPC 內部發出的 DNS 查詢能夠抵達地端私有區域，同時讓地端發出的 DNS 查詢能夠抵達 AWS 私有區域。在 AWS 上，hybrid DNS resolver 由 Amazon Route 53 Resolver 實作——這是一個受管的區域性 DNS 服務，預設存在於每一個 VPC 之中，並可透過 Resolver endpoints 和 Resolver Rules 延伸，在雲端與企業資料中心、遠端辦公室或透過 AWS Site-to-Site VPN、AWS Direct Connect 或 AWS Transit Gateway 連接的夥伴網路之間橋接 DNS 流量。

在 SAP-C02 考試中，hybrid DNS resolver 設計是 Domain 1（設計組織複雜性解決方案）和 Domain 2（設計新方案）的反覆出現主題。常見情境包括：「地端 Active Directory 使用者必須解析 AWS 私有 endpoints」、「共用服務 VPC 為數十個 spoke VPC 提供集中 DNS」、「多個 AWS 帳號需要相同的 conditional forwarding 規則但不重複設定」，以及「DNS 查詢必須記錄至 CloudWatch 以符合合規要求」。正確答案幾乎都結合了以下元素：以 Route 53 Resolver inbound endpoints、outbound endpoints、透過 AWS Resource Access Manager（RAM）共用的 Resolver Rules、跨 VPC 與帳號關聯的 Route 53 Private Hosted Zones（PHZ），有時再加上 DNSSEC signing 或 Resolver Query Logging 作為治理控制。

本主題比 CLF-C02 的 Route 53 概論深入得多。Hybrid DNS resolver 不只是「多幾個步驟的 Route 53」——它是一個架構控制平面，決定你的多帳號 landing zone 是否能可靠地解析名稱、遭入侵的 resolver 是否可被稽核，以及舊有 Active Directory 樹系能否與雲端原生服務探索共存。專業解決方案架構師必須清楚知道何時部署帶有 inbound endpoints 的 hybrid DNS resolver、何時需要 outbound endpoints、forwarding rules 的作用範圍為何，以及 Transit Gateway 如何改變 DNS 拓撲。本指南每一段落都針對 SAP-C02 情境題精準校準。

白話文解釋 Hybrid DNS Resolver

Hybrid DNS resolver 在白板上畫起來像一張蜘蛛網：雲端、地端、各帳號、各 VPC 都要能互相查名字。用三個類比，可以把 Route 53 Resolver 的 inbound、outbound endpoints 和 Resolver Rules 的角色拆開來看。

類比一：捷運路網的轉乘站（Inbound vs Outbound Endpoints）

把你的 VPC 想像成一座大型捷運站，站內每個月台都有自己的內部廣播系統（private IP）。Route 53 Resolver 是站內廣播中控室——它接聽每一則站內查詢（「payments.internal 在哪一個月台？」）並指引到正確出口。不過，這座捷運站也有兩條專屬對外聯絡道，連接外部路網。

Inbound endpoint 是從外部路網進入本站的聯絡道——專門給你的地端資料中心使用。地端 DNS 伺服器把 inbound endpoint 的 IP 當作普通 DNS 伺服器撥號查詢，Resolver 在站內接收並查找 Private Hosted Zone 內的 AWS 私有名稱，例如 *.awscloud.internal。Outbound endpoint 是從本站離開、駛向外部路網的聯絡道——當 VPC 內的 EC2 實例查詢 corp.example.com 時，Resolver 把查詢送出 outbound endpoint，前往地端 DNS 伺服器。方向永遠從 VPC 的角度定義：inbound = 流量進入 VPC resolver；outbound = 流量離開 VPC resolver。這個方向是 SAP-C02 hybrid DNS resolver 考題中最常測試的陷阱。

類比二：共享電子通訊錄（Resolver Rules 與 AWS RAM）

把每個 AWS 帳號想像成各自管理一本通訊錄的不同部門。Resolver Rules 是 Network 帳號維護的主通訊錄條目：「凡查詢 corp.example.com，請聯繫電話 10.1.2.3（地端 DNS 伺服器）。」問題在於，如果每個部門都各自購買一份主通訊錄副本，只要企業 DNS 伺服器搬家，就得更新 50 份副本。解決方案是：Network 帳號透過 AWS Resource Access Manager（RAM） 發布唯一一份主通訊錄，每個部門只需訂閱共享版本。主通訊錄一旦更新，50 個部門立即同步看到最新內容。這正是 hybrid DNS resolver 在 AWS Control Tower 與 Landing Zone 架構中擴展到多帳號的正確做法。

類比三：大樓氣送管道系統（Transit Gateway DNS）

老式百貨公司的出納員透過氣送管道在各樓層傳遞文件。AWS Transit Gateway 就是這套氣送管道系統，負責傳遞封包——包括 DNS 封包。當 spoke VPC 的 Resolver 查詢 legacy.corp.example.com 時，查詢從 spoke VPC 出發，穿過 outbound endpoint，進入 Transit Gateway，透過 Direct Connect 或 VPN 抵達地端，再攜帶答案原路返回。重點在於：Transit Gateway 不保管任何 DNS 狀態，它只搬運原始 UDP/TCP DNS 封包。DNS 必須在 Resolver 層端對端地設計妥當。管道只負責搬文件；它不閱讀文件內容。

理解了轉乘站、共享通訊錄和氣送管道這三個類比之後，本指南後續的每一個 hybrid DNS resolver 機制，都只是把相應的元件對應到正確的考試情境而已。

Route 53 Resolver — VPC 預設 Resolver

每個 AWS 區域的每一個 VPC 都內建 Route 53 Resolver，執行於保留 IP VPC_CIDR + 2（例如 10.0.0.0/16 的 VPC 對應 10.0.0.2），同時也可透過通用 IP 169.254.169.253 存取。這個 VPC 內建 Resolver 是任何 hybrid DNS resolver 設計的起點，負責回應三類查詢：

  1. 公開 DNS — amazon.com、google.com，以及任何公開網際網路上的名稱。Resolver 遞迴查詢 DNS root 與授權伺服器。
  2. AWS 私有 DNS — EC2 實例主機名稱（ip-10-0-1-23.ec2.internal）、VPC endpoint DNS 名稱、ALB/NLB DNS，以及 AWS 服務 endpoints。
  3. 客戶私有 DNS — 與 VPC 關聯的 Private Hosted Zones（PHZ），以及任何指向地端或第三方 resolver 的 Resolver Rules。

VPC 內建 Resolver 是隱性存在的：你無法關閉它、無法在主控台列出它，而且它的範圍限於單一區域。你只能在 EC2 實例上執行 dig 後，觀察查詢由 AmazonProvidedDNS 回應，才能感知它的存在。當預設 Resolver 不足以應付需求——例如地端伺服器需要存取 AWS 內部名稱，或 AWS 工作負載需要存取地端私有名稱——就需要加入 Resolver endpoints。

Route 53 Resolver — Route 53 Resolver 是遞迴 DNS 服務，在每個 VPC 的 VPC_CIDR + 2 與 169.254.169.253 執行。它負責解析公開 DNS、AWS 受管內部 DNS，以及與該 VPC 關聯的 Private Hosted Zones（PHZ）或 Resolver Rules。在 hybrid DNS resolver 情境中，Route 53 Resolver 可透過 inbound endpoints（地端 → AWS）和 outbound endpoints（AWS → 地端）延伸，這些 endpoints 以位於你子網路的 ENIs 為底層。 參考：https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html

Resolver Inbound Endpoints — 地端到 AWS

Resolver inbound endpoint 是一組放置在 VPC 子網路內的 Elastic Network Interfaces（ENIs），每個 ENI 從子網路的 CIDR 分配一個私有 IP。地端 DNS 伺服器被設定為將 AWS 私有名稱的查詢（例如 *.awscloud.internal 或 PHZ 網域名稱 internal.examhub.cc）轉送至 inbound endpoint 的 IP。從地端伺服器的角度來看，inbound endpoint 的 IP 就如同任何一台外部 DNS 伺服器；從 AWS 的角度來看，這些 ENIs 將查詢傳遞給 VPC 內建 Resolver，Resolver 再比對已關聯的 PHZ 進行查找。

為何需要 Inbound Endpoint？

  • 地端使用者需要解析 AWS 私有 endpoints，例如 vpce-123.execute-api.us-east-1.vpce.amazonaws.com — 這是 SAP-C02 最經典的 hybrid DNS resolver 情境。
  • 企業工作站需要存取 VPC 內 ALB 後方的內部服務，而不透過公開網際網路。
  • 資料中心的 CI/CD pipeline 需要透過 Direct Connect 解析 VPC 內的私有 RDS endpoints。

需求條件

  • 至少兩個 ENIs，分佈在兩個不同 AZ 以確保高可用性。AWS 建議每個 endpoint 至少兩個 IP 地址；主控台會強制要求此選項。
  • 一個允許地端 CIDR 範圍對 UDP/TCP port 53 進行 inbound 連線的 Security Group。
  • 從 VPC 回到地端的路由，透過 VPN、Direct Connect 或 Transit Gateway — DNS 是請求-回應協定，回傳流量必須能抵達地端 resolver。
  • 一個已關聯的 Private Hosted Zone（或預設的 ec2.internal 行為），用於你想公開的名稱。

費用模型

Resolver inbound endpoints 依每個 ENI 每小時計費，另加每次查詢費用。撰寫本文時，每個 ENI 約 $0.125/小時（$90/月），高可用性需要兩個 ENI，因此每個 inbound endpoint 預算約 $180/月。請乘以部署的區域數量。

Inbound Endpoint 方向：地端 → AWS — 「inbound」的方向是從 VPC 的角度定義：DNS 查詢從地端進入 VPC。想像一台地端 BIND 伺服器設定了 forwarder 規則 internal.examhub.cc → 10.0.1.10, 10.0.2.10——那兩個 IP 就是你的 inbound endpoint ENIs。方向判斷錯誤，整個 hybrid DNS resolver 拓撲就會設計反了。 參考：https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html

Resolver Outbound Endpoints — AWS 到地端

Resolver outbound endpoint 是鏡像的另一半。它同樣是一組位於 VPC 子網路的 ENIs，但這次這些 ENIs 是 DNS 查詢離開 VPC 前往地端 DNS 伺服器的出口。Outbound endpoints 搭配 Resolver Rules 使用，Rules 指定「對於這些網域名稱，將查詢轉送到這些目標 IP」。

為何需要 Outbound Endpoint？

  • VPC 工作負載需要解析地端私有名稱，例如 payroll.corp.example.com 或 ldap.ad.example.com。
  • **直接搬遷（lift-and-shift）**場景，EC2 實例仍使用舊有主機名稱指向地端資料庫。
  • 混合式 Active Directory，網域加入的 EC2 實例必須透過 SRV 記錄找到地端 AD 控制器。

查詢流程

  1. VPC 內的 EC2 實例查詢 ldap.ad.example.com。
  2. VPC_CIDR + 2 的 VPC 內建 Resolver 查對已關聯的 PHZ 和自動定義規則——無符合項目。
  3. Resolver 查對 Resolver Rules：一條 forwarding rule 寫著 ad.example.com → 10.1.1.53, 10.1.1.54 透過 outbound endpoint rslvr-out-abc。
  4. 查詢從 outbound endpoint ENI 送出，經過 VPC 路由表，進入 VGW/TGW，穿越 VPN 或 Direct Connect，抵達地端 DNS 伺服器 10.1.1.53。
  5. 答案沿原路返回。

需求條件

  • 最少兩個 ENIs，分佈在兩個 AZ。
  • 允許對地端 DNS 伺服器 IP 進行 outbound UDP/TCP port 53 連線的 Security Group。
  • VPC 到地端 DNS 伺服器 IP 的路由，透過 VPN/DX/TGW。
  • 至少一條與 VPC 關聯的 Forwarding Rule。

Inbound vs Outbound 方向陷阱 — 考生經常搞反方向。請記住這句話：「Inbound 是地端打進來；outbound 是 AWS 打出去。」情境是「地端伺服器需要解析 AWS PHZ 名稱」，答案是 inbound endpoint + PHZ。情境是「VPC 內的 EC2 需要解析地端 AD」，答案是 outbound endpoint + forwarding rule。許多 hybrid DNS resolver 設計兩種 endpoints 都需要。只選一個卻需要兩個，就是錯誤答案。 參考：https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html

Resolver Rules — Forwarding、System 與 Auto-Defined

Resolver Rule 是一條 DSL 語句，告訴 VPC Resolver 如何處理特定網域名稱的查詢。SAP-C02 測試三種類型。

1. Forwarding Rules（自定義）

最常見的類型：「對於網域 X，透過 outbound endpoint E 將查詢轉送到 IP [Y, Z]。」這類規則由你明確建立。一條 forwarding rule 包含：

  • 網域名稱 — 比對的後綴，例如 corp.example.com。比對採用最長後綴優先，因此 ad.corp.example.com 的優先級高於 corp.example.com。
  • 目標 IPs — 最多六個地端或其他 VPC 的 DNS 伺服器 IP。
  • Outbound endpoint — VPC 的出口路徑。
  • 關聯列表 — 使用此規則的 VPC 清單。一條規則可關聯到多個 VPC。

2. System Rules

System Rules 是 Route 53 Resolver 始終套用的內建規則。最重要的 system rule 規定：「對於 AWS 保留網域（如 amazonaws.com、compute.internal、ec2.internal），一律在內部解析——永不轉送給自定義規則。」這個機制防止你因為建立通配符 forwarding rule 而意外破壞 EC2 中繼資料或 VPC endpoint DNS。你無法刪除或修改 system rules，但可以對更窄的子網域建立覆蓋規則（例如強制轉送 legacy.amazonaws.com——這種操作通常不建議）。

3. Auto-Defined Rules

當你將 Private Hosted Zone（PHZ）與 VPC 關聯時，Route 53 會靜默安裝一條 auto-defined rule，將該 PHZ 網域的查詢路由到內部 PHZ 查找。這些規則不會出現在 Resolver Rules 清單中，但實際存在。Auto-defined rules 在相同後綴長度時總是輸給更長後綴的明確規則，但在後綴相同時優先於 system rules——因此 internal.examhub.cc 的 PHZ 會壓過相同後綴的 forwarding rule。

規則評估順序

對於查詢 payroll.corp.example.com，Resolver 依以下順序評估：

  1. 最長後綴優先 — 無論規則類型，最長後綴的規則獲勝。
  2. 相同後綴時，System rule — 優先於 auto-defined。
  3. 相同後綴時，Auto-defined（PHZ） — 優先於自定義 forwarding。
  4. 相同後綴時，Custom forwarding rule — 最後的 fallback。

在 95% 的實際設計中，你不會遇到同後綴的平手局面；最長後綴的規則獲勝，直接結束。

Resolver Rule 類型速查 — - Forwarding Rule：自定義，由你建立，透過 outbound endpoint 將符合的查詢轉送到地端 IP。

透過 AWS RAM 跨帳號共用 Resolver Rules

在多帳號 landing zone——AWS Control Tower、AWS Organizations 或自行搭建的 hub-and-spoke——你不會希望每個帳號各自定義一份 forwarding rules 副本。維護同步的營運成本不可接受，而設定偏移（drift）會造成靜默的解析失敗。正確模式是在 Network 帳號集中管理 Resolver Rules，並透過 AWS Resource Access Manager（RAM）共用。

共用機制

  1. Network 帳號建立 outbound endpoint 和指向地端 DNS 伺服器的 forwarding rules。
  2. Network 帳號開啟 AWS RAM 並建立一個包含 Resolver Rules 的 Resource Share。
  3. Resource Share 授予 principals 存取權：個別 AWS 帳號 ID、Organizational Unit（OU）或整個 AWS Organization。
  4. 每個消費帳號接受共用（若在組織內且 Share 設為信任 Organization，則自動接受）。
  5. 在每個消費帳號中，管理員將共用規則關聯到一個或多個 VPC。關聯由消費帳號自行控制，因此他們決定哪些 VPC 使用此規則。

Outbound endpoint 本身留在 Network 帳號中——你不共用 endpoints，只有規則可以共用。消費 VPC 的流量透過 Transit Gateway 或 VPC peering 抵達集中的 endpoint；endpoint 可被存取，是因為其 ENIs 位於連接到 TGW 的 Network VPC 中。

節省了什麼

  • 只需支付一個 outbound endpoint 而非 N 個（每省一個 endpoint 約節省 $90/月，再乘以高可用性的兩倍）。
  • 只需維護一組 forwarding rules，地端 DNS IP 變更時只改一處。
  • 整個組織的解析行為一致——沒有任何 spoke 會偏移。

無法共用的項目

  • Private Hosted Zones 無法透過 RAM 共用；PHZ 使用不同的、需明確操作的跨帳號關聯機制（見下節）。
  • Inbound endpoints 也無法共用——但通常也不需要。Network VPC 中的單一 inbound endpoint，透過 TGW 可達，足以處理所有地端查詢。

透過 AWS RAM 共用 Resolver Rules，而非 Endpoints — 在多帳號 hybrid DNS resolver 設計中，將 outbound endpoint 集中放在一個 Network 帳號。在同一個帳號建立 Resolver Rules，並透過 AWS RAM 共用給整個 AWS Organization。每個消費帳號只需將共用規則關聯到自己的 VPC 即可。這能降低成本、消除設定偏移，也是 SAP-C02「大規模集中 DNS forwarding」情境的標準答案。 參考：https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-rules-sharing.html

Route 53 Private Hosted Zones（PHZ）

Private Hosted Zone 是一個只有在特定關聯 VPC 中才能解析的 DNS 區域。PHZ 是 AWS 原生發布內部網域名稱（如 internal.examhub.cc、vpce.examhub.cc、svc.payments.examhub.cc）的方式。PHZ 支援常見的 RR 類型——A、AAAA、CNAME、TXT、SRV、MX——以及指向 AWS 資源的 Alias 記錄（ELB、CloudFront、S3 網站、同區域另一筆 PHZ 記錄）。

關鍵屬性

  • PHZ 只對已關聯的 VPC 可見。來自公開網際網路對該區域網域的查詢將會失敗（或 fallback 至相同名稱的公開區域——即 split-horizon 模式，見下方）。
  • 一個 VPC 可以關聯多個 PHZ（例如同一個 VPC 同時關聯 internal.examhub.cc 和 legacy.examhub.com）。
  • 一個 PHZ 可以關聯多個 VPC，在同一個 AWS 帳號內或透過兩步驟授權握手進行跨帳號關聯。
  • VPC 的 enableDnsHostnames 和 enableDnsSupport 兩者都必須為 true，PHZ 解析才能正常運作——這是一個經典的靜默失敗模式。

跨 VPC 關聯（同帳號）

很簡單：在 Route 53 主控台編輯 PHZ 並新增另一個 VPC ID，兩個 VPC 立即都能解析該區域。

跨帳號 PHZ 關聯（兩步驟）

帳號 A 的 PHZ 可以關聯到帳號 B 的 VPC，但需要一個兩步驟流程：

  1. 帳號 A 執行 create-vpc-association-authorization --hosted-zone-id Z123 --vpc VPCRegion=...,VPCId=vpc-abc，授權帳號 B 的 VPC。
  2. 帳號 B 執行 associate-vpc-with-hosted-zone --hosted-zone-id Z123 --vpc VPCRegion=...,VPCId=vpc-abc，完成關聯。
  3. 帳號 A（選用）執行 delete-vpc-association-authorization 撤銷臨時授權——關聯本身仍會持續存在。

完成後，帳號 B 的 VPC 即可解析該 PHZ。此跨帳號關聯模式是共用服務 VPC 的標準架構：中央 VPC 擁有 PHZ，其他帳號的 spoke VPC 則被關聯進來。

PHZ 無法透過 RAM 共用

一個常見陷阱：PHZ 無法透過 AWS RAM 共用。你必須使用上述的兩步驟 VPC 關聯 API。請勿將此與 Resolver Rules 混淆——後者可以透過 RAM 共用。

PHZ 跨帳號使用 VPC Association，而非 AWS RAM — SAP-C02 會把「透過 AWS RAM 共用 PHZ」作為誘答選項，這是錯誤答案。正確機制是在擁有者帳號執行 create-vpc-association-authorization，再由消費帳號執行 associate-vpc-with-hosted-zone。RAM 可以共用 Resolver Rules、Transit Gateways、子網路和 License Manager，但無法共用 Private Hosted Zones。 參考：https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zone-private-associate-vpcs-different-accounts.html

Split-Horizon DNS 模式

Split-horizon DNS（又稱 split-brain 或 split-view DNS）的意思是相同網域根據查詢者身份的不同而解析出不同的答案。這是 hybrid DNS resolver 的基礎架構模式。經典例子：api.examhub.cc 對外部客戶應解析到公開 CloudFront distribution，而對 VPC 工作負載和地端使用者則應解析到內部 ALB 的私有 IP。

在 AWS 上的實作方式

  1. 為 examhub.cc 建立一個公開 hosted zone，內含 api.examhub.cc → cloudfront-xxx.cloudfront.net（alias）。
  2. 為 examhub.cc 建立一個 Private Hosted Zone，內含 api.examhub.cc → internal-alb-yyy.elb.amazonaws.com（alias）。
  3. 將 PHZ 關聯到所有需要看到私有視圖的 VPC。
  4. 若地端使用者也需要私有視圖，在 PHZ 所在的 VPC 中建立 inbound endpoint，並在地端 DNS 伺服器上新增 forwarding 規則：examhub.cc → inbound-endpoint-IPs。

VPC Resolver 的優先規則

當 VPC 已關聯 examhub.cc 的 PHZ，從該 VPC 內部查詢任何以 examhub.cc 結尾的名稱，都會優先查詢 PHZ。如果 PHZ 有對應記錄，你會得到私有答案。如果 PHZ 沒有該特定名稱的記錄，Resolver 預設不會 fallback 至公開區域——你會得到 NXDOMAIN，或根據 PHZ 中通配符設定，得到一個 catch-all 答案。

這種「無 fallback」行為常讓人出乎意料。若你希望 PHZ 中缺少的名稱能回傳公開答案，你必須在 PHZ 中鏡像這些記錄，或針對特定查詢停用 PHZ。

Split-Horizon 對 SAP-C02 的重要性

Split-horizon 是任何企業同時對外部和內部發布 API，或是對外的 Web App 帶有只在企業網路可見的管理後台時，的預設設計。SAP-C02 情境題常將 split-horizon 與 Resolver inbound endpoints 結合——這就是「地端 AD 使用者需要解析 AWS 私有 endpoints」的架構模式。

將關鍵的公開記錄鏡像進 PHZ 以避免 NXDOMAIN — 若 VPC 已關聯 examhub.cc 的 PHZ，則 VPC 內對 examhub.cc 下任何未知名稱的查詢都會回傳 NXDOMAIN——它們不會溢出到公開區域。請將你仍需要的公開記錄（例如 www.examhub.cc）鏡像到 PHZ 中，或採用命名策略讓內外子網域永不衝突（例如 int.examhub.cc 對應 www.examhub.cc）。 參考：https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html

Conditional Forwarding

Conditional forwarding 是地端對應 AWS Resolver Rules 的功能。它的意思是：地端 DNS 伺服器對特定網域後綴的查詢，轉送到特定目標 DNS 伺服器，同時正常解析其他所有查詢。在 hybrid DNS resolver 設計中，地端的 conditional forwarding 與 AWS 的 Resolver Rules 互相呼應。

完整的來回流程

設想一位在企業辦公室工作的使用者，其筆電 DNS 設定為地端 BIND 伺服器 10.1.1.53：

  1. 使用者瀏覽 admin.internal.examhub.cc。
  2. 筆電查詢 10.1.1.53。
  3. BIND 評估其 conditional forwarders：internal.examhub.cc → 10.0.1.10, 10.0.2.10（Resolver inbound endpoint ENIs）。
  4. BIND 透過 VPN/DX 將查詢轉送到 10.0.1.10。
  5. AWS inbound endpoint ENI 將查詢交給 VPC 內建 Resolver，後者查找 internal.examhub.cc 的 PHZ 並回傳私有 ALB IP。
  6. 答案沿原路返回至筆電。

雙向的 Conditional Forwarding

要建立完全雙向的 hybrid DNS resolver：

  • 地端 BIND/Windows DNS：將 internal.examhub.cc 轉送到 → inbound endpoint IPs。
  • AWS Resolver Rule：透過 outbound endpoint 將 corp.example.com 轉送到 → 地端 DNS IPs。

這就是雙向 DNS forwarding 模式，也是 SAP-C02 任何涉及地端 Active Directory 加上 AWS 託管工作負載的情境中，最常見的正確答案。

DNSSEC Signing for Route 53

DNSSEC（DNS Security Extensions）以密碼學方式簽署 DNS 記錄，讓 resolver 得以驗證回應在傳輸過程中未遭篡改。Route 53 支援對公開 hosted zones 進行 DNSSEC signing（不支援 PHZ——見下方陷阱）。

DNSSEC Signing 在 Route 53 中的運作方式

  1. 對公開 hosted zone 啟用 DNSSEC signing。
  2. Route 53 建立一個 Key-Signing Key（KSK），由 AWS KMS 以使用非對稱 ECC_NIST_P256 規格的客戶自管金鑰作為底層。
  3. Route 53 在內部管理一個 Zone-Signing Key（ZSK）。
  4. Route 53 以 ZSK 簽署區域內的每個 RRset，並自動發布 DNSKEY、RRSIG、NSEC/NSEC3 記錄。
  5. 你在上層區域（TLD 註冊商）發布 DS（Delegation Signer）記錄，建立信任鏈。
  6. 支援 DNSSEC 的驗證型 resolver（如 Cloudflare 1.1.1.1 或 Google 8.8.8.8）在回傳答案給用戶端前驗證簽章。

DNSSEC 不涵蓋 Private Hosted Zones

Route 53 DNSSEC signing 僅適用於公開 hosted zones。Private Hosted Zones 不支援簽署，因為 PHZ 只能從已關聯的 VPC 透過 Route 53 Resolver 解析，而 Route 53 Resolver 是 AWS 受管元件——AWS 將 PHZ 到 Resolver 的路徑視為受信任的內部通道。若需要對內部名稱進行驗證型解析，必須在應用層使用 TLS（mTLS、私有 PKI）。

網域註冊與 DNSSEC

DNSSEC 有兩個相關概念：

  • DNSSEC signing on Route 53（見上方）— Route 53 作為簽署者。
  • DNSSEC for domain registration — 當你的網域透過 Route 53 Domains 註冊時，你可以將 DS 記錄上傳至 TLD 登錄機構。這是信任鏈的「另一半」。

DNSSEC 對 SAP-C02 的重要性

合規和反劫持情境。若題目提及受管制產業、政府工作負載，或「必須防止 DNS spoofing」，答案是對公開 hosted zone 啟用 DNSSEC signing。若題目涉及 VPC 內的私有名稱，DNSSEC 是誘答項——應改選 PHZ 加 Resolver endpoints。

DNSSEC Signing 只適用於公開 Hosted Zones，不適用 PHZs — Private Hosted Zones 無法在 Route 53 上進行 DNSSEC signing。VPC Resolver 不對 PHZ 回應驗證 DNSSEC，因為 PHZ 是受信任的 AWS 內部元件。任何 SAP-C02 答案說「對 PHZ 啟用 DNSSEC」都是錯誤的。若需要內部完整性保證，應仰賴應用層 TLS 和私有 CA（AWS Private CA）。 參考：https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html

Resolver Query Logging（Resolver Query Log Config）

Route 53 Resolver Query Logging 捕獲 Resolver 為已關聯 VPC 處理的每一筆 DNS 查詢，並將日誌事件寫入 CloudWatch Logs、Amazon S3 或 Amazon Kinesis Data Firehose。日誌包含查詢名稱、類型、class、回應代碼、來源 IP，以及查詢是否由快取、PHZ、forwarding rule 或公開 DNS 回答。

為何啟用 Query Logging？

  • 安全鑑識 — 透過檢查查詢模式，偵測 DNS exfiltration、DGA（domain generation algorithm）惡意程式或 beaconing 行為。
  • 合規 — 許多法規（HIPAA、PCI、FedRAMP）要求留存 DNS 活動記錄。
  • 故障排除 — 診斷為何 EC2 實例得到過時或錯誤的答案。
  • 成本歸因 — 找出重複執行數百萬次冗餘查詢的失控服務。

設定物件

Query Log Config 是核心物件。你建立一個指向目的地（CloudWatch Logs 群組、S3 儲存桶或 Firehose stream）的 Config，再將該 Config 關聯到一個或多個 VPC。同一個 Config 可以涵蓋多個 VPC，也可以透過 AWS RAM 跨帳號共用，實現集中式日誌記錄。

記錄內容與不記錄內容

Resolver query logs 捕獲 VPC Resolver 處理的查詢——包括 PHZ 查詢、公開 DNS 查詢和 outbound 轉送查詢。在地端回答（從未到達 VPC Resolver）的查詢不被捕獲——那些需要依靠地端日誌記錄。從地端透過 inbound endpoint 到達的查詢會被捕獲，因為它們通過了 VPC Resolver。

費用

按每百萬筆記錄查詢計費，另加目的地的資料輸入成本（CloudWatch Logs 資料輸入、S3 PUT、Firehose 吞吐量）。請事先規劃：一個查詢頻繁的 VPC 每天可能產生數百萬筆查詢。

儘早啟用 Resolver Query Logging 以供稽核與鑑識 — Route 53 Resolver Query Logging 是稽核 VPC 內 DNS 活動的唯一 AWS 原生機制。在受管制的環境中，在 Network 帳號建立一個集中式 Query Log Config，透過 Firehose（可用於轉換）寫入 Logging 帳號的專用 S3 儲存桶，並將 Config 關聯到每個正式環境 VPC。此模式可自然地與 VPC Flow Logs 和 AWS CloudTrail 組合，形成完整的可觀測性堆疊。 參考：https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html

Transit Gateway DNS Resolution over Peering

AWS Transit Gateway 是連接多個 VPC、VPN 和 Direct Connect gateways 的 hub-and-spoke 路由器。DNS over Transit Gateway 較為微妙，因為 TGW 是一個第三層封包路由器，而非 DNS 感知服務。

TGW 不解析 DNS

TGW 轉送 IP 封包。如果一個 VPC resolver 將 DNS 查詢發送到只能透過 TGW 到達的 IP（例如連接到 TGW 的中央 Network VPC 中的 inbound endpoint），TGW 會透明地轉送該 UDP/53 或 TCP/53 封包，不關心封包的內容。

共用服務 VPC 模式

大多數企業 hybrid DNS resolver 設計會在共用服務 VPC（又稱 egress VPC 或 Network VPC）中集中 inbound 和 outbound endpoints：

+------------------+        +---------------------------+        +---------------+
|  Spoke VPC A     |------->|  Transit Gateway (TGW)   |<-------|  On-Prem DC   |
|  (resolver Rule  |        +---------------------------+        +---------------+
|   via RAM)       |                   ^
+------------------+                   |
                                       |
                              +------------------+
                              |  Network VPC     |
                              |  (inbound +      |
                              |   outbound EP)   |
                              +------------------+

Spoke VPCs 透過 AWS RAM 取得 Resolver Rules。當 spoke VPC 查詢 corp.example.com 時，規則指示「透過 outbound endpoint EP-1 轉送到地端」——但 EP-1 位於 Network VPC，不在 spoke 中。Spoke 的 VPC Resolver 將轉送查詢透過 spoke 的路由表送出，進入 TGW，穿越 TGW 到達 Network VPC，再從 EP-1 透過 VPN/DX 送往地端。回應沿相同路徑返回。

路由表和 TGW Attachment 需求

  • Network VPC 必須**掛載（attached）**到 TGW。
  • 每個 spoke VPC 必須掛載到 TGW，並在子網路路由表中設定路由，將 outbound endpoint ENI IP 透過 TGW 轉送。
  • Network VPC 的子網路路由表必須透過 VGW 或 VPN attachment 將地端 CIDRs 路由出去。
  • TGW 路由表必須允許 spoke 和 Network VPC 之間的流量。

TGW Peering 跨區域

TGW Peering 在兩個 TGW 之間建立跨區域連線。DNS 仍以封包形式流過 peering——但區域 A 的 VPC Resolver 無法原生使用區域 B 的 endpoint，除非你路由查詢的目標 IP 穿過 peering。大多數情況下，你會在每個區域各部署一組 Network VPC（每個區域一組），各自配備獨立的 inbound/outbound endpoints，並讓 Resolver Rules 指向當地區域的 endpoint。跨區域 DNS over TGW peering 技術上可行，但通常沒有必要。

VPC Peering 與 DNS

VPC Peering 本身不能跨 VPC 解析 PHZ 或 EC2 私有主機名稱，除非你明確啟用 peering 的 DNS resolution support。即便啟用，你仍需要將 PHZ 關聯到對等 VPC——peering 只共用網路路徑，不共用區域關聯。

情境：地端 AD 使用者需要解析 AWS 私有 Endpoints

這是 SAP-C02 最經典的 hybrid DNS resolver 情境。需求通常如下：

企業員工透過地端 Active Directory 進行驗證。他們需要存取 api.internal.examhub.cc，這是 VPC 私有子網路內一台內部 ALB。DNS 不得穿越公開網際網路。請提供解決方案。

正確架構

  1. 為 internal.examhub.cc 建立一個 Private Hosted Zone，內含 alias 記錄 api.internal.examhub.cc → internal-alb。
  2. 將 PHZ 關聯到託管 ALB 的 VPC。
  3. 在同一個 VPC 中建立 Resolver inbound endpoint，具備跨兩個 AZ 的兩個 ENIs。
  4. 確保 inbound endpoint 的 Security Group 允許地端 CIDR 的 UDP/TCP 53。
  5. 確保 VPC 透過 VPN/DX/TGW 有回到地端的路由。
  6. 在地端 AD DNS 伺服器上設定 conditional forwarder：internal.examhub.cc → inbound-endpoint-IPs。
  7. 員工的筆電以地端 AD DNS 作為 resolver；api.internal.examhub.cc 的查詢流程：筆電 → AD DNS → inbound endpoint → VPC 內建 Resolver → PHZ → ALB IP → 原路返回。

常見誘答項

  • 「對 PHZ 啟用 DNSSEC」——錯誤；PHZ 無法進行 DNSSEC signing。
  • 「透過 AWS RAM 共用 PHZ」——錯誤；應使用 VPC association authorization。
  • 「使用 outbound endpoint」——方向錯誤；outbound 是 AWS → 地端。
  • 「使用公開 hosted zone 加 internal 子網域」——錯誤；會將內部名稱暴露在網際網路上。

情境：共用服務 VPC 作為集中 DNS

第二個經典情境如下：

一個 AWS Organization 有 30 個帳號，每個帳號有多個 VPC 掛載在集中的 Transit Gateway 上。所有工作負載都需要解析地端的 corp.example.com 名稱。請設計一個具成本效益、易於維護的 hybrid DNS resolver。

正確架構

  1. 在 Network 帳號中，建立一個掛載到 Transit Gateway 的共用服務 VPC。
  2. 在該 VPC 中部署一個 outbound Resolver endpoint（2 個 ENIs，跨 2 個 AZ）。
  3. 建立一條 Resolver Rule：corp.example.com → on-prem-DNS-IPs via outbound endpoint。
  4. 透過 AWS RAM 將 Resolver Rule 共用給整個 AWS Organization。
  5. 在每個 spoke 帳號中，將共用規則關聯到相關的 VPC。
  6. TGW 路由表允許 spoke VPC 透過 VGW 存取 Network VPC 中的 outbound endpoint ENIs 和地端 CIDRs。

為何此架構勝出

  • 一個 outbound endpoint 服務 30 個帳號——節省 29 × $180/月 = 約 $5,200/月。
  • Forwarding rules 的單一真相來源——修改一次，所有帳號立即看到變更。
  • 分散式關聯——每個 spoke 自行決定哪些 VPC 使用此規則。
  • TGW 原生支援——無需 VPC peering mesh，無需重複 endpoints。

比較表：Hybrid DNS Resolver 各機制

機制 方向 用途 可透過 RAM 共用 費用驅動因素
Inbound Endpoint 地端 → AWS 地端解析 AWS PHZ 名稱 否 每 ENI/小時 + 查詢
Outbound Endpoint AWS → 地端 VPC 解析地端名稱 否 每 ENI/小時 + 查詢
Resolver Forwarding Rule VPC 出口設定 定義哪個網域轉送到哪裡 是 免費（透過 endpoint 計費）
Private Hosted Zone（PHZ） VPC 內部 私有區域記錄 否——使用 VPC association 每區域 + 查詢
DNSSEC Signing 僅公開區域 回應完整性 N/A KMS 金鑰 + 簽署
Resolver Query Logging 所有 Resolver 查詢 稽核、鑑識 是（Query Log Config） 每百萬筆查詢 + 目的地費用
System Rule 內建 保護 AWS 保留網域 N/A 免費

Hybrid DNS Resolver 常見考試陷阱

  1. Inbound vs outbound 方向搞反 — inbound 是地端進入 AWS；outbound 是 AWS 連出到地端。
  2. PHZ 透過 RAM 共用 — 錯誤；應使用 create-vpc-association-authorization / associate-vpc-with-hosted-zone。
  3. 對 PHZ 啟用 DNSSEC — 錯誤；DNSSEC signing 在 Route 53 只支援公開區域。
  4. VPC peering 自動解析對等 VPC 的 PHZ — 錯誤；你必須將 PHZ 關聯到對等 VPC，並且啟用 peering 的 DNS resolution support。
  5. 每個 spoke VPC 各一個 outbound endpoint — 運維噩夢；應集中在 Network VPC 並透過 RAM 共用 Rules。
  6. enableDnsHostnames 或 enableDnsSupport 被停用 — 靜默失敗模式；兩者都必須為 true，PHZ 解析才能正常運作。
  7. TGW 代你解析 DNS — 錯誤；TGW 只轉送 DNS 封包，Resolver 才是真正解析的元件。
  8. 為 *.amazonaws.com 建立 forwarding rule — 會被 System Rule 覆蓋；無法破壞 AWS 保留網域。
  9. 對私有名稱依賴公開 DNS — 不安全且緩慢；混合存取一律使用 PHZ + inbound endpoint。
  10. 雙向 AD + AWS 混合架構只使用 inbound endpoint — 完整的雙向解析需要 inbound 和 outbound 兩種 endpoints。

Hybrid DNS Resolver 快速決策樹 — 1. 「地端 → AWS 私有名稱？」→ Inbound endpoint + PHZ。 2. 「AWS → 地端私有名稱？」→ Outbound endpoint + Resolver Rule。 3. 「多帳號大規模擴展？」→ Network VPC + Resolver Rule 透過 AWS RAM 共用。 4. 「PHZ 要在另一個帳號可見？」→ VPC association authorization（兩步驟），不用 RAM。 5. 「公開區域需要簽署？」→ DNSSEC 套用於公開 hosted zone。 6. 「稽核 DNS 活動？」→ Resolver Query Log Config 寫入 S3/CloudWatch/Firehose。 參考：https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/introduction.html

Hybrid DNS Resolver 成本最佳化

  • 集中 endpoints：在 Network VPC 中配置一組 inbound + outbound endpoints，透過 Transit Gateway 存取，優於在每個 VPC 重複部署。
  • 透過 RAM 共用 Rules：消除重複的 outbound endpoints。
  • 謹慎規劃 Query Logging 目的地：在高 QPS 下，CloudWatch Logs 費用可能偏高；改用 Kinesis Firehose → S3 可降低長期存留的費用。
  • 使用 PHZ alias 記錄：指向 AWS 資源的 alias 記錄本身不收取 alias 查詢費用。
  • 留意失控應用程式：行為異常的應用程式每小時可能執行 100 萬次以上的 DNS 查詢；Resolver Query Logs 能讓你及時發現。

安全考量

  • Resolver endpoint Security Groups 應限制 port 53 的來源只允許地端 CIDRs（inbound 用），以及目的地只允許已知的地端 DNS IP（outbound 用）。在 port 53 上開放 0.0.0.0/0 會讓你的 endpoint 成為開放 resolver，構成 DDoS 放大攻擊風險。
  • DNS query logging 是一項合規控制；請依照你的法規要求留存日誌。
  • DNSSEC 防止公開端的快取中毒；結合應用層 TLS 可實現縱深防禦。
  • IAM 權限對於 Resolver Rules 和 PHZ 操作應嚴格限縮範圍；一個放錯位置的 route53:AssociateVPCWithHostedZone 授權可能將內部名稱洩漏到不受信任的 VPC 中。
  • AWS PrivateLink endpoints 搭配 hybrid DNS 使用時，必須啟用 endpoint 的 private DNS 功能，且 VPC 的 enableDnsSupport 旗標必須為 true，否則 PrivateLink DNS 名稱無法覆蓋公開名稱。

Hybrid DNS Resolver vs 第三方 DNS 設備

部分企業以 Infoblox、BlueCat 或自行架設的 BIND 叢集作為其授權內部 resolver。Hybrid DNS resolver 模式同樣適用，差別只在 Resolver Rules 指向設備 IP 而非原生 AD DNS。主要取捨：

  • Route 53 Resolver endpoints + PHZ 是全受管服務，自動擴展，並與 AWS RAM 和 CloudWatch 整合——但需支付 ENIs 和查詢費用。
  • 第三方設備提供集中化 IPAM 功能和地端一致的操作體驗，但你必須在 EC2 上自行維運叢集，並支付實例費用、授權費和修補作業成本。

SAP-C02 的正確答案通常圍繞受管的 Route 53 Resolver 模式。第三方設備答案往往是誘答項，除非題目明確提到既有的 DNS 投資。

常見問題 — AWS Hybrid DNS Resolver

Q1：Resolver inbound endpoint 和 outbound endpoint 有什麼差別？

Inbound endpoint 讓 DNS 查詢能從地端流入 VPC Resolver，通常用於讓地端伺服器解析 Private Hosted Zone 名稱。Outbound endpoint 讓 DNS 查詢能從 VPC Resolver 流出到地端，通常用於讓 EC2 實例解析地端私有名稱。完整的雙向 hybrid DNS resolver 需要同時部署兩者。

Q2：我可以透過 AWS RAM 跨帳號共用 Private Hosted Zone 嗎？

不行。Private Hosted Zones 無法透過 AWS RAM 共用。請使用兩步驟的 VPC Association Authorization 流程：擁有者帳號執行 create-vpc-association-authorization 授權另一個帳號的特定 VPC，再由消費帳號執行 associate-vpc-with-hosted-zone 完成關聯。AWS RAM 可處理 Resolver Rules、Transit Gateways 和許多其他資源，但不包含 PHZs。

Q3：Route 53 是否支援 Private Hosted Zones 的 DNSSEC？

不支援。Route 53 DNSSEC signing 僅適用於公開 hosted zones。Private Hosted Zones 無法進行 DNSSEC signing，因為解析透過受信任的 AWS 受管 VPC Resolver 進行，AWS 將其視為內部安全通道。若需要內部名稱的完整性保證，請依賴應用層 TLS 搭配 AWS Private CA。

Q4：如何在 30 個 AWS 帳號中集中管理 hybrid DNS resolver？

在專用 Network 帳號中部署一個 Network VPC，將其掛載到 Transit Gateway，並在該 VPC 中建立 outbound Resolver endpoint 以及針對地端網域的 forwarding Resolver Rules。透過 AWS RAM 將 Resolver Rules 共用給整個 AWS Organization。每個 spoke 帳號再將共用規則關聯到自己的 VPC。若需要地端 → AWS 解析，在同一個 Network VPC 中加入 inbound endpoint，並在地端 DNS 伺服器上新增指向它的 conditional forwarder。

Q5：VPC 中 Resolver Rules 的評估順序是什麼？

Route 53 Resolver 以最長後綴符合原則評估。若兩條規則的後綴長度相同，System Rules（內建，用於 AWS 保留網域）優先，其次是 Auto-Defined Rules（關聯 PHZ 時安裝），最後是自定義 Forwarding Rules。在實務上，大多數設計使用各自不同的後綴，最長符合規則不會產生歧義。

Q6：AWS Transit Gateway 是否執行 DNS 解析？

不會。Transit Gateway 是第三層封包路由器。它在已掛載的 VPC 和地端網路之間轉送 DNS 封包（UDP/TCP port 53），但不會檢查、快取或解析 DNS 查詢。DNS 解析始終由每個 VPC 內的 Route 53 Resolver 執行，必要時輔以 Resolver endpoints 延伸。

Q7：為何即使 PHZ 已關聯，VPC 實例仍無法解析 PHZ 名稱？

請確認 VPC 的 enableDnsHostnames 和 enableDnsSupport 兩者都設為 true。任一旗標停用時，PHZ 解析會靜默失敗。同時確認正在使用 VPC Resolver——自訂的 /etc/resolv.conf 條目指向外部 DNS 將完全繞過 Resolver。

可以，但需要正確的 hybrid DNS resolver 設定。PrivateLink endpoints 在 amazonaws.com 下建立私有 DNS 名稱。當 VPC 的 endpoint 啟用了 private DNS，VPC Resolver 會以 endpoint 的私有 IP 覆蓋公開 DNS 名稱。若要讓地端使用者繼承此行為，在 VPC 中部署 Resolver inbound endpoint，並設定地端 DNS 將 amazonaws.com 子查詢（或至少是你需要私有化的特定 endpoint 子網域）轉送到 inbound endpoint。將整個 amazonaws.com 轉送範圍通常過於寬泛；請只轉送你確實需要私有解析的特定服務子網域。

Q9：Resolver Query Log Config 記錄哪些內容？

Query Log Config 捕獲 Route 53 Resolver 在已關聯 VPC 中處理的每一筆 DNS 查詢，包含查詢名稱、類型、來源 IP、回應代碼，以及解析路徑（PHZ、forwarding rule、公開 DNS）。日誌可寫入 CloudWatch Logs、S3 或 Kinesis Firehose。Config 本身可透過 AWS RAM 跨帳號共用，以實現集中式日誌記錄。

Q10：何時應選擇第三方 DNS 設備而非 Route 53 Resolver？

通常只有在你已在地端運營成熟的 DNS/IPAM 平台（Infoblox、BlueCat）並希望在 AWS 使用相同工具集，或需要 Route 53 不提供的功能（全域視圖、豐富 IPAM、自訂查詢腳本）時才考慮。對於全新的 AWS 設計或 SAP-C02 考試情境，答案幾乎都是 Route 53 Resolver + PHZ + 透過 RAM 共用的 Resolver Rules——費用更低、全受管，且與 AWS 原生日誌記錄和 IAM 整合。

總結 — Hybrid DNS Resolver 速查表

  • Inbound endpoint = 地端 → AWS VPC Resolver。
  • Outbound endpoint = AWS VPC Resolver → 地端。
  • Resolver Rules 轉送查詢；透過 AWS RAM 共用以跨帳號擴展。
  • Private Hosted Zones 發布內部名稱；與 VPC 關聯，跨帳號透過 VPC association authorization（不用 RAM）。
  • DNSSEC signing 只保護公開區域；PHZ 不支援。
  • Query Log Config 稽核 Resolver 活動；寫入 CloudWatch/S3/Firehose。
  • Split-horizon DNS 混合同名的公開與私有區域；PHZ 在已關聯的 VPC 內部優先。
  • Conditional forwarding 在地端對應 AWS Resolver Rules；兩者合力實現雙向混合解析。
  • Transit Gateway 只轉送 DNS 封包，不負責解析；請將 endpoints 集中在掛載到 TGW 的 Network VPC 中。
  • 兩種 endpoints、一個 Network VPC、RAM 共用 Rules 是 SAP-C02 的標準架構。

把這九行寫在一張索引卡上，大多數 SAP-C02 hybrid DNS resolver 考題都能迎刃而解。

官方資料來源