最近自身のblog側にしか書いてなかったのですが、
Qiitaにでも久々に書いてみようと思います。
記事を書いていたタイミングで、AWS Advent Calendar 2018の22日目に空きがあったので参加しました。
#Route53 Resolverについて
記憶ではre:Invent 2018開催前にリリースされたかとは思っていますが、Route53 Resolverについてメモ書きを残します。
多分リリースされてから日も経っておるので他に詳しい記事があるかと思いますが書いて行きたいと思います。
##Route53 Resolverとは
Route53の権威サーバ機能は既にご存知の方も多いと思いますが、Resolverとある通りでAWSとVPN/DX(Direct Connect)環境を構築している場合等で利用できるResolver/フォワーダをAWSのマネージドサービスで提供といった具合のものです。
ですので自身でBIND等でグローバルIPつけて立ててフルサービスリゾルバとして使うような用途では利用できないようです。あくまでもPrivate Address空間での相互利用といったところ。
##Route53 Resolverの使いどころ
AWSのインスタンスなどから見た場合のフルサービスリゾルバについては、
特にオプション指定を外さない限り、VPCを作成したタイミングでできるAmazon Provided DNSを使う動きになっていますが、いわゆる外部からの接続DX(Direct Connect)やVPN接続を行なっている場合に重宝します。
Amazon Provided DNSはVPC外からの参照が直接できないため、
今まではAWS上のPrivate Zoneを解決するにはBINDやUnbound等を用いてDNS forwarderを
作成する必要があったかと思いますが、これを作成しなくて済むのが大きなポイントです。
脆弱性対応や冗長の取り方を悩まなくて良いのもポイント。
Amazon Provided DNS
10.1.0.0/16で立てた場合に10.1.0.2とかで作成されるもの
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_DHCP_Options.html#AmazonDNS
以下はマネジメントコンソール上のRoute53 Resolverの説明の図
図では自身のオンプレ等の設備とVPCの間にDNS Endpointが設置され、
自設備からAWSへのInbound Traffic(図中の赤アンダーライン)、
AWSから自設備へのOutbound Traffic(図中の青アンダーライン)についての図が書かれており、
2つ以上のEndpointが作成される事がわかる(図中の緑色枠)
また、Outbound trafficでForwarder ruleを書けるのもポイントです(図中の黄色枠)。
##料金体型
AWSの料金ページから引用
Route 53 リゾルバーエンドポイント
Route 53 リゾルバーのエンドポイントには、1 つ以上の IP アドレスが含まれています。各 IP アドレスは、1 つの Elastic Network Interface (ENI) に対応します。同じリージョン内の複数のアカウントにまたがる複数の VPC を単一エンドポイントで共有することができます。
ENI あたり 0.125 USD/時
オンプレミスネットワークとの間の再帰的な DNS クエリオンプレミスリソースとの間で、Route 53 リゾルバエンドポイントを通過するクエリの料金のみ請求されます。Virtual Private Cloud (VPC) にローカルで解決されたクエリについては請求されません。
100 万件のクエリごとに 0.400 USD – 最初の 10 億件のクエリ/月
100 万件のクエリごとに 0.200 USD – 10 億件を超えた分のクエリ/月
##Route53 Resolverのコンソール画面をみてみよう
既に東京リージョンでも利用が可能です。
*AWSは頻繁に更新されるためキャプチャ画面は変更されている事があります。
###サービスの検索でRoute53を探す
###Route53のコンソール画面上で確認
左ペイン下側のResolverと言う項目が増えています
###各項目を見る(VPC)
左ペインがいきなり日本語表示になったのはさておき
VPCを選択すると今作成されているVPCとそのVPCに作成されているエンドポイントの
情報を確認する事ができます。
また表示されているVPC-idをクリックするとEndpointのIPアドレス等の確認ができます。
###各項目を見る(インバウンドエンドポイント)
こちらは既に作成されている場合は作成されている一覧が表示されています。
また新規でインバウンドエンドポイントを作成する場合もこちらの画面から行います。
###各項目を見る(アウトバウンドエンドポイント)
こちらもインバウンドエンドポイントの画面と同様です。
ルールは適用されているForwarding ruleの数を表しています。
###各項目を見る(ルール)
ここは初期の状態でも一つルールが存在しています。
ドメインを見ると.なのでFowarding ruleが存在しない場合はこちらが適用となりインターネット向けにQueryが抜けるようになっているようです。
##Route53 ResolverでInbound Endpointを作成してみる
インバウンドエンドポイントの作成をやってみたいと思います。
###インバウンドエンドポイントの作成を選択
###各項目に必要パラメータを入力
理解が間違っていなければVPNやDXで自設備を繋いでいる場合はリーチャビリティが取れているVPCを選択する事になると思います。
また、セキュリティグループについてはこの画面で作成ができないため、
別タブで作成画面を開くか事前に作成しておく必要があります。
セキュリティグループについては作成するVPCに紐づけて53番のTCPとUDPを開ける事になると思います。
ソースはご自身のセキュリティポリシーに合わせてください。
###最後にAvailability zoneとサブネットを選択
DNSとして53番をListenさせるIPを自分で指定したい場合は自分で指定したIPアドレスを使用します。にラジヲボタンを付け直し前段で選んだサブネットのレンジから切り出します。
なお、画像みてわかる通り、IPアドレス#1とIPアドレス#2の2つを最低作成する必要があります。
ちなみに、Availability zoneについてはIPアドレス#1、IPアドレス#2共に同Availability zone内で作成も可能でした。
必要に応じてIPアドレス#3も作成ができます。
###最後にtagがありますのでお好みで値を入力
全て入力が完了したら送信を選択します。
入力にミスがある場合などは項目に赤字でコメントが付きますので確認しましょう。
###作成後の画面
赤枠のIPアドレスがインバウンドエンドポイントのIPになります。(今回は2つ)
###動作の確認
作成が完了しましたらVPNやDXで接続をしている自設備のクライアントからDNSの確認をします。
インターネットに抜ける事とAWSのinternalドメインが引ける事を確認します。
また、Route53でPrivate hosted zonesを利用している方は登録しているRRも確認してみましょう。
$ dig @[作成されたInbound Endpoint IP] [FQDN]
$ dig +noall +ans +stats @172.10.1.1 www.google.com
www.google.com. 74 IN A 172.217.161.36
;; Query time: 5 msec
;; SERVER: 172.10.1.1#53(172.10.1.1)
;; WHEN: 火 12月 24 16:18:32 JST 2018
;; MSG SIZE rcvd: 48
$
$ dig +noall +ans +stats @172.10.1.1 ip-172-10-1-1.ap-northeast-1.compute.internal
ip-172-10-1-1.ap-northeast-1.compute.internal. 60 IN A 172.10.1.1
;; Query time: 6 msec
;; SERVER: 172.10.1.1#53(172.10.1.1)
;; WHEN: 火 12月 24 16:19:02 JST 2018
;; MSG SIZE rcvd: 81
$
$ dig +noall +ans +stats @172.10.1.1 [Route53 Private hosted zones rr]
[Route53 Private hosted zonesで登録した値が返る事]
;; Query time: X msec
;; SERVER: 172.10.1.1#53(172.10.1.1)
;; WHEN: 火 12月 24 16:19:XX JST 2018
;; MSG SIZE rcvd: XXXX
$
以上でインバウンドエンドポイントは完成です。
オンプレ側の使い方によりますが、クライアントのresolv.confなんかに作成したIPを書いておけばOKという事ですね。これだけでもAWS側にBINDを立てなくて済むのは大変助かる。
多少インターネット向けのQuery Timeが気にはなりますがまぁ大丈夫でしょう。
##Route53 ResolverでOutbound Endpointを作成してみる
###アウトバンドエンドポイントの作成を選択
作成の仕方はインバウンドエンドポイントとほぼ同様です。
###各項目に必要パラメータを入力
入力の項目はエンドポイントのIPアドレス設定の部分まではインバウンドエンドポイントと同じ流れです。
セキリティグループについては自設備セグメントからのincomingでない事に注意してください。
最後にtagがありますのでお好みで値を入れてください。
全て入力が完了したら送信を選択します。
入力にミスがある場合などは項目に赤字でコメントが付きますので確認しましょう。
###作成後の画面
インバウンドエンドポイントと一緒ですね。。
###この時点での動作確認
と行きたいところですが、この時点で作成されたIPに対してはDNS Queryは投げられないようです。
##ルールを作成する(Outbound Forwarding rules)
###ルールの作成
ルールの作成を選択します
###各項目に必要パラメータを入力
名前はルール名と言う事ですね
#####ルールタイプは2種類から選びます
転送はDNSソフトウエアにもあるような、特定のFQDNを特定のIPへForwardするもの
システムについては、特定のドメインを転送で設定した後に、転送対象ドメインの特定サブドメインのみインターネット上に向けると言う時に使う形
Rule type
When you want to forward DNS queries for specified domain name to resolvers on your network, choose Forward.When you have a forwarding rule to forward DNS queries for a domain to your network and you want Resolver to process queries for a subdomain of that domain, choose System.
For example, to forward DNS queries for example.com to resolvers on your network, you create a rule and specify Forward for Rule type. To then have Resolver process queries for apex.example.com, you create a rule and specify System for Rule type.
タイプが決まったところで、ルールを適用するVPCの選択し、Forwarding ruleをかけるドメイン名を入力します。
ターゲットIPアドレスはForward先のDNSアドレスとListenしているPortを指定する。
最後にtagがありますのでお好みで値を入れてください。
全て入力が完了したら送信を選択します。
入力にミスがある場合などは項目に赤字でコメントが付きますので確認しましょう。
###rule作成後の画面
登録されると一覧のページに追加されます。
###作成ruleの詳細確認
転送の詳細を確認したい場合は、ドメイン名を選択します。
塗りつぶしが多いですが、設定したドメイン、タイプ、ターゲットIPが合っているか確認しましょう。
###動作の確認をする
名前解決を確認する
(この例ではforward先にDNSを立ててないのでtcpdumpで特定のQueryが来ている事だけを確認しています、またIPアドレスはマスクするために書き換えているためパケットサイズなどは実際のものと事なります)
今回のruleではexample.comを特定のサーバにForwardingするruleにしてます。
以下のようにdigを発行
$ dig +noall +ans +stats example.com.
;; Query time: 3201 msec
;; SERVER: 10.1.0.2##53(10.1.0.2#)
;; WHEN: 火 12月 24 16:01:40 JST 2018
;; MSG SIZE rcvd: 40
$
転送先にDNSが立っていないので、ServFailになるので応答は帰って来ていませんが、
転送先のサーバではちゃんとQueryが届いてる事が確認できている。(SourceIPが2つなのはOutbound Endpointを2つ立てているので)
# tcpdump -i any -nn port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:01:35.979345 IP 10.1.1.38.54201 > 172.10.10.10.53: 56447+ [1au] A? example.com. (40)
16:01:36.355807 IP 10.1.1.38.54201 > 172.10.10.10.53: 10187+ [1au] A? example.com. (40)
16:01:36.731207 IP 10.1.2.45.32831 > 172.10.10.10.53: 41545+ [1au] A? example.com. (40)
16:01:37.107971 IP 10.1.2.45.32831 > 172.10.10.10.53: 19213+ [1au] A? example.com. (40)
16:01:37.486731 IP 10.1.1.38.54201 > 172.10.10.10.53: 45208+ [1au] A? example.com. (40)
16:01:37.863050 IP 10.1.1.38.54201 > 172.10.10.10.53: 16499+ [1au] A? example.com. (40)
16:01:38.238095 IP 10.1.2.45.32831 > 172.10.10.10.53: 14261+ [1au] A? example.com. (40)
16:01:38.615070 IP 10.1.2.45.32831 > 172.10.10.10.53: 49859+ [1au] A? example.com. (40)
16:01:38.993728 IP 10.1.1.38.54201 > 172.10.10.10.53: 16805+ [1au] A? example.com. (40)
16:01:39.370274 IP 10.1.1.38.54201 > 172.10.10.10.53: 458+ [1au] A? example.com. (40)
16:01:39.744989 IP 10.1.2.45.32831 > 172.10.10.10.53: 41978+ [1au] A? example.com. (40)
16:01:40.121218 IP 10.1.2.45.32831 > 172.10.10.10.53: 35504+ [1au] A? example.com. (40)
なお、これでわかる事はOutbound Trafficの場合は、
Amazon Provided DNSを経由してOutbound Endpointに到達し、Outbound EndpointからForwarding先に抜けていると言う事
##最後に
・VPNやDX環境でForwarderを立ててた人は乗り換える価値はあるかも
設計と管理をしなくなるのは良い気がする
・Queryログ機能などはまだ実装がない模様
・Private空間なのでどのくらいのtps/qpsに耐えられるかは不明
・CloudWatchのMetric等はまだ試していない
##re:Invent 2018のスライド
Introduction to Amazon Route 53 Resolver for Hybrid Cloud (NET215) - AWS re:Invent 2018