【AWS Route53】

DNS, Route53の理解は障害対策、トラブルシューティング時に必要不可欠。
基本的なhostsファイルの動作も含めて「名前解決」は奥が深いトピックです。
CluldTechを通じて、基本から勉強しました!

AWS公式：Route53は、ロードバランサーの代替ではなく拡張機能である旨が明示されている。

• ELBのヘルスチェック
  • ロードバランサがどのバックエンドインスタンスにトラフィックをルーティングするかを判断
• Route 53のヘルスチェック
  • 重み付けラウンドロビンやDNSフェールオーバーで、どのIPアドレスを回答に含めるかを判断
  • IPアドレスかエンドポイントがあるもの、ELBやRDSにも分散が可能。

Amazon Route53（Hosted Zone）　＝ ネームサーバー

• AWSが提供するDNSサービス（フルマネージド型のDNSサービス）
  • Amazonが管理してくれる。
  • 単なるDNSサーバーとしての活用も可能
  • AWSから自動で割り当てられるドメイン名ではなく、独自ドメイン名で運用を行いたい場合に必要。
• Hosted Zoneでドメイン名のリソースレコードを管理
  • 作成したHosted Zoneごとに、NSレコードとSOAレコードを自動的に作成
    • NSレコード：ドメイン情報を管理するサーバを表したレコード
    • SOAレコード：ドメインの管理情報を表したレコード
  • 1つのHosted ZoneにネームサーバのFDQNを4つ割り当て。
    • 4つのトップレベルドメイン（*.com, *.org, *.net, *.co.uk）にまたがる。
    • 可能性に考慮して作成されているので、レコードを変更しないようにする。
• 特定のVPCからの問い合わせと、それ以外からの問い合わせを識別し、異なる応答を返す。
  • Public Hosted Zone
    • インターネットを含む特定のVPC以外向け
    • インターネット上に公開されたDNSドメインのレコードを管理する単位
  • Private Hosted Zone
    • 特定のVPC向け
    • VPCに閉じたプライベートネットワーク内のDNSドメインのレコードを管理するコンテナ
• エイリアスレコード
  • Amazon Route53 固有の機能
    • 一般的なDNSの仕組みを拡張したAWSオリジナルのレコード
    • ドメインとAWSリソースを関連付ける。
  • 最終的にユーザーが必要とするレコードデータのみを取得する。
    • 問い合わせ元にCNAMEを応答しない。
      • CNAME：ドメインとURLを関連付けるもの。（エイリアスレコードと非常に似ている）
      • CNAMEレコードは、ドメインを一旦、AWSリソースのドメインに置き換えて、そこからIPアドレスに変換する。
    • CNAMEを利用しないことで、Zone Apex(サブドメインを含まないドメイン名）でサービスをホスト可能とする。
      • エイリアスレコードは、ドメインからIPアドレスに変換できる。
      • CNAMEレコードと比較して、変換の回数が異なり、応答速度に違いが出る。

Route53によるトラフィックルーティング

• DNSの応答をカスタマイズすることで、クライアントからのトラフィックをより適したリソースにルーティング
  • レコードの作成時に、Route53がクエリに応答する方法を決定するルーティングポリシーを選択。

トラフィックルーティングの種類

• シンプル（いわゆるDNSラウンドロビン）
  • 従来のDNSと同様に、静的なマッピングによりルーティングが決定される。
  • 複数の値を1つのレコードに指定すると、すべての値をランダムな順序で応答。
• 加重
  • 指定した比率で複数のリソースにトラフィックをルーティング
  • より重み付けの高いリソースにより多くルーティング
    • 例）段階的な移行（Blue/Greenデプロイ）、サーバーの負荷平準化
• フェイルオーバー
  • ヘルスチェックの結果に基づいて利用可能なリソースのみを応答
  • アクティブ/アクティブおよびアクティブ/パッシブ構成を実現
  • フェイルオーバー条件は、複数のヘルスチェック結果を結合するなどのカスタマイズ可能
    • 例）複数リージョンにまたがるシステムで冗長構成
    • 例）S3静的ウエブサイトホスティングのSorry Pageを表示
      • クライアントに対して、「サイトメンテナンス中」等のページを表示する。
      • プライマリ > セカンダリ という通信の優先順位付けの設定ができる。
        • プライマリで異常が発生した時は、セカンダリに通信をフェイルオーバー
      • Route53がドメインに対してヘルスチェックをしてくれる。
      • S3の静的Webサイトホスティング機能を利用し、障害時に表示するHTMLファイルを用意

　　※ フェイルオーバールーティングは、デモをおこないました。（Sorry Pageを表示）
　　　→　自分で手を動かしてみることで理解度が増します。
　（昔はDNSの動きを手を動かして学習するのはオンプレや個人環境では困難なものだったが、クラウドは可能）

• 複数値回答
  • 最大8つのランダムに選択された正常なレコードでDNSクエリに応答
  • 各リソースが正常かどうかも確認し、正常なリソースの値のみを応答
  • 応答をキャッシュされた後にリソースが使用できなくなった場合にも、クライアントは応答内の別のIPアドレスを利用できる。
• レイテンシー
  • 複数のAWSリージョンでアプリケーションがホストされている場合
    • ネットワークレイテンシーが最も低いAWSリージョンのリソースを応答
  • 一定期間中に実行されたレイテンシーの測定値に基づいている。
  • 時間の経過と共にルーティンされるAWSリージョンが変化する場合がある。
• 位置情報
  • クライアントの位置情報に基づいて、DNSクエリに応答
  • 特定の地域や国からのDNSクエリに対して、特定のアドレスを応答
    • クライアントの地域により適切な言語でコンテンツを提供
    • ライセンス許可をした市場のみに制限
• 物理的近接性
  • ユーザーとリソースの地理的場所に基づいてDNSクエリに応答
  • トラフィックフロー（ポリシーベース：簡単に作成や管理できる機能）を使用する必要がある。
    • ビジュアルエディタ
    • トラフィックポリシーバージョン
    • ポリシーレコード

大抵はシンプルと加重とフェイルオーバーで十分ですので、ほかのルーティングが必要となるケースで実務を担当する際は貴重な経験だと思います。位置情報などはかなり大規模な構成ですよね！

くろかわさんにコメント頂きました。
実務でいろんな技術をこれから経験していきたいですね。

Amazon Route53 Resolver

• VPCに標準で備わるDNSサーバー（フォワーダーとフルサービスリゾルバー）
  • VPC作成時にデフォルトで有効
  • VPC毎に有効/無効に設定可能
  • IPアドレス設定はDHCPで自動的に配布される。
• インターネットに公開されたZoneと内部に閉じたDNS Zoneを解決する。
• VPC外からのDNSクエリは受け付けない。
  • VPC内のインスタンスから発生するDNSクエリには無料

Amazon Route53 Resolverの具体的な使用用途

※ くろかわさんに補足して頂きました。

オンプレ（ネット接続無しの閉じた環境）とAWSとを専用線接続する際、オンプレはAWS側のリソースを名前解決できません。
オンプレからAWSリソースのIPアドレスに対して通信できますが、名前解決できないのでAutoScalingなどでIPアドレスが変わると通信できなくなります。
そこで、Route53 Resolverを使用すると、内部に閉じたDNS Zoneを解決できる（ネットが繋がっていないオンプレでもAWS側の名前解決ができる）という使い方があります。なお、この仕組みで月に3万円くらいかかります。

なるほど！となりました。ありがとうございます！

テストとトラブルシューティング

• テスト
  • 実際にエンドポイントに対して、問い合わせを試行する。
    • Linux：dig

digコマンド

$ dig @172.31.0.2 www.example.com. A +rec +all

- 参照したいFQDN（必須）：（www.example.com）
- 以下、省略可能。省略すると以下の内容に保補完される。
 - 参照先：スタブリゾルバの参照先（/etc/resol.confのネームサーバ）
 - クエリタイプ：A
 - オプション：+rec（再起問い合わせ） +all（表示指定を全て有効）

• トラブルシューティング
  • 原因がどこか特定する。
    • 再帰的問い合わせと反復問い合わせを明確に区別して、試行する。
    • 出力情報やオプションが豊富なdigコマンドが有用。
    • ヘッダのstatus, flagsに着目しよう。

DNS（Domain Name System）のおさらい

• DNSは、FQDNをキーに対応するIPアドレスなどの情報を取得する仕組み
  • DNSから情報取得することを「名前解決」
  • 各ネームサーバが管理する名前空間を「ゾーン」
• ホスト名とFQDN（完全修飾ドメイン名）
  • ホスト名
    • サーバや端末に付けられた名前
    • ノードが一意に識別されることを前提にしていない相対的な名前
  • FQDN（完全修飾ドメイン名）
    • サブドメインからトップレベルドメインまで完全に指定されたホスト名
    • ホスト名に「どこの」という修飾語を付ける。
      • 「どこの」を設定したものを「レコード」
        • レコードを構成する要素：NAME, TTL, CLASS, TYPE, RDATA
      • 1つ1つの設定のことを、「レコードセット」または「リソースレコード」
      • それらの設定の集合体を「ホストゾーン」
    • 特定のドメイン名空間において、ノードを一意に識別が可能な名前

DNSサーバーとは

• DNSサーバーは、以下、4つの異なる機能を持つ実装
  • ネームサーバー
    • ルートを起点に全てのFQDNを探索できるように構成された分散DB
      • それを成すひとつひとつのサーバー
    • 権威DNSサーバ（Authoritative Serverと表現される場合も）
      • 世界中のユーザーから利用されるが負荷が大きくなる。これを対策するため。
        • 権限委譲元：親ゾーン　　権限委譲先：子ゾーン
      • 親ゾーンから子ゾーンのネームサーバーをFQDNで指し示し、権限委譲
      • 子ゾーンのネームサーバーのFQDNが、子ゾーンで管理されている場合、親ゾーンの返答にそのIPアドレスを含めて指し示す。（Glueレコード）
  • フルサービスリゾルバー
    • ルートから順にネームサーバに問い合わせ、得られた回答を問い合わせ元に返す。
    • 効率化のため、所定の期間（TTL）キャッシュを保持
    • 反復問い合わせを受け取った場合、自らが保有している情報を回答する。
      • ネームサーバへの反復問い合わせは行わない。
  • スタブリゾルバー
    • 一般に、OSに組み込まれたDNSクライアント
    • ルートからネームサーバを辿る反復問い合わせの機能を持たない。
      • 常に再帰的問い合わせを行う。
    • キャッシュの有無は実装に依存する。
    • スタブリゾルバーの制約
      • 複数のDNSサーバーに対し、ドメイン毎に振り分けたり、同時に利用したりする機能は有していない。
        • 複数サーバーを指定するのは、障害時のフォールバックのため。
        • 名前解決に失敗した場合、順に問い合わせため。
        • 耐障害性を高めるため。
  • フォワーダー
    • 受け取った問い合わせを、ルールに基づいて中継する。
    • ルートからネームサーバを辿る反復問い合わせの機能を持たない。
      • 常に再帰的問い合わせを行う
    • 効率化のため、所定の期間（TTL）キャッシュを保持
    • フォワーダーの制約
      • インターネット向けネームサーバーと内部ネットワーク向けネームサーバーで同じドメイン名を利用している場合に両方を参照することができない。
      • ドメインやホスト名を分ける、必要なレコードを同期させるなどの必要がある。

再帰的問い合わせと反復問い合わせ

• 反復問い合わせは、自らがネームサーバを辿る時に行う問い合わせ
• 再帰的問い合わせは、問い合わせ先に反復問い合わせを依頼する問い合わせ

企業ネットワークのよくあるDNSサーバー構成

• フォワーダー、フルサービスリゾルバー、ネームサーバーが同居して、1つのDNSサーバを構成

参考

• CloudTech
• 【AWS Black Belt Online Seminar】Amazon Route 53 Resolver
• 【AWS Black Belt Online Seminar】Amazon Route 53 Hosted Zone

おわりに。

この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
https://aws-cloud-tech.com