この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Route 53をプライベートネットワーク向けに利用する
本セッションでは、今までオンプレで管理していたDNSサーバーをAmazon Route53に移行するメリットと方法について解説しています。ふらっと立ち寄った最終日の最終セッションでしたが、不足していた知識を補うことができました。
アジェンダ
全体の流れは、なぜDNSをRoute 53にするのか？から始まり、基本的なDNSのユースケースと、拡張プライベードDNSについて解説しています。
パブリックDNS、プライベースDNS、モニタリングについてそれぞれ考えています。
Route 53への移行
DNSデータをRoute 53に移行する手順として、既存のDNSからのエクスポート、委譲、転送などが考えられます。まるごと移行する場合には、エクスポートしてRoute 53に同じ情報を書き込みます。そして、ドメイン管理事業者が指定するDNSサーバをRoute53に指定することで、パブリックドメインの移管が完了します。
Route 53の優位性
なぜRoute 53に移行するか考えた時、最も大きなモチベーションは、管理不要で、分散配置されていて、安価であることが挙げられます。また、エイリアスの設定、ヘルスチェック、レイテンシーベースのバランシングなど、他には無い機能が多数あります。
ということで、オンプレで行なっていたモニタリングなどの管理は不要となりました。
プライベートDNS
パブリックDNSの管理ができるようになりましたので、続いて、プライベートDNSの管理をしたいと思います。管理コンソールから設定をしましょう。
とても簡単です。以上により、AWS側にほとんどのDNS機能が移管されました。実際にVPC内のインスタンスからプライベートDNS情報が見れるか見てみましょう。以下のようにプライベートなホステッドゾーンを作成して、TXTレコードに「hello world」と書いてみました。
VPC内のEC2から見たTXTの内容です。
確かにTXTレコードが見えましたね。
$ dig txt classmethod.jp
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.39.amzn1 <<>> txt classmethod.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31058
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;classmethod.jp. IN TXT
;; ANSWER SECTION:
classmethod.jp. 300 IN TXT "hello world"
;; Query time: 4 msec
;; SERVER: 172.16.0.2#53(172.16.0.2)
;; WHEN: Sat Oct 10 19:53:12 2015
;; MSG SIZE rcvd: 56これでプライベートDNSの移行も完了しました。
拡張プライベートDNS
DNSサーバがクラウド側に来たことによって、オンプレ側にあるPCやサーバからの問い合わせがどのようになるか考えてみましょう。
Amazon DNSサーバー
Amazon DNSサーバーは、VPC作成時に自動で指定されるDNSサーバーです。公式ドキュメントには以下の様な説明があります。
VPC の Amazon EC2 インスタンスにカスタム DNS サーバーを設定した場合は、その VPC 用に Amazon が提供する DNS サーバーの IP アドレスにプライベート DNS クエリをルーティングするように、カスタム DNS サーバーを設定する必要があります。この IP アドレスは、VPC ネットワーク範囲のベースに「プラス 2」した IP アドレスです。たとえば、VPC の CIDR 範囲が 10.0.0.0/16 である場合、DNS サーバーの IP アドレスは 10.0.0.2 です。
例えば、VPCのネットワークアドレスを、「127.16.0.0/16」で作成した場合、カスタムDNSサーバーは「172.16.0.2」です。実際に見てみましょう。確かに「172.0.0.2」が自動的に設定されていますね。
$ cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search ap-northeast-1.compute.internal
nameserver 172.16.0.2VPC の外部にあるカスタム DNS サーバーを使用していて、プライベート DNS を使用する場合は、VPC 内の Amazon EC2 インスタンスのカスタム DNS サーバーを使用するように再設定する必要があります。
さらにVPCの外にあるDNSサーバーとやり取りするためには再設定する必要があると書いてあります。以下の様な場合ですね。
オンプレからクラウドへの問い合わせについては、リゾルバ同士が直接やりとりするのではなく、フォワーダーを経由して通信をします。
フォワーダーには、unboundやActive Directory（SimpleAD）などの製品を置きます。
これにより、オンプレからクラウドへの問い合わせがうまく行きます。
クラウドからクラウドへの問い合わせ
フォワーダーを間に挟むことによて、それぞれのゾーン情報が行き渡るようになりまた。しかし、クラウド側の名前解決がオンプレに向かっていてはもったいないです。
そこで、オンプレのゾーン情報を定期的にクラウド側にコピーすることで、クラウド側の問い合わせがオンプレ側に向かうこと無く、クラウド側だけで完結します。
まとめ
今回は、オンプレからクラウドへのDNS移行と、オンプレとクラウドのDNSの連携について解説しました。ネットワークアドレス+2という制約を回避するために、フォワーダーを用いて連携を実現しているのがポイントですね。皆さんもぜひやってみてください。
参考資料
(NET308) Consolidating DNS Data in the Cloud with Amazon Route 53
14
