Cloudflareを設定したらサーバー内部で名前解決ができなくなった

Question

問題点課題

サーバセキュリティ強化のためAPIサーバとなっているサーバに対してCloudflareの設定を行ったら、内部でのDBアクセスのための名前解決ができなくなってしまいました。
現在、復旧のためいろいろ調査していますが、なにぶんサーバ関連初心者です。ご指導いただけると幸いです。

現在の環境

AWSにてサーバ構築。スマホアプリからのAPIサーバとして動かしている。Laravel 5.1となっています。
RDSにてDBサーバ構築。Postgre9.4です。
Route53でドメインの管理
説明のため、メインのドメインはssss.jpとします。
DBはdb.ssss.jp をCNAMEで設定しています。

作業した手順

• Cloudflareのアカウント作成。指示に従い、Route53でssss.jpの内容を指定されたものへ変更。

　　ns-814.awsdns-37.net.
　　ns-1221.awsdns-24.org.
　　ns-1957.awsdns-52.co.uk.
　　ns-40.awsdns-05.com.

から

    arushi.ns.cloudflare.com. 
    rocco.ns.cloudflare.com.

へ変更しました。（変更箇所はここのみ）

• しばらくすると、サーバ監視でエラーを吐き始めました。調べてみるとdb.ssss.jpが見つからないと言うエラー

local.ERROR: exception 'PDOException' with message 'SQLSTATE[08006] [7] could not translate host name "db.ssss.jp" to address:      Name or service not known' in /mnt/home/apache/..../user-api/vendor/laravel/framework/src/Illuminate/Database/Connectors/Connec     tor.php:55

名前解決できないと見えます。（ちなみに、PgAdminなどで直接DBをつなぐと問題なく見えています。）

• DNS設定がおかしいと思い、設定を元に戻し、cloudflareからもssss.jpの設定は削除しました（削除）
• 当該サーバ側でdig ssss.jp、dig db.ssss.jpを試すとssss.jpの方では、ANSWER SECTIONで正しくIPアドレスが出てきますが、db.ssss.jpでは

;; QUESTION SECTION:
;db.ssss.jp.                        IN      A

;; AUTHORITY SECTION:
ssss.jp.               32      IN      SOA     arushi.ns.cloudflare.com. dns.cloudflare.com. 2034188024 10000 2400 604800 3600

と返ってきます。すでに削除変更したはずのcloudflareのDNSが表示されています。

1時間以上待っている状態ですが、まだ変化はないようです。

対応案？

これですが、どのように対応すべきなのでしょうか？サーバー内部での名前解決なので、時間がかかるというのも不明です。
いずれにしろ、削除変更したはずのDNSがまだdigで表示されている状況です。

冒頭にも書きましたが、サーバ側の知識は素人です。
足りない情報も多いかと思います。ご指導いただけると大変助かります。

Answer 1

Route53にはRDSのエンドポイントのレコードをどう設定しているんでしょうか？

Private Hosted Zoneとして設定したゾーンに登録しようとしているのなら理解はできますが、今回の設定だとインターネットを経由してRDSにアクセスしようとしていることになります。
RDSのほうでPublicly Accessibleに設定していないと接続できません。
そして特別な理由がない限りPublicly Accessibleの設定は推奨しません。

このようなことをせずRDSのエンドポイントを直接指定すれば、AWSの内部からはRDSのプライベートIPが名前解決されるはずなのでそちらを使ってください。
煩雑な名前になるのが面倒ならば、Private Hosted Zoneで内部DNSでの名前解決をしてください。
前述の通り、理由がなければインターネットからアクセスできる状態にするのは推奨しません。

また、今回対象がAPIサーバなので、CDNを使ってもそれほど意味がなさそうな気がするのですが、どうでしょう…？
セキュリティ強化のためとは具体的に何に対するセキュリティがどう強化されることを意図してますか？

DNSで設定した内容が引けないのは元々設定してあったTTLが長く、古い情報がキャッシュされているからではないかという気がするのですが、DNSの詳細な仕様にそれほど詳しいわけではないのでそのへんは割愛します。

Comments

[maedamin]

ありがとうございます。
おっしゃる通りAPIなので今回の対応は意味はありませんでした。なので余計なことをしてしまったと言うことです。問題は、そのせいでDB接続ができなくなったことにあります。
RDSのエンドポイント直で良かったはずなのですが、なぜかRDSのエンドポイントをCNAMEで設定してありました。

ちなみにDNSの方ですが、時間とともに解消したように見えます。
今回急ぎでしたので、最後の手段で/etc/hostsに設定してしまいましたが・・・

[yu_1985]

理由がない限りわざわざインターネット経由でRDSに接続する意味がないので、直接RDSのエンドポイントを指定するか、内部DNSを利用することをおすすめします。
また、DNSで名前解決できてしまうということは、そのRDSのエンドポイントはインターネットからアクセスできてしまうということなので、そもそも必要がなければインターネットからアクセスできないようにしましょう。
セキュリティを気にするのならそちらのほうが遥かに優先度が高いです。

> ちなみにDNSの方ですが、時間とともに解消したように見えます。
おそらくは記載のとおりですね。