[レポート]Deep dive ハイブリッドクラウドでのDNS #NET410 #reinvent

本記事はAWS re:Invent 2019のセッション「Deep dive on DNS in the hybrid cloud」のレポートです。

概要

日本語訳

Amazon Route 53 リゾルバーエンドポイントと転送ルールの開始により、特にハイブリッドクラウド環境でDNS解決を管理するためのさまざまなエキサイティングな新しいオプションが開かれました。このセッションでは、Route 53 リゾルバーの設計を深く掘り下げる前に、製品の概要を簡単に説明します。これには、Route 53プライベートDNSを補完する方法や、可用性とパフォーマンスを達成するためのベストプラクティスが含まれます。また、AWS Transit Gateway、AWS PrivateLink、Microsoft Active Directory用AWS Directory Serviceなどのサービスで新たに出現しているいくつかの新しいパターンにも飛び込みます。

原文

The launch of Amazon Route 53 Resolver endpoints and forwarding rules has opened up a variety of exciting new options for managing DNS resolution, especially in hybrid cloud environments. This session gives a quick overview of the product before taking a deep dive into the design of Route 53 Resolver, including how it complements Route 53 private DNS and best practices to achieve availability and performance. We also dive into some new patterns that are emerging with services such as AWS Transit Gateway, AWS PrivateLink, and AWS Directory Service for Microsoft Active Directory.

スピーカー

• Gavin McCullagh - Principal System Development Engineer, Amazon Web Services

レポート

アジェンダ

• VPC Route 53リゾルバー
• ハイブリッドクラウド
• Route 53 リゾルバー インバウンド エンドポイント
• Route 53 リゾルバー インバウンド エンドポイント & ルール
• Route 53 リゾルバー & Active Directory
• Managing DNS across many VPCs

レポート

VPCのRoute 53リゾルバー

Route 53 リゾルバーとは

• VPC内外に多くのリゾルバーが存在しているが名前がなかった
  • EC2 DNSリゾルバーには正式名が必要
• Route 53 リゾルバーは以下としても知られている
  • AmazonProvidedDNS
  • VPC リゾルバー
  • +2 リゾルバー
  • .2 リゾルバー
  • EC2 DNS Resolbver
• 2018年第4四半期の機能追加で正式名称が必要
  • リゾルバー エンドポイント
  • リゾルバー fowarding rules

VPCのDNS解決（DNS Resolution）を有効にしている場合、AmazonProvidedDNSが利用され、アドレスはVPCのCIDRに2を追加したもの。 それはS3ゲートウェイエンドポイントのようなものだが、リクエスト元インスタンスと共に、サブネット内に存在している。 VPC内からの名前解決のリクエストはマルチテナントの共有リゾルバサービス(Route 53 リゾルバー)に移動する。

Route 53 リゾルバーは、最初のクエリをチェックし、Route 53 Private DNSに送信される。

Route 53 Private DNS：どのように機能するか？

• Route 53 リゾルバーは、Route 53 Private DNSのプライベートホストゾーン（PHZ）にアソシエーションする
• ネームがPHZに存在する場合、クエリをRoute 53プライベートDNSに送信
• Private DNSはVPC DNSレコードよりも優先度が高い
• "."というゾーンを作成すると、すべてのパブリックおよびVPC DNSがオーバーライドされる

プライベートDNS - 重複ゾーンのサポート

• 2019年11月にリリース
• プライベートDNSが重複するプライベートゾーンをサポート
• 1つのVPC(PHZ)でmycompany.comおよびservice.mycompany.comが可能

VPC DNS

• 定義済みの特別な名前空間
• 例
  • eu-west-2.compute.intenal
  • 10.in-addr.arpa...
• サーバはロンドンにあるインスタンス

Route 53 リゾルバー(VPC+2)

• シンプルな機能（意図して）
• スケーラブル
• フォールトトレラント
  • 各AZで独立して動作
• パフォーマンス
  • キャッシュによる待ち時間が改善
• リクエスト料金なし

ハイブリッドクラウド

VPCとオンプレをDX接続してる構成があったとして、オンプレ上からは、リゾルバー(VPC+2)に接続できない（=Route 53 リゾルバーに接続不可）ので、DNSフォワーダー（インスタンス）を構築し リゾルバー(VPC+2)を通し、Route 53 リゾルバーに照会。

DNSフォワーダー（インスタンス）：良い

• VPCとオンプレミスDNSを統合
• コスト
  • VPC間で再利用可能
• パフォーマンス
  • キャッシュによる待ち時間が改善
• フレキシブル
  • ロギング、RPZ、AXFR

DNSフォワーダー（インスタンス）：チャレンジ

• 自前で構築
  • それなりの難易度
• 制限
  • ENI Limitはボトルネックになる可能性がある
• 失敗
  • インスタンス障害がVPC全体に影響する
• 分離
  • AZ障害はVPC全体に影響を与える可能性ある

Route 53 リゾルバー エンドポイント

Route 53 リゾルバー インバウンドエンドポイント

• オンプレミスのリゾルバーにRoute 53 リゾルバーへのクエリを許可する
• AWS Direct ConnectまたはVPNを介して到達可能なVPCでルーティング可能なENIを作成する
• 1つのエンドポイント = 複数のENI
• 制限：10,000 QPS pre ENI

インバウンドエンドポイント：ベストプラクティス

• 高可用性のためにマルチAZで複数のENIを使用
• オンプレミスのDNSリゾルバーで再試行を使用
• IPを指定
• QPSのCloudWatchアラーム
• EC2インスタンスは、インバウンドエンドポイントではなくVPC + 2リゾルバーを使用

インバウンドエンドポイント：複数のVPC

複数のVPCに複数のエンドポイントが必要か？

• いいえ(一般的に)
  • すべてのプライベートホストゾーンを1つのVPCに関連付ける
  • 内部インスタンス名はすべてのVPCで解決する
  • パブリックEC2の内部IPは、ピアリング/ TGWで解決

Route 53 リゾルバー インバウンド エンドポイント ルール

Route 53 リゾルバー アウトバウンドエンドポイント

• DNSリゾルバーを照会するRoute 53リゾルバーのパス
• VPCにソースENIを作成
• 多くのVPCで使用可能
• 1つのエンドポイント = 複数のENI
• 制限：10,000 QPS pre ENI

Route 53 リゾルバー ： リゾルバールール

• Route 53 リゾルバーがクエリを作成する方法を構成する
• 2つのタイプ： FORWARD and SYSTEM

アウトバウンドエンドポイント：複数のVPC

• 複数のVPCに複数のアウトバウンドエンドポイントが必要か？
  • いいえ。ルールを多くのVPCで共有および関連付ける。
• VPC/アカウント間でアウトバウンドエンドポイントを共有する必要があるか？
  • いいえ。ルールを関連付けるとエンドポイントは暗黙的に共有される。
• VPCが異なるAWSアカウントにある場合はどうなるか？
  • Resource Access Managerは、リゾルバールールのクロスアカウントを共有。
• VPCピアリングまたはTrangsit Gatewayは必要か？
  • いいえ

アウトバウンドエンドポイント：ベストプラクティス

• 高可用性のためにマルチAZで複数のENIを使用
• 控えめに使用する
• ターゲットとして固定IPを維持する
• QPSのCloudWatchアラーム

リゾルバールール:どのように機能するか？

• 重複するルールを作成するとどうなるか？
  • 最も具体的な一致ルールが勝つ
  • FORWARDが同じドメインのSYSTEMに勝つ

自動定義されたSYSTEMルール

• "." にFORWARDルールを作成するとします
• これはすべてのVPC DNSおよびPrivare DNSをオーバーライドしますか？
• Route 53リゾルバーは、より具体的な「自動検出システムルール」を作成します
• VPC DNS
  • eu-west-2.compute.internal
  • eu-west-2.compute.amazonaws.com
  • 10.in-addr.arpa, 168.192.in-addr.arpa,[16-31].172.in-addr.arpa
  • VPC CIDR/24のルール
• プラーベートDNS
  • VPCに関連付けられたすべてのプライベートホストゾーン

リゾルバールールまとめ

• 最も具体的なルールが勝つ
• プライベートDNS、プライベートリンクエンドポイント、およびVPC DNSは自動定義されたルールを取得
  • それらはオーバーライド可能
• SYSTEMがamazonaws.comを解決できるようにすることがベストプラクティス
• 逆引くレコードを忘れないように（例:keberos)
• VPC CiDR範囲は/24ルールを自動定義
  • それらはオーバーライド可能

Route 53 リゾルバー & Active Directory

EC2のActive Directory

• AWS Managed Microsoft AD、Simple AD、および自前でインストール
• Active Directoryマネージャー、Actice Directoryドメイン上のホストのダイナミックDNS
  • フォワードおよびリバースDNSは重要
• 一般的にはDNSのドメコンを指すようにDHCPを更新する
• ドメコンは、Active Directoryドメインと逆引きレコードに回答
• ドメコンは通常、他のすべての場合はRoute 53 Resolver（+2）に転送します
• DNSフォワーダー（インスタンス）と同様に、このソリューションは多くのユーザに適する
  • 問題点／Windowsインスタンスはすべて、DHCPの最初のネームサーバーを照会する傾向がある
  • 問題点／スケーリング：VPC+2の1024 ppsの制限が適用される

Route 53リゾルバーとActive Directory

手順

• Route 53 Resolverアウトバウンドエンドポイントを作成
• リゾルバールールを作成
  • Active DirectoryドメインをAWS Managed Microsoft AD DNSアドレスに転送
  • VPCサブネットをAWS Managed Microsoft AD DNSアドレスに転送し、各自動検出ルールをオーバーライド
• DHCPネームサーバーをAmazonProvidedDNSに戻す

必須条件

• Active Directoryドメイン：mydomain.com
• VPC CIDR：10.10.0.0/23

Active Directoryの信頼関係

• オンプレミスドメインとのActive Directory信頼関係がある場合はどうなるか？
• 通常、信頼できるデータセンターに直接転送するルールを好む

複数のVPCにわたるDNS管理

多くの場合、大規模な顧客は以下のようなことをしており、DNSを一元管理するのは難しい場合がある

• ネットワークとDNSを管理するインフラチーム
• 多くの開発チーム、複数AWSアカウントとVPC
• VPCピアリングまたはTranit Gateway相互接続
• ハブとスポークのネットワークアーキテクチャ
• 一貫性のあるDNSビューの共有

ハブとスポーク戦略

コミュニティには4つの戦略が登場

• ハブDNSの管理:DHCP ネームサーバのスポーク変更
• ハブDNSの管理:エンドポイントを介してハブにスポーククエリを転送
• VPC共有
• プライベートホストゾーンとリゾルバルールの共有と関連付け

1.ハブDNSの管理：DHCPの変更

• 長所
  • 使い慣れたモデル（転送インスタンスなど）
• 短所
  • 単一のインバウンドENIでホットスポットを期待する
  • フォールトトレラントではない
  • ローカルインスタンスキャッシュなし
  • 10Kクエリ/秒ENI制限を介したすべてのクエリ
  • クエリごとに最大4倍のAZ間ホップ
  • スポークとハブ間のL3接続が必要
  • より高いクエリコスト

2.エンドポイント経由で転送

• プライベートゾーンをハブVPCに関連付ける
• ハブVPCのアウトバウンドおよびインバウンドエンドポイント
• ルールは、アウトバウンドエンドポイントからインバウンドエンドポイントを介してプライベートホストゾーンのリゾルバーに転送します
• オンプレミスに転送される追加のルール
• ルールを共有し、スポークVPCに関連付けます
• 長所
  • 簡単なセットアップ/メンテナンス
  • VPC+2リゾルバー、キャッシュを使用
  • 転送されないクエリはスケーラブルパスを使用します
• 短所
  • 拡張性が低い（1万クエリ/秒の制限：VPC+2の場合は1024 pps）
  • 各クエリはアベイラビリティーゾーン間を最大4回横断します
  • 耐障害性ほどではない
  • クエリ費用

3.VPC共有

• 長所
  • 何百ものVPCは必要ありません
  • 1つのVPC、DNSの一貫したビューの保証
  • ネットワークの簡素化
• 短所
  • 今日の機能のギャップ
  • 開発チームの自律性/分離性の低下

4.共有して関連付ける

VPC間でPrivateLinkエンドポイントを処理するにはどうすればいいか？

• エイリアスを使用して共有可能なプライベートホストゾーンを作成する
  • ssm.eu-west-2.amazonaws.comというプライベートゾーン
  • ssm.eu-west-2.amazonaws.com A（ALIAS）vpce-xx..vpce.amazonaws.com。
• 長所
  • 最も回復力と拡張性
  • VPC + 2エンドポイント、ローカルキャッシュ、AZ分離を使用
  • 最小転送ホップ
  • 低コスト
• 短所
  • PHZ共有は面倒で、CLI / APIのみです
  • プライベートホストゾーンごとのVPCアソシエーションの制限

Route 53リゾルバーベストプラクティス

• 高可用性
  • 複数のアベイラビリティーゾーンでリゾルバーENIを常に使用する
• 転送を控えめに使用する
  • EC2インスタンスにAmazonProvidedDNSを使用する
  • プライベートホストゾーン/ルールをすべてのVPCに関連付けることを好む
  • 可能な場合、クエリをローカルのアベイラビリティーゾーン内に保持する
• モニタリング
  • リゾルバーエンドポイントのQPS制限に近づいていないかCloudWatchアラームを設定する

さいごに

これぞDeep diveというセッションでAWSのDNSがよくわかりました。既に動画も公開されていますので、是非みていただければと思います。

• AWS re:Invent 2019: Deep dive on DNS in the hybrid cloud