Amazon Route 53
# Amazon Route 53
https://d1.awsstatic.com/webinars/jp/pdf/services/20160113_aws-blackbelt-route53-public.pdf
https://d1.awsstatic.com/webinars/jp/pdf/services/20191016_AWS_Blackbelt_Route53_Resolver.pdf
https://d1.awsstatic.com/webinars/jp/pdf/services/20191105_AWS_Blackbelt_Route53_Hosted_Zone_A.pdf
## 概要
- 設計原則
## DNSサーバーとは
以下の4つの異なる機能を持つ実装
- Name Server
- ルートを起点に全てのFQDNを探索できるように構成された分散データベース、およびそれをなす１つ１つのノード
- 権威DNSサーバ
- ルートは下位のName Server に対して権限を委譲(Delegation)していく
- Full Service Resolver
- ルートから順にネームサーバに問い合わせ、得られた回答を問い合わせ元に返す機能を有するサーバー実装
- TTLキャッシュを保持する
- TTLは残せる限界時間を指定
- 再帰的問い合わせ（他のネームサーバ群に反復問い合わせを行い回答）と反復問い合わせ（リゾルバーが持つ情報を回答）
- 存在しないRR（リソースレコード）Setを問い合わせた場合は不存在応答をする（NXDOMAIN）
- Stub Resolver
- OSに組み込まれたDNSクライアント実装
- 常に再帰的問い合わせを行う
- キャッシュについては実装依存
- 複数のDNSサーバに対してドメインごとに問い合わせるDNSサーバーを変更したり、同時に利用したりはできない。プライマリーのDNSに障害が起こったらSecondary に問い合わせを行うといった方法で問い合わせを行う。
- Forwarder
- Internet(インターネットに公開されたDNSドメインのゾーン)
- Amazon VPC（VPCに閉じたプライベートネットワーク内のDNSドメインのゾーン）
- On-premise（オンプレミス環境に閉じたプライベートネットワーク内のDNSドメインのゾーン）
- User-managed DNS Private Hosted Zone
- Route53で作成したHosted ZoneごとにNSレコードとSOAレコードを自動的に作成する
- 1つのHosted ZoneにネームサーバーのFQDNを4つ割り当て
- 4つのトップレベルドメイン(*.com, *.org, *.net, *.co.uk)にまたがる
## Route 53 の機能
- ホストゾーンでドメインのリソースレコードを管理
- ホストゾーンとは
- 種類
- サポートされるリソースレコードタイプ
- SOA(start of authority record)
- ゾーンに対してどのサーバーがそのゾーンを管理しているのかの情報が指定されている
- DNS構成用
- NS(name server record)
- A(Address record)
- IPv4のIPとホスト名の関連付け
- AAAA(IPv6 address record)
- IPv6のIPとホスト名の関連付け
- CNAME(canonical name record)
- 正規のホスト名とその別名を関連付け。CNAMEのレコードからAレコードが導かれるイメージ
- PTR(pointer record)
- MX(mail exchange record)
- メールで利用。宛先ドメインのメールサーバのホスト名を定義できる。
- SRV(service locator)
- 負荷分散サービスの提供・冗長性の確保・サービスポート番号の通知を可能にするレコード
- SPF(sender policy framework)
- TXT record の一種。
- 対象ドメインからのメール送信を許可されているのはどのサーバーなのかを受信サーバに伝える役目
- TXT(text record)
- ホスト名に関連づけるテキスト情報を定義するレコード
- ALIASレコード
- Route 53 固有の仮想リソースレコード
- DNSクエリに対してAWSsa-bisu のエンドポイントIPアドレスを直接返す。これによりCNAMEを利用することに比べてレスポンスが高速になる
- S3
- CloudFront ディストリビューション
- ELB
- ホストゾーン内のリソースレコードセット
- 管理しているDNSドメインの頂点（Apex)を示すZone Apex を利用可能
- トラフィックルーティング
- ルーティングポリシー
- シンプルルーティング
- 加重ルーティング（加重ラウンドロビン）
- レイテンシールーティング
- ANSリージョンとの遅延によってDNSクエリに応答する
- リージョン間の遅延が少ない方のリソースへルーティングする
- ユースケース
- グローバルに展開しており、エンドユーザーのレイテンシーを低減したいケース
- 動的なサイトでレスポンスを早くしたい場合
- フェイルオーバールーティング
- ヘルスチェックに基づき、利用可能なリソースにのみルーティングされる
- アクティブ・パッシブフェイルオーバー（アクティブだと常に複数のAZにルーティングされる。パッシブだと、通常はアクティブなプライマリAZにルーティングされるが、フェイルオーバー時にはパッシブ側をアクティブにして、そちらにルーティングする。パッシブ方式だとダウンタイムが発生する）
- ユースケース
- 複数リージョンにまたがるシステムで冗長構成
- 災害発生時にリージョン間でフェイルオーバー
- サイト障害時に、S3静的ウェブサイトでSorry Page を表示
- 位置情報ルーティング
- 複数回答
- 最大８つのランダムに選択された正常なレコードでDNSクエリに応答
- 応答をキャッシュされた後にリソースが使用できなくなった場合にも、クライアントは応答ないの別のIPアドレスを利用できる
- 物理的近接性
- DNSフェイルオーバー
- ヘルスチェック
- アプリケーションのエンドポイントが機能しているかを確認する（10-30秒-> 世界中に15個以上あるので30秒だったら2秒に一回どこかしらからヘルスチェックが行われる）。
- 世界中の複数のエンドポイントから対象に向かってインターネット経由のリクエストを送る
- 三回連続でヘルスチェックが失敗するとunhealthyに変更。逆も同じ。
- CloudWatch アラームとの連携
- TCP/HTTP/HTTPSでのヘルスチェック
- ヘルスチェッカーが到達できるようにセキュリティグループの設定に注意する必要がある
- フェイルオーバー
- ヘルスチェックでOKが出たリソースだけをクエリに返答
- 対象が停止していた場合はダウンしたエンドポイントからリダイレクト
- 全てのエンドポイントがunhealthyになると逆に全てをhealthy とみなすようになる
- 大規模なリージョンダウンがあった場合、各ロケーションのDNSサーバはことなるステータスを持つ可能性がある
- トラフィックフロー
## Route 53 の種類
- Amazon Route 53
- Amazon Route 53 Resolver
- Amazon Route 53 Resolver for Hybrid Clouds
- ハイブリッド環境での名前解決を一元化するROute 53 resolver の拡張機能。
- ユースケース
- オンプレミスからVPC向けゾーンの名前解決
- オンプレミスからインターネット向けゾーンの名前解決
- VPCからオンプレミス向けゾーンへの名前解決
- オンプレミスとインターネットで同じドメイン名を利用している場合に、双方のゾーンを併用した名前解決
- コンポーネント（ENIを持つのでセキュリティグループの設定が必要）
- Outbound Endpoint
- Inbound Endpoint
- 仕組み
- コンポーネントを利用して社内のフォワーダー+ネームサーバと接続。相互に問い合わせを行いVPC -> 社内、社内-> VPCの名前解決を可能にする
- 転送ルールタイプを指定することで、どのDNSクエリをRoute53 で解決するのか、または他のリゾルバに転送するのかを指定できる
- 料金
- エンドポイントの使用にはENIが必要でその分の料金がかかる
- 転送ルールも従量課金
## ユースケース
- 単純フェイルオーバ（片側はSorry Page)
- マルチリージョンフェイルオーバー
- Failover + Latency + Health Check
- 先頭から順に評価していき宛先を決定
- Failover + geolocation + Latency + health check
## 設計
## ドメイン名のトラブル
- ドメイン名ハイジャック
https://xtech.nikkei.com/atcl/nxt/column/18/00598/021900009/
- スラミング
- ドロップキャッチング
https://xtech.nikkei.com/atcl/nxt/column/18/00598/021900009/
- 対策
## 運用管理
- IAMによるRoute53へのアクセス制限
- IAMによりドメイン、ホストゾーン、リソースレコードの作成を制限
- CloudTrail 対応
- タグ付けによる管理
## 雑感
そもそもDNSというシステム自体が成功した分散データベースともいわれているので障害に強いということもあり、SLA100%が達成できているのだと感じた。スゴイ。
マネージドで世界中にサービスを用意できるので加重ルーティングや地域別ルーティング、レイテンシベースルーティングなどを多段にするといった柔軟な構築が可能になっている。
DNS単体もやることが単機能でわかりやすいし、それをつないでいくことができるイメージなのでシステムの構築はイメージしやすそう。（そのあとのインフラ設計やアプリ設計もあるけれども）。
ルーティング方法によって料金が微妙に異なってくる。料金の目安については https://www.lancork.net/2014/05/amazon-route53-monthly-cost/ によると数万PV程度だったら100円もかからないみたい。なのでそこまでシビアに考えなくてもいいかも。
新版も読んでみて追記
トラフィックフローを構築することでより柔軟にDNSクエリに応答できるようになっている。地理ベースルーティング（近接やレイテンシー）はグローバルなサービスを構築しているワークロードで利用されるだろう。Slack とかだと、Route53 の地理ルーティングとCloudFront 等を組み合わせてレイテンシを低くする工夫とかをしていそう。
身近なところだと情シスが社内システムを構築する際にBindを運用するのではなくRoute53を運用するとかはありそう。その際にはマイグレーションが必要だったりするが、手順（https://jprs.jp/related-info/guide/019.pdf）があるみたい。１つづつずらして行ってTTLを短くすることで変えていくって流れかな。
トラシューには頭の中に構成図がないと難しそう。
