Amazon Route53の名前解決機能を整理してみる

こんにちは。技術2課の加藤ゆです。
最近アレルギー検査をしたら、スギ・ヒノキ・ハンノキ・シラカバが陽性だと判明しました。
あと猫も・・かなしい。断トツでバチバチに陽性だったのはダニ・ハウスダストです。

さて、今回はAmazon Route53の名前解決機能を、DNSの基本的な機能を元に整理してみます。

Amazon Route53とは
DNSの機能
Route53の名前解決機能
まとめ：Amazon Route 53
利用料金
おわり

Amazon Route53とは

Route 53 は、DNS レコードの作成・管理が出来るサービスです。
ドメインネームシステム (DNS)、ドメイン名登録、ヘルスチェックが提供されています。

aws.amazon.com

新規ドメイン用に DNS レコードを作成したり、既存ドメインの DNS レコードを転送したりすることが可能です。

参考資料：Route53のBlackbeltがとても分かりやすいです
・AWS Black Belt Online Seminar Amazon Route 53 Resolver 編(2023/05)
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-Route53-Resolver_0530_v1.pdf

・AWS Black Belt Online Seminar Amazon Route 53 Resolver(2019/10/16)
20191016 AWS Black Belt Online Seminar Amazon Route 53 Resolver | PPT

DNSの機能

Route53 の説明の前に、DNSとしての機能説明をします。

DNS（Domain Name System）は、「ドメイン名（www.example.com等）」と「IPアドレス」を紐づけて変換する仕組みです。

この「DNS」を利用して、ドメイン名ーIP アドレスを取得することを「名前解決」といます。
まずは名前解決に必要となるDNSの機能を説明します。

ここでは以下の4機能を取り上げます。

項番	機能	概要
1	ネームサーバー（権威サーバー）	各名前空間（.com、.example.com等）を管理するデータベース。 .(ルート) から順次問い合わせされる先の一つ一つのサーバー。
2	フルサービスリゾルバ	ネームサーバーへの問い合わせた回答を、問い合わせ元のクライアントに回答を返す機能をもつ。
3	フォワーダー	クライアントからの問い合わせを、ルールに従って中継する機能をもつ。
4	スタブリゾルバ	クライアントのOS上に組み込まれている。問い合わせるクライアント側に実装されている。

ネームサーバー

各名前空間（.com、.example.com等）を管理するデータ（ゾーン情報）を持っています。
.(ルート) から順次問い合わせされる先のサーバーが「ネームサーバー」です。

ネームサーバーは、「ルート」を頂点とする階層構造になっています。

尚ドメイン名のうち、ルートを起点として一番右を「トップレベルドメイン（TLD）」、
その次を「セカンドレベルドメイン（2LD）」、
3番目は「サードレベルドメイン（3LD）」と呼ばれます。

フルサービスリゾルバ（キャッシュDNSサーバー）

クライアントは、名前解決の実行時にネームサーバーへ直接問い合わせは行いません。
間にフルサービスリゾルバを挟みます。

クライアントから受けた問い合わせを、.(ルート) から順次ネームサーバーへ問い合わせます。

またフルサービスリゾルバは、回答効率をよくするために一定時間キャッシュを保持します。

フォワーダー

名前解決を実施する機能ではなく、問い合わせの中継をする機能です。
設定されているルールに基づき、フルサービスリゾルバへ繋ぎます。

フォワーダーは、反復問い合わせはしません。
クライアントから再帰的問い合わせを受け取り、ルールを参照し、再帰的問い合わせを行います。

反復問い合わせ・再帰的問い合わせ
これはあくまで私の理解ですが、どうも覚えられなくて下記のノリで記憶しています。

・「再帰的問い合わせ」：絶対に回答を返してほしいマン
　→ 絶対に回答返してほしいので、答えにたどり着くまではクライアント側に返れないリクエスト。たどり着くまで何度もネームサーバーを聞きに行く。

・「反復問い合わせ」：持ってる情報だけで回答もらうマン
　→ リクエスト先でお手元の情報だけ受け取れれば、クライアント側に返れるリクエスト。

スタブリゾルバ

クライアントのOS上に組み込まれているDNS機能のことです。

問い合わせるクライアント側に実装されています。２つのネームサーバーを設定していることが多いですね。
（例：Linuxの「/etc/resolve.conf」、Windowsのネットワークインターフェースの設定）

フルサービスリゾルバのように、. (ルート) から順次問い合わせ（反復問い合わせ）を行うのではなく、再帰的問い合わせをします。

補足：3機能が同居した「DNSサーバー」

フォワーダー・フルサービスリゾルバ・ネームサーバーの3種の機能は一括で提供されている場合が多いです。
その場合、ひとつの「DNSサーバー」として、3機能が同居して構成されている状態になります。

※図に記載したネームサーバーは、社内の名前解決を行うDNSサーバーのイメージ

このような複数機能を有する「DNSサーバー」に向けて、名前解決を行っているため、クライアントが機能を意識しないことも多いです。

Route53の名前解決機能

AWSが提供するDNSのサービスが「Amazon Route53」です。

上項で説明したDNSの機能と当てはめながら、Route53の機能を記載します。

１．HostedZone

HostedZoneは、ネームサーバーの機能です。
ドメイン名のレコードを管理しています。

2種類ありますが、インターネット上に公開するか否かの違いです。

項番	HostedZone	説明
1	Public Hosted Zone	インターネット上に公開されたDNSドメインのレコードを管理する
2	Private Hosted Zone	VPC内 or 社内などのプライベート環境のDNSドメインのレコードを管理するプライベートな問い合わせに対する振る舞いを指定する

Private Hosted Zoneを利用する際は、VPCに標準で設定されている「Amazon Route53 Resolver」を利用する必要があります。

２．Route53 Resolver（旧 Amazon Provided DNS）

実態は、「フォワーダー＋フルサービスリゾルバ」です。

マネジメントコンソール画面を見ると分かる通り、Route53 ResolverはVPC毎に存在しています。

Route53 Resolverは、VPCを構築すると標準で用意されますので意図して構築することは無いでしょう。
VPC ネットワーク範囲のベースプラス 2 したIPアドレスが、Route53 Resolver用のIPアドレスとして確保されています。

IPv4 のサブネットのサイズ設定
例えば、CIDR ブロック 10.0.0.0/24 を持つサブネットの場合、次の 5 つの IP アドレスが予約されます。
～～略～～
・10.0.0.2: AWS が予約しています。
DNS サーバーの IP アドレスは、VPC ネットワーク範囲のベースにプラス 2 したものです。
複数の CIDR ブロックを持つ VPC の場合、DNS サーバーの IP アドレスはプライマリ CIDR にあります。
また、VPC 内のすべての CIDR ブロックに対して、各サブネットの範囲 + 2 のベースを予約します。
サブネット CIDR ブロック - Amazon Virtual Private Cloud

３．Inbound Endpoint・Outbound Endpoint

上項で記載の通り、Route53 ResolverはVPC毎に存在していましたね。

従って、当VPC外の環境からRoute53 Resolverにアクセスする場合、当VPC内にEndpointを用意してあげる必要があります。
Route53 Resolverは、VPC外からの直接的なDNSクエリは受け付けません。

考え方は簡単で、Resolverに入るために使うか、Resolverから出るために使うか、です。

項番	Endpoint名	説明
1	Inbound Endpoint	VPC外部から、Route53 Resolverにアクセスするための入り口
2	Outbound Endpoint	VPC内のRoute 53 Resolverが、VPC外のリゾルバー（オンプレミス、他VPCのRoute 53 Resolver Inbound Endpoint)にアクセスするための出口

ユースケースとして、以下のパターンが考えられます。

オンプレミス⇔AWS環境間でRoute53 Resolverを利用するとき
VPCを跨いでRoute53 Resolverを利用するとき

Inbound Endpoint

オンプレミス・インターネットから、VPC内のリソース（Provided Private DNS hostnames） or PrivateHostedZone 向けに名前解決を行う際のリクエストの流れ（サンプル）です。

インターネット向け（オレンジ線）
- Inbound Endpoint ＞ Route53 Resolver ＞ PublicHostedZone or インターネット上のネームサーバーへ反復問い合わせ
VPC内のリソース（Provided Private DNS hostnames） or PrivateHostedZone 向け（青線）
- Inbound Endpoint ＞ Route53 Resolver ＞ PrivateHostedZone Provided or Private DNS hostnames へ反復問い合わせ

Outbound Endpoint

VPC内から、VPC外のオンプレミス・別VPC向けに名前解決を行う際のリクエストの流れ（サンプル）です。

EC2 ＞ Route53 Resolver ＞フォワーダーにてリゾルバ―ルールを参照＞ Outbound Endpoint ＞オンプレミス（緑線） or 別VPC（黄線）＞以降略

４．リゾルバールール

Route53 Resolverのうち「フォワーダー」機能を制御する「ルール」に該当するものです。

指定したドメイン名の DNSクエリを、指定したネームサーバーに転送する or Route53 Resolver自体で回答するのか、等を指定するルールタイプです。
ルールタイプは、3種類あります。

項番	ルールタイプ	説明	設定例
1	転送	指定したドメイン名の DNSクエリを、指定した別のネームサーバーに転送する	[転送するドメイン名]：[転送するターゲットのIPアドレス] を指定
2	システム	転送ルールで定義されている動作を選択的に上書きする	①[example.com] ：[フルサービスリゾルバ] に転送する ②[xxx.example.com]のみ例外として挙動を変えたい →このように元のルール対し上書きして、設定が出来るルールタイプ
3	再帰的	標準で設定されている転送タイプ。ルールに該当がない「その他」に該当するドメイン名に対して、再帰リゾルバーとして機能するために必要なルール。アカウントにあるすべてのVPCに対して自動的に関連付けられます。	再帰的ルールはこちら ※削除・変更は出来ないルールですマネジメントコンソール画面

補足：VPC内のAWSリソースの名前解決はどうなっているのか？

おそらく、通常EC2等をご利用いただいている際には
Inbound/Outbound Endpoint の作成せずとも、EC2はインターネットの名前解決が出来ていると思います。

たとえば、以下のような名前解決の実行です。

AWSリソース→インターネット（Publicに存在するDNSサーバー）向けの名前解決
インターネット→EC2（PublicなDNSホスト名）の名前解決

AWSリソースを構築すると、DNSホスト名が設定されます。

そのため、意識的に設定をせずとも名前解決が可能となっているのです。
EC2の例を以下にあげます。

パブリック IPv4 DNS名：<ec2-public-ipv4-address>.<リージョン名>.compute.amazonaws.com
プライベート IPv4 DNS 名：<ec2-private-ipv4-address>.<リージョン名>.compute.internal

まとめ：Amazon Route 53

各Route53の機能をひとことでまとめてみます。

項番	サービス・機能名	役割
1	Amazon Route 53 HostedZone	ネームサーバー
2	Amazon Route 53 Resolver	フォワーダー + フルサービスリゾルバ
3	Inboundエンドポイント	VPC外からRoute53 Resolverにアクセスするための入り口
4	Outboundエンドポイント	VPC内のRoute 53 Resolverが、外部のリゾルバー（オンプレミス、他VPCのRoute 53 Resolver Inbound Endpoint)にアクセスするための出口
5	リゾルバールール	「フォワーダー」機能を制御するルール機能

利用料金