Route53 Resolverを試した

最近自身の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を書けるのもポイントです(図中の黄色枠)。
<img width="981" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/664870c5-a02e-6407-03ad-2e85cbbeccef.png">



##料金体型
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 億件を超えた分のクエリ/月
>
>https://aws.amazon.com/jp/route53/pricing/

##Route53 Resolverのコンソール画面をみてみよう
既に東京リージョンでも利用が可能です。
*AWSは頻繁に更新されるためキャプチャ画面は変更されている事があります。

###サービスの検索でRoute53を探す
<img width="524" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/e3f3da68-8058-77de-1aad-093b759d547b.png">

###Route53のコンソール画面上で確認
左ペイン下側のResolverと言う項目が増えています
<img width="260" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/2e0a02c7-75a1-ba31-4185-2cfe995585a3.png">

###各項目を見る(VPC)
左ペインがいきなり日本語表示になったのはさておき
VPCを選択すると今作成されているVPCとそのVPCに作成されているエンドポイントの
情報を確認する事ができます。
また表示されているVPC-idをクリックするとEndpointのIPアドレス等の確認ができます。
<img width="1274" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/372e2ebc-b709-d269-26d2-31631111bbaf.png">

###各項目を見る(インバウンドエンドポイント)
こちらは既に作成されている場合は作成されている一覧が表示されています。
また新規でインバウンドエンドポイントを作成する場合もこちらの画面から行います。
<img width="1060" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/2b58e069-f80d-e0cc-5331-d070ab706d33.png">

###各項目を見る(アウトバウンドエンドポイント)
こちらもインバウンドエンドポイントの画面と同様です。
ルールは適用されているForwarding ruleの数を表しています。
<img width="1034" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/dba0ea4a-ef1b-af1e-5daf-bacd0bdfa454.png">

###各項目を見る(ルール)
ここは初期の状態でも一つルールが存在しています。
ドメインを見ると`.`なのでFowarding ruleが存在しない場合はこちらが適用となりインターネット向けにQueryが抜けるようになっているようです。
<img width="1019" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/96ec1f2b-07f6-6f74-f9d2-d5d664ffc88a.png">

##Route53 ResolverでInbound Endpointを作成してみる
インバウンドエンドポイントの作成をやってみたいと思います。

###インバウンドエンドポイントの作成を選択
<img width="981" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/7512dd27-a6f7-2d8a-6eee-34044251b884.png">

###各項目に必要パラメータを入力
理解が間違っていなければVPNやDXで自設備を繋いでいる場合はリーチャビリティが取れているVPCを選択する事になると思います。
また、セキュリティグループについてはこの画面で作成ができないため、
別タブで作成画面を開くか事前に作成しておく必要があります。
<img width="709" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/b816561a-cdd6-909a-edd1-993d25c62792.png">
セキュリティグループについては作成するVPCに紐づけて53番の`TCP`と`UDP`を開ける事になると思います。
ソースはご自身のセキュリティポリシーに合わせてください。
<img width="931" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/a1b77124-925c-b719-1e06-355e0564ef68.png">

###最後にAvailability zoneとサブネットを選択
DNSとして53番をListenさせるIPを自分で指定したい場合は`自分で指定したIPアドレスを使用します。`にラジヲボタンを付け直し前段で選んだサブネットのレンジから切り出します。
なお、画像みてわかる通り、`IPアドレス#1`と`IPアドレス#2`の2つを最低作成する必要があります。
ちなみに、Availability zoneについては`IPアドレス#1`、`IPアドレス#2`共に同Availability zone内で作成も可能でした。
必要に応じて`IPアドレス#3`も作成ができます。
<img width="775" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/7297c9a1-5c58-5a59-9b4c-4ae16003a7ff.png">

###最後にtagがありますのでお好みで値を入力
全て入力が完了したら`送信`を選択します。
<img width="778" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/7791fbe4-a79e-10ff-245e-35171d14679c.png">
入力にミスがある場合などは項目に赤字でコメントが付きますので確認しましょう。

###作成後の画面
赤枠のIPアドレスが`インバウンドエンドポイントのIP`になります。(今回は2つ)
<img width="992" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/63267e01-1b3e-086d-13bd-06ae356d3eac.png">

###動作の確認
作成が完了しましたら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を作成してみる

###アウトバンドエンドポイントの作成を選択
作成の仕方はインバウンドエンドポイントとほぼ同様です。

<img width="1002" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/86c7a348-80b2-d53e-ed32-8f9e41797d78.png">

###各項目に必要パラメータを入力
入力の項目はエンドポイントのIPアドレス設定の部分まではインバウンドエンドポイントと同じ流れです。
セキリティグループについては自設備セグメントからのincomingでない事に注意してください。
<img width="763" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/dd9da6b0-069c-a32e-fad0-e9d97b9af9eb.png">

最後にtagがありますのでお好みで値を入れてください。
全て入力が完了したら`送信`を選択します。
<img width="796" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/e7278dbf-f526-1389-2d7b-84cd4e7983b4.png">
入力にミスがある場合などは項目に赤字でコメントが付きますので確認しましょう。

###作成後の画面
インバウンドエンドポイントと一緒ですね。。
<img width="997" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/58418ae8-b330-0720-06cf-ab04ce8610d5.png">

###この時点での動作確認
と行きたいところですが、この時点で作成されたIPに対してはDNS Queryは投げられないようです。


##ルールを作成する(Outbound Forwarding rules)

###ルールの作成
`ルールの作成`を選択します
<img width="996" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/3fb2e955-b3c3-438d-9e71-a2ba853a851e.png">

###各項目に必要パラメータを入力
名前はルール名と言う事ですね
<img width="649" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/feb8584b-bd3a-ee25-031e-3a8e7634377b.png">

#####ルールタイプは2種類から選びます
<img width="606" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/ea885055-a1ed-9444-30f6-054799f8dc3d.png">
`転送`はDNSソフトウエアにもあるような、特定のFQDNを特定のIPへForwardするもの
`システム`については、特定のドメインを`転送`で設定した後に、転送対象ドメインの特定サブドメインのみインターネット上に向けると言う時に使う形
<img width="610" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/c3efba16-c2bf-b52d-8d50-86e65e3724dd.png">

>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.
>
>https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resolver-forwarding-outbound-queries.html#resolver-forwarding-outbound-queries-rule-values

タイプが決まったところで、ルールを適用するVPCの選択し、Forwarding ruleをかける`ドメイン名`を入力します。
ターゲットIPアドレスはForward先のDNSアドレスとListenしているPortを指定する。
<img width="767" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/96fb4553-de18-d2df-bbbf-a325fba66d0c.png">

最後にtagがありますのでお好みで値を入れてください。
全て入力が完了したら`送信`を選択します。
<img width="774" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/07818815-9626-db09-65c3-e260fcbf1a99.png">
入力にミスがある場合などは項目に赤字でコメントが付きますので確認しましょう。

###rule作成後の画面
登録されると一覧のページに追加されます。
<img width="995" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/50b423a1-ea24-b2cd-7620-731ca83872ec.png">

###作成ruleの詳細確認
転送の詳細を確認したい場合は、ドメイン名を選択します。
塗りつぶしが多いですが、設定した`ドメイン`、`タイプ`、`ターゲットIP`が合っているか確認しましょう。
<img width="998" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/04a72bca-85df-6f1b-e21e-504144f4ef9b.png">

###動作の確認をする
名前解決を確認する
(この例ではforward先にDNSを立ててないのでtcpdumpで特定のQueryが来ている事だけを確認しています、またIPアドレスはマスクするために書き換えているためパケットサイズなどは実際のものと事なります)
今回のruleではexample.comを特定のサーバにForwardingするruleにしてます。

以下のようにdigを発行

```:EC2インスタンス(Forward元):
$ 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つ立てているので)

```:Forward先:
# 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先に抜けていると言う事
<img width="817" alt="" src="https://qiita-image-store.s3.amazonaws.com/0/90309/7f687106-9966-bae1-45ef-f2494a833cf6.png">


##最後に
・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](https://www.slideshare.net/AmazonWebServices/introduction-to-amazon-route-53-resolver-for-hybrid-cloud-net215-aws-reinvent-2018)