【AWS】用語を整理しながら学ぶAWS - Amazon Route 53

# 【AWS】用語を整理しながら学ぶAWS - Amazon Route 53

## はじめに

この記事では 用語を整理しながらAWSが提供するAmazon Route 53 を学習していく記事です。
主な内容としては実践したときのメモを中心に書きます。（忘れやすいことなど）
誤りなどがあれば書き直していく予定です。

なお、内容につきましては2023年3月14日時点の調査内容で記載しております。あらかじめご了承ください。

## 目次

- 今回扱うサービス
- 前提知識(DNSと関連技術)
- Amazon Route 53とは(解説)

## 今回扱うサービス

今回は以下のサービスを扱います。

- Amazon Route 53(Route53)

ざっくりいうとAWSさんとこのつよつよDNSサービスです。
そもそもDNSって何だっけ？名前解決？アドレス教えてくれる系のサービス？
まずは前提知識からおさらいしていきましょう。

## 前提知識

### DNSとは

ズバリ、Domain Name System とは名前からアドレスを教えてくれる仕組みです。
そんなことはわかっているし、そもそも何でDNSっていう仕組みが必要なのサって思う人が大多数だと思うのでDNSの成り立ち、歴史を振り返ってみましょう。

#### 補足: DNSの歴史(DNSがなかったとき)

そもそもですが、その昔にはDNSという仕組みすらありませんでした。
「えっ！じゃあどうやってWebサイトやサーバにアクセスしていたの！！？」とそう思うかもしれません。

今でこそほとんど意識しませんが、実は私たちが利用するPCではそれぞれホスト名とアドレスを対応づけるテキストファイルがあります。このファイルは`hosts`、俗に`ホスツファイル`と言われています。
簡単に言えば、DNSという仕組みが構築される以前は自身の知る範囲でのみサーバへのアクセスを実行していました。

「それじゃあ、新しく構築したサーバのアドレスを知るにはそのホスツファイルに名前を書いて更新するのか？」

つまりはそういうことになります。そこで察しの良い人は気づいたかもしれません。

「各自でホスツファイルを更新するなんてことをしたら、新しくサーバが追加されたことを知らずに生きることになるのでは？」

これは実際にその通りです。ですのでホスツファイルの内容を常に同期させるにはどうしたら良いか最初に考案された方法としては

`ホスツファイルを管理する組織を作って、サーバの名前を一元管理する`

という方式に辿り着きました。こうして名前を管理する組織
つまりは`レジストリ`が誕生しました。

#### 補足: DNSの歴史(レジストリが誕生)

レジストリが一元管理するのはいいけど、名前を登録する人と名付けされるマシンはどんどんと増えていく
いわゆる、「一元管理の限界が来てません??」という状況まで来ました。

そもそもインターネットで名前を解決するようにする為に一組織が全部を管理するのには無理があった為
「自分たちと似たような権限を持ちつつ、名前に被りが無いように管理することはできないか」という考えに至り、集中管理の名前管理から分散管理の体制に移行しました。

そこで階層化と権限委任という考え方が考案されました。

#### 補足: DNSの歴史(階層化と権限委任)

名前を管理する組織を複数に分割して階層構造にし、名前の管理権限を委任することで複数の組織が名前を管理できるようになりました。

ここまででようやく今の形に近づいて来ましたが、この状態だと名前が被る可能性があります。
そこで名前を分割する方法として`名前空間` が使われるようになりました。

`名前空間`とは名前に紐づく名字やIDのようなものです。
例えば、人の名前で言うとKentoは死ぬほど世の中にいますが、Yamadaという名字が付いている人でかつエンジニアでTwitter IDが`@ymd65536`の人とすると一意に定まります。

名前が被らない状態を維持する為にツリー構造が採用されました。

![dns-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/527543/45f6c834-a069-53ab-e4bc-40c669930eee.png)

上記のツリー構造をルート(根っこ)から辿ることによってインターネット上で一意の名前を保つことが可能となりました。
ここで名前空間によって分割された範囲を`ドメイン(domain)`、その範囲にある名前のことを`ドメイン名(domain name)`と言います。

この図では`engineer`や`Yamada`などがドメインとなり、`ymd65536.Kento.Yamada.engineer`がドメイン名になります。
※厳密にはルートという概念もありますが、今回は割愛

#### 歴史のまとめ

ここまででの話を簡単にまとめると

- 元々はホスツファイルを使って名前を管理していた
- ホスツファイルは特定の組織が管理していたが、限界が来たので権限を委任するようにした
- 名前が被らないようにツリー構造のデータ構造を採用した
- ツリー構造を採用するプロセスで名前空間という概念が生まれ、ドメインとドメイン名が誕生した

まだまだ語るところはありますが、歴史としては概ね十分だと思うので次からはDNSを扱う上で理解しておく用語について解説します。

### DNSとは(再掲)

Domain Name System とは名前からアドレス教えてくれる仕組みです。
がしかし、歴史を読んでみると

:::note info
DNSとはつまり
「名前空間でドメインを構築後、それぞれのドメイン名を作成してツリー構造でドメイン名を分散管理する仕組み」
とも捉えることができます。
:::

### 名前解決とは

ドメイン名の役割については概ね理解ができたと思います。
そして本来、ドメイン名のような文字列を機械は理解することができません。そこで機械はこのドメイン名をIPアドレスに変換して理解します。

これを`名前解決`と言います。この名前解決を理解するには`ゾーン`という概念を理解する必要があります。

### ゾーンとは

ゾーンとは名前空間によって分割された範囲であり、名前管理の権限を委任された範囲です。
ゾーンそれぞれにはドメインが存在します。

例えば、URLの末尾がjpの場合はjpと名のつくゾーンに所属しているドメインとなります。
`example.jp`　であれば、`jp`ドメインのゾーンに`example.jp`が所属しているということになります。

ドメイン名からゾーンを理解した後、名前解決を実行してIPアドレスを取得するということになります。

### NSレコード

ここまで概ね、DNSの仕組みを理解することができたと思います。では具体的にどのようなデータ構造でアドレスを解釈しているのでしょうか。アドレスを解釈する為のデータ構造としてDNSでは`レコード`というものを使っています。

また、名前解決をするにあたって名前を管理する権限を委任しているとも説明しました。

権限を委任する上で重要なこととして特定のドメインがどのDNSサーバに所属しているか指し示す必要があります。
これを管理するレコードをNSレコードと言います。
特徴的なのはドメイン名とDNSサーバの名前を関連付けるところです。

BINDでは以下のように書きます。（ゾーンを定義するファイル、ゾーンファイルでの書き方）
※BINDはDNSサーバを構築する為のソフト

```text
example.com.      IN NS         ns1.example.com.
```

### Aレコード

おそらくレコード聞いて最初に想像するレコードかと思いますが、アドレスとドメインを紐づけるレコードのことを`Aレコード`と言います。

```text
www.example.jp. IN A 198.51.100.0
```

DNSで用いる名前は省略することができますが、`www.example.jp.`というように省略せずに書いた名前のことを`FQDN`と言います。
また、名前からアドレスを割り出す作業を`正引き`または`forward lookup`と言います。

### 補足：AAAAレコード

AレコードはIPv4で用いられる方式ですが、昨今ではIPv6も採用されています。
IPV6では`AAAAレコード`が採用されています。

AAAAレコードとAレコードは正引きに利用される観点では同じですが、IPv4かIPv6かの違いがあります。

### MXレコード

全ての名前はAレコードで管理されているのかというとそれは違います。
皆さんが使っているメールでは`MX(mail exchanger)レコードが参照されています。

BINDでは以下のように書きます。（ゾーンを定義するファイル、ゾーンファイルでの書き方）

```
example.com.    IN MX 10     mail.example.com.
```

メールサーバとのやり取りではドメインを見て、メールサーバとのやりとりを可能にしています。

### CNAMEレコード

アドレスに変換するレコード、メールサーバ用のレコード様々ですが、では一度定義した名前をずっと使い続けないといけないのでしょうか。

実は定義した名前には別名を定義することができます。これを`CNAME（canonical name）レコード`と言います。
名前を一部省略しても名前解決を続けてくれるのはCNAMEのおかげということです。

```text
mobile.example.jp. IN CNAME www.example.jp.
```

CNAMEレコードと表現していますが、エイリアス(alias)と表現する場合もあります。

## Route 53 - 解説

※ようやくサービス解説に辿り着きました。

Route 53はAWS上におけるDNSサービスです。AWS公式では以下のように説明されています。

> 信頼性が高く、費用対効果に優れた方法でエンドユーザーをインターネットアプリケーションにルーティングする

> グローバルに分散されたドメインネームシステム (DNS) サーバーとオートスケーリングを使用して、エンドユーザーをサイトに確実にルーティングします。

> ドメイン名登録と簡単なビジュアルトラフィックフローツールを使用して、DNS ルーティングを数分で設定します。

> DNS ルーティングポリシーをカスタマイズして、レイテンシーを抑え、アプリケーションの可用性を向上させ、コンプライアンスを維持します。

[引用元](https://aws.amazon.com/jp/route53/)

なんかスゲェということだけはわかりそうです。
後ほど詳しく説明はしますが、AWSのサービスの中ではSLA100％を貫いていることもありますので確かに「スゲェ」という気持ちになります。

※あの強靭無敵最強のS3くんでさえ、イレブンナインであることから凄さがわかると思います。

### 実はここで使われている

各AWSサービスの名前解決で使われています。だからSLA100%なんです。
Route53が機能しなかったら随所で名前解決に失敗してサービスに繋がらなくなるかもしれないですね。

### 基本的な機能

いくつか機能がありますが、特定の機能にフォーカスしてみていきましょう。

#### Route 53 リゾルバー

簡単に言えば、AWS上の名前解決のことではありますが、Direct Connectなどで社内の環境とAWSを構築している場合は社内のシステムなどの名前を解決している場合もあります。

とりわけ、インターネットからアクセスできないゾーンをRoute53では`プライベートホストゾーン`と言います。
反対にインターネットからアクセスできるホストゾーンを`パブリックホストゾーン`言います。

※なお、Route53ではこれらゾーンのことをコンテナと表現している場合があります。

#### ルーティング

名前解決をするもの(リゾルバー)としての役割をRoute53は担っていますが、それ以外にも重要な役割があります。
それはリクエストに対してどういう返信を返すかという役割です。

Route53ではルーティングポリシーというものを定義してアクセス先を誘導(ルーティング)することができます。
実は概ね8種類のルーティングポリシーがあります。

|No.|ルーティングポリシー名|特徴|
|---|---|---|
|1|シンプル|1つのレコードに対し、1つのIPアドレスを返す|
|2|フェイルオーバー|メインまたはACTに障害が発生していた場合にサブまたはSBYにアクセスする|
|3|位置情報|ユーザーの位置情報に基づいてルーティング|
|4|地理的近接性|ユーザーとリソースの位置情報に基づいてルーティング|
|5|レイテンシー|ユーザーから最もレイテンシーが少ないリージョンにルーティング|
|6|複数値回答|複数のレコードの中からヘルスチェックでOKとなったレコードからランダムにルーティング|
|7|加重|予め指定した重量(比率)で複数のAWSリソースにトラフィックをルーティング|
|8|IPベース|アクセス元のIP アドレス範囲に応じてトラフィックをルーティング|

ぱっと見、位置情報を使うポリシーが2つあって混乱すると思います。

`位置情報ルーティングポリシー`はアクセスしてきたユーザーの位置情報に基づいてIPアドレスを返します。
利用用途としては例えば、アメリカからアクセスしてきたら英語でコンテンツをローカライズして返すなどの用途に利用されます。

`地理的近接性ルーティングポリシー`は一番近いリソースにルーティングします。ユーザーと物理的に近いリソースに誘導します。

ぶっちゃけ、かなり似ているというかうやろうと思えば、位置情報で地理的近接性を再現することも可能かとは思いますが、特定のユーザからアクセスしてもらいたいリソースがある時は地理的近接性を使うと良いでしょう。

### エイリアスレコード

DNSには様々なレコードがあると解説しましたが、エイリアスレコードについてはRoute 53 固有のレコードです。
エイリアスレコードはレコードから別のレコードに置き換えて動作します。
CNAMEレコードと似ていますが、厳密には違います。

#### Route 53 Resolver DNS Firewall

ここまででRoute53が名前解決をするすごいサービスだということがわかりました。
がしかし、それだけではありません。

昨今ではDNSを使った攻撃もあります。DNS以外の仕組みでブロックすることが今までは一般的でしたが、最近ではDNSにもセキュリティを実装することがあります。

Route53にはDNS単位でアクセスを制御する機能として`Route 53 Resolver DNS Firewall`というものがあります。アクセスしてきたIPアドレスを調べることはできませんが、名前レベルでブロックすることが可能です。
ブロックに関してはルールベースであり、ブロックする順番を優先度で優先度で決めることができます。

なお、設定はAWS Firewall Manager と統合して管理することができます。

### 他の機能

- Route 53 Application Recovery Controller
    - 最近(2022年)にZone Shiftという機能が発表されて話題になりました
- DNSSEC
- CloudFront Zone Apex のサポート

## まとめ

DNSの成り立ちからDNSの仕組みを理解しました。
AWSではRoute53で名前解決を実行しますが、Route53は単純なDNSサービスではありません。可用性に貢献する機能やセキュリティを担保する為の機能もあります。また、よく連携するサービスとしてはAmazon CloudFrontやELBもあります。

また、パブリックな名前解決だけでなくプライベートな名前解決にも利用されます。
昨今ではオンプレミスとクラウドの連携もあります。連携する際にはL3レベルで連携することもありますが、DNSレベルで連携をしないといけない場合もあります。そういう時はRoute53をうまく使いましょう。

## リソース

- [What is Amazon Route 53 Resolver?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html)
- [パブリックホストゾーンの使用](https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/AboutHZWorkingWith.html)
- [Linux豆知識 158](https://linuc.org/study/knowledge/488/)
- [エイリアスレコードと非エイリアスレコードの選択](https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)
- [Amazon Route 53 の特徴](https://aws.amazon.com/jp/route53/features/)
- [Amazon Route 53 Resolver DNS Firewallを分かりやすく解説してみる](https://blog.serverworks.co.jp/route-53-resolver-dns-firewall)

## おわり