はじめに

年末から多忙を極め、書きたい記事も中々書けなかった @___nix___ です。

背景

様々な企業さまのお手伝いをする中で、AWS環境とRoute53の最適化がされていないと「何で？」と思うことが多々ありました。
また、IaC による開発でも「開発しているAWS環境で閉じられない」というのはインフラとしても手数が掛かるので出来るだけ運用をスマートにしたいと考えるわけです。

例えば開発環境で Amplify を使っているケースで、「カスタムドメイン設定したいのでレコード追加してください」という依頼。IaC なんだからインフラ頼らなくても良くね？と。

AWS使ってるのであれば出来るだけ設定は環境毎に閉じて欲しいという思いからこの記事の執筆を決めました。

概要

AWSアカウントとRoute53の関係を最適化する為には DNSの権限委譲を理解する必要があります。
この権限委譲の説明と手順を交えながら進んでいこうと思います。

DNSの権限委譲

DNS権限委譲とは？

DNSの権威委譲は、ドメイン名の管理を階層的に委譲する仕組みです。ルートゾーンから順に.com/.net/.orgなどのTLD、その下に組織ドメインが続きます。

各組織はレジストリから権限を委譲され、自身のドメインの名前解決情報を自由に設定できます。DNSはクエリされたドメインの権威を探しながら名前解決を行います。

この仕組みにより、ドメイン管理が分散化され、インターネットの成長に合わせてスケーラブルなDNS運用が可能になっています。

example.com の hoge.example.com への権限委譲

example.com はドメインレジストリから自身のドメインの管理権限を委譲されています。
その権限の一部を自身の下位ドメインである hoge.example.com に対して委譲することができます。

具体的には、 example.com は hoge.example.com のネームサーバーの設定情報をDNSに登録することで、 hoge.example.com に関する名前解決の権威が hoge.example.com の管理者に移譲されます。

hoge.example.com の管理者は、自身のドメインのDNSレコード(AレコードやCNAMEレコードなど)を自由に設定でき、そのドメイン内のサブドメインの管理もできるようになります。

一方、 example.com の管理者は hoge.example.com の具体的な設定には関与せず、ルート権限を持った状態でメインの example.com ドメインの管理を行います。

このようにDNSの権威委譲は階層的に行われ、各レベルでドメインの管理責任が分散されることで、柔軟でスケーラブルなDNS運用が可能になっています。

Route53 で権限委譲

全体図

商用環境, ステージング環境, 開発環境それぞれ別のAWSアカウントIDを持つ3つの環境を想定しています。

権限委譲の手順

example.com のホストゾーンを商用環境に登録
stg.example.com のホストゾーンをステージング環境に登録
stg.example.com の NS（赤枠部分）を example.com にタイプ=NS で登録（{stgのNS}の説明部分）
同様に dev.example.com のホストゾーンを開発環境に登録
dev.example.com の NS を example.com にタイプ=NS で登録（{devのNS}の説明部分）

権限委譲の確認

何も考えずに dig stg.example.com ns +short と、呪文を唱えましょう。

# dig stg.example.com ns +short
ns-****.awsdns-**.net.
ns-****.awsdns-**.org.
ns-****.awsdns-**.co.uk.
ns-****.awsdns-**.com.

※ {stgのNS} と同じ内容になっていればOK

同じように開発環境も dig dev.example.com ns +short の呪文を唱えて {devのNS} と同じであればOKです。

何が嬉しいのか？

レコードの自動設定

ACM

商用環境で証明書を発行する時に example.com, *.example.com な SAN で証明書を発行すれば [Route53 でレコードを作成] のボタンを押すことで証明書の検証レコードが Route53 に自動設定されます。

Amplify

カスタムドメイン設定の際にこれも証明書の検証レコードが Route53 に自動設定されるので TLS化も容易です。

etc...

他にも自動連係しているサービスがあります。

カスタムドメイン

証明書

各環境で様々なホスト名で証明書が必要になっても以下の証明書が環境毎に1つあれば随時追加の必要がありません。

商用環境の SAN 証明書 ... example.com, *.example.com
ステージング環境の SAN 証明書 ... stg.example.com, *.stg.example.com
開発環境の SAN 証明書 ... dev.example.com, *.dev.example.com

環境毎の開発

商用環境の Route53 で example.com を権限委譲無しで管理している場合、ステージング環境で api.stg.example.com が必要になったら商用環境の Route53 にレコードを追加しなければいけません。

ステージング環境でホストを追加したい場合、その変更作業もステージング環境で閉じることは誤った設定のリスクも軽減することが可能です。

開発環境でも同様です。
開発環境で使いたいホスト名をわざわざ商用環境の Route53 に設定するのは面倒ですよね。

DNSレコード管理

環境毎にDNSレコードが管理されるので、一つのホストゾーンにあらゆる環境、あらゆるホスト名が混在することがありません。
レコード数が多くとなると見通しも悪くなり、管理・運用に影響が出そうです。

終わりに

とても便利な Route53 と DNS権限委譲ですが、設定を間違うと大事故に繋がります。
それは「DNSとはそういうもの」だからです。

ネットワークの設定と同様に、一つの設定ミスが致命傷になりますのでご注意ください。
その為にも環境毎に設定を分けておくことをお勧めしています。

一言

最後にクイズです。

記事にあるDNS権限委譲の設定において dev.example.com のホストゾーン内（開発環境）に作った hoge.dev.example.com と example.com のホストゾーン内（商用環境）に作った hoge.dev.example.com はどちらが優先されるでしょうか？

答えば分かった方はコメント欄か @___nix___ までご一報ください。

DNSを深く理解してお付き合いしていきましょう♪

AWSアカウントとRoute53の最適化