きっかけ
DTIのDNSサーバ202.216.229.30、なんでcloudfrontの正引きを高確率で127.0.0.1返すの。
— エアコンが新しくなったmatsuu (@matsuu)
まじか!と思い、conohaからdigって見るものの、REFUSEDになってしまいました。「ちぇー、ちゃんアクセス制限してんのかー」と思っていたところ、@tss_ontapさんから「繰り返し聞いてみましょう」とのアドバイスをいただきました。
言われた通り何度もdigった結果、、、
@tss_ontap うお、返ってきた!え!?
— こんごー@頑張らないために頑張る (@kongou_ae)
アクセス制限しているにも関わらず、何回かに1回、応答を返すという謎動作。「このDNS、ロードバランサか?」ということで、どんな構成なのか調べてみました。
調べかた
- DTIが提供する以下のキャッシュDNSサーバ(202.216.224.30、202.216.229.30)にServersMans VPSから再帰問い合わせ行う。(このためだけにVPSを借りた。)
- 問い合わせで利用するFQDNは、絶対にキャッシュされていないドメイン(自ドメインのNXDOMAINになるもの)を使う
- 自ドメインの権威DNSはIPv4アドレスのみでListenする。
- 自ドメインの権威DNSのクエリログを確認し、問い合わせで使ったFQDNを問い合わせに来たDNSサーバをチェックする。
- 問い合わせに来たDNSサーバに、ConohaVPSから再帰問い合わせを行い、オープンリゾルバかどうかチェックする。
- 面白そうなので、問い合わせに来たDNSサーバに、ServersManからversion.bindを問い合わせる。
結果
202.216.224.30
202.216.224.30は13台中2台がオープンリゾルバでした。version.bindを信じるのであれば、ソースからコンパイルしたbindはちゃんとしていて、RHELのパッケージを使っているbindはオープンリゾルバのようです。
VIP |
---|
202.216.224.30 |
202.216.229.30
202.216.229.30は8台中5台がオープンリゾルバでした。version.bindを信じるのであれば、202.216.224.30と同様、ソースからコンパイルしたbindはちゃんとしていて、RHELのパッケージを使っているbindはオープンリゾルバのようです。
VIP |
---|
202.216.229.30 |
雑感
- ロードバランサの配下に置くサーバは、設定を合わせた方がいいと思います。。。
- DNSサービスって、リアルサーバが沢山必要なのね。。。
- BINDのバージョンをあわせないのは、脆弱性対策なのかなあ。。。全部同じバージョンだと、ひとつの脆弱性で全部死ぬから。
- でも、全部BINDだから、新BINDコロリが出たら全滅だよなぁ。。。
- LBの配下で異なるキャッシュDNSサーバ(e.g.unboundとBIND)を動かすと強いDNSサービスが作れそう。