AWS 基礎コース / Chapter 13

Route 53で、ドメインの責任を環境ごとに委任する

DNSはURLをIPへ変換するだけの仕組みではない。どのゾーンがその名前に答える権威を持つかをつなぎ、環境の運用境界を作る。

TL;DR

  1. Hosted Zoneは特定ドメインのDNSレコードを管理する場所で、NSレコードが権威DNSを示す。
  2. 親ゾーンに子ゾーンのNSレコードを置くと、サブドメインの問い合わせを別ゾーンへ委任できる。
  3. prdが親ドメイン、stgがサブドメインを管理すると、検証環境のDNS変更を本番アカウントから分離できる。

01DNSの「登録」と「回答責任」を分けて理解する

ドメインを持つことと、その名前のDNSレコードを管理することは別

ドメイン登録とRoute 53 Hosted Zoneの役割の違い
名前の所有とDNSの回答設定は別の管理対象。

ドメインを登録すると名前を利用できるが、アプリの接続先を答えるにはHosted ZoneでDNSレコードを管理する必要がある。DNS設計では、どのゾーンが何に答えるかを追う。

Hosted Zoneを作っただけでは、親側から委任されていないサブドメインは外部から期待通りに解決されない。

02親ゾーンから子ゾーンへNSで委任する

stg.example.comの回答責任を、stg用Hosted Zoneへ渡す

親ドメインからstgサブドメインへDNSを委任する図
親ゾーンのNSレコードが、子ゾーンを権威ある回答者として指名する。

stgアカウントでstg.example.comのHosted Zoneを作ると、固有のNSレコードが発行される。そのNS値をprdアカウントの親ゾーンへ登録すると、サブドメインの問い合わせが子ゾーンへ委任される。

子Hosted ZoneのNS値をコピーするだけでは不十分。親ゾーン側に同じNSを登録して初めて委任になる。

03環境のDNS責任をアカウント境界へ合わせる

stgのレコード更新をstgアカウント内で完結できるようにする

本番とステージングでDNS管理権限を分ける図
委任後はstg内のレコードをstgアカウントで管理できる。

親ドメインの権威管理はprdに残しつつ、stgサブドメインのレコードはstgアカウントで変更できる。この分離により、検証環境の日常運用で本番アカウントへのアクセスを減らせる。

委任確認にはdig NSを使い、表示されたネームサーバーが子ゾーンの値と一致することを確かめる。

結論

  1. DNSは名前を解決するだけでなく、回答責任を委任する仕組み。
  2. 親ゾーンのNSレコードでstg子ゾーンへ委任する。
  3. DNS運用の責任範囲をアカウント境界と揃える。